✔ Stu´s runde Ecken

Hi,

ihr kennt doch sicher alle Stu seine Technik um runde Ecken zu machen?

CSS

HTML

Frage dazu, wenn ich ca. 10 solche kleine KAsten auf meine Seite stelle, meint ihr nicht auch, dass es von der Ladezeit und Größe der Datei nicht besser wäre wenn man das mit einem Hintergrundbild mit runden Ecken besser macht als jedesmal so viel Code zu schreiben?

Ich denke die Technik eignet sich höchstens für runde Ecken eines gesamten Layouts und ist für mehrere Kästen nicht so geeigent?

Das müßte man mal genau ausrechnen.
Pro Stu:
Auch Ecken mit Gifs als Hintergrund benötigen zusätzliches Markup.
Nur HTML-Request, kein zusätzlicher Gif-Request (4 mal).
Beim Speichern der Seite: Einzelne Datei, wenn nicht an anderer Stelle Dateien eingebunden werden.
Kontra Stu:
Das zusätzliche Markup für die Ecken wächst, je größer der Radius sein soll.

Versuch ein Formel aufzustellen (Alles in Byte gerechnet):
Für Gif:
"CSS für Gif-Ecken" + "Größe aller Gif-Dateien" + "zusätzliches Markup für Gif-Ecken" * "Anzahl der Boxen"

Für Stu:
"CSS für Stu's Ecken" + "zusätzliches Markup für Stu's Ecken" * "Anzahl der Boxen"

Nun kannst Du Dir für jeden Radius, den Du benötigst eine Box erstellen, Bytes zählen, abschätzen, wie viele Boxen Du auf Deiner Seite haben wirst und ausrechnen, welche Art weniger Bytes braucht.

Unberücksichtigt: Die Vor- und Nachteile, die sich nicht durch die Dateigröße beschreiben lassen.

Gruß hpvw

Hallo,

also danke für die Formeln zum Ausrechnen, aber jetzt mal ohne zu rechnen denke ich, das es mit einem Gif besser gelösz ist, weil das als Hintergrund in einem span Tag schnell geladen ist bei ca. 4 span Tag mit unschönen Leerzeichen darin um eine obere runde Ecke zu erhalten, denke ich hat man viel mehr Aufwand und am Ende auch KB.

Als Hintergrundbild mit runde Ecke wird das ganze ja nur einmal geladen, also ca 10KB das Bild.

Gruß
feh

Stu macht seine krazy korners mit b statt span und ohne geschützte Leerzeichen. Das spart eine ganze Menge. Ein 8bit-Gif (zwei Farben genutzt) mit 8x8 Pixel hat bei mir übrigends 64 Byte. Um an 10k zu kommen brauchst Du ganz schön große Ecken.
Das macht bei 4 Ecken 256 Byte.
Stu benötigt pro 2 Ecken 18 * (Radius+1) Bytes an Markup, hier also 2 * 18 * 9 = 324 Byte. Das Markup für Gifs darf also Maximal 68 Byte (=Zeichen) haben, damit die Gifs ohne CSS bereits bei einer einzelnen Box Vorteile haben.Ich denke, das CSS für Gifs wird etwas kleiner ausfallen. Das Markup wird bei Gifs vermutlich um 100 Byte haben. Bei einer Box kann Stu's Variante also evtl. etwas kleiner sein, aber im Großen und Ganzen haben Gifs, was die Bytezahl angeht, die Nase vorn.

Gruß hpvw

PS Stu's Ecken haben aber noch einen (kleinen) Vorteil: Sie funktionieren auch bei Usern, die Hintergrundbilder nicht laden.

Hallo hpvw,

vielen Dank für deine Rechnung, selber kann ich das nicht so gut.:-(

Aber sie bestätigt was ich geahnt habe, das es mit Gif doch etwas Speicherplatz spart wenn man mehrere verwendet.

Hinzu kommt noch, wen man ein XHTML Seite für XHTHL Broser macht und das ganze über einen XML PArser schickt kann es zu Problemen kommen, weil ein leeres Tag nicht logisch ist, wen man aber ein Leerzeichen rein macht weis ich nicht ob das auch viel hilft, ich kann mich nur an eine alte Seite erinnern wo ich als Absatndhalter ein Div Tag mit Leerzeichen benutzt hatte und mir darauf hin jemand einen Hinweis gegeben hatte, das die Seite im Netscape 7.0 eine XML Parser Fehlermeldung verursacht weil das schema nicht stimmen würde.

Das ganze hatte mich so abgeschreckt, das ich mich dazu entscheiden musste meine schöne Homepage keinen XHTML Browser als reine XHTML Seite anzubieten. Obwohl alle meine XHTML Browser keinen einschließlich Netscape 7.1 keine Fehlermeldung machten, hat der Netscape 7.0 ein gemacht. Das isz doch erschreckend. Wie soll man sich da noch sicher sein, wobei doch erzählt wird das die XML Parser normal viel strenger sind, da habe ich mir gedacht wen schon denn schon, also wenn einer Meldet dann alle und sonst halt keiner.

zum kotzen, schade.

gruß
feh