nicht angemeldet
Hallo Michael,
Selbst wenn der Browser also lediglich prüfen würde,
ob die in seinem Cache vorliegende Datei aktuell ist,
würde das schon mehr kosten, als den CSS-Code immer
wieder komprimiert zu übertragen!
*ähem* wir sprechen hier nicht von einer einzelnen Datei, sondern
von einer Website. Selbst wenn man es niedrig ansetzt, wird sich
ein Besucher wohl schon drei Seiten anschauen und da wird dann
genau einmal die CSS-Datei angefordert. Soll heißen, umso mehr
HTML-Dateien vom Besucher angefordert werden, die diese CSS-Datei
referenzieren, umso größer wird der Vorteil dieser Lösung. Dazu
kommt noch, dass eventuell nur ein 304 an den Browser geschickt
wird, wenn sie die CSS-Datei nicht verändert hat. Wenn also je-
mand 10 Seiten abruft, die ein und diesselbe CSS-Datei einbinden,
so werden später genau 11 Einträge im Logfile stehen.
Es kann natürlich sein, dass in Einzelfällen Browser so eigenartig
konfiguriert sind, dass sie zehnmal die CSS-Datei anfordern, aber
der Normalfall ist sowas nicht ;-)
Wenn sich also schon das Einbindung von 2 KB CSS-Code
lohnt, dann lohnt es sich bei den üblichen kleineren
Dateien umso mehr.
Wenn man mal Deine Komprierung ausser acht lässt, dann kann man
davon ausgehen, dass je weniger Seiten von einem Besucher im
Schnitt besucht werden und je kleiner die CSS-Datei ist, umso
mehr es sich lohnt, die CSS-Definitionen direkt in die HTML-
Dateien reinzuschreiben. Wenn eine oder beide Sache sich genau
andersrum verhalten, dann dürfte meine Variante die bessere Wahl
sein. Im konkreten Fall ist natürlich noch zu berücksichtigen,
dass Du einzelne CSS-Dateien unkomprimiert auslieferst, während
CSS direkt in HTML-Dateien mit komprimiert wird.
Allgemein dürfte die Trennung von HTML- und CSS-
Dateien weniger Traffic verursachen.
Ich behaupte nach wie vor das Gegenteil.
Wenn Du diese Behauptung pauschal aufstellst, dann ist sie falsch.
Wann welche Variante vermutlich besser geeignet ist, habe ich ja
weiter oben beschrieben. Auf http://de.selfhtml.org/ beispiels-
weise schauen die meisten Besucher etliche HTML-Seiten an, da
wäre es grober Unfug, die CSS-Definitionen jedesmal einzeln mit
reinzuschreiben. Eine externe CSS-Datei, die in fast allen Fällen
genau einmal während eines Besuches angefordert und geladen wird,
ist da sinnvoller.
Dazu kommt noch der nicht unwesentliche Punkt der
besseren Wartbarkeit.
Der existiert nicht.
im konkreten Fall kann es durchaus sein, dass er nicht existiert,
in der Regel ist er vorhanden. Die meisten Websites werden nicht
vollautomtisch über irgendwelche Scripte generiert, so dass es
schon einen Unterschied macht, ob man CSS-Änderungen in allen
HTML-Dokumenten oder nur in einer CSS-Datei vornehmen muß. CMS
lasse ich hier mal aussen vor, die können ja noch nicht einmal
validen Quelltext generieren, obwohl ein DOCTYPE angegeben ist :-/
Meine statischen Dateien mit eingebundenem CSS-Code
entstehen natürlich durch ein Perl-Skript. Das kann
man ja mit ausliefern.
im Fall einer Errata zu SELFHTML sicher nicht praktikal. Die CSS-
Datei von SELFHTML 8.0 wird in mehr als 400 HTML-Seiten genannt,
die hätte man dann allesamt mit der Errata austauschen müssen,
nur weil eine Kleinigkeit in der CSS-Definition geändert wurde,
die allerdings in allen HTML-Dateien notwendig ist (es war die
Standardschriftgröße).
Wenn Du dagegen die umfangreicheren Möglichkeiten
von CSS nutzen und Deine Dokumente nicht nur
optisch, sondern auch semantisch korrekt gestalten
willst, dann wirst Du nicht umhin kommen, zumindest
mittelfristig ein einfacheres Aussehen in alten
Browsern zu akzeptieren.
Das halte ich für nicht sinnvoll.
ich weiß, dass http://favicon.de im NC4 nicht wirklich schön aus-
sieht, aber es ist in diesem Browser vollständig nutzbar und des-
halb kann ich da ganz ruhig schlafen ;-)
Ich möchte nicht die Qualität meines Angebots für
Benutzer reduzieren, nur um dadurch irgendwelchen
Normen zu genügen.
die inhaltliche Qualität möchte ich wenn irgendwie möglich allen
Besuchern bieten. Um dieses Ziel zu erreichen (auch für Leute
die eine eigene Farbgestaltung benötigen), muß ich mich irgend-
wann von Sachen wie Tabellenlayout verabschieden. Wenn jemand
mit einem Screenreader daherkommt, soll er meine Seiten auch
vernünftig nutzen können, genauso wie ein Nutzer von NC4.
Irgendwann kommt man an den Punkt, wo dieses Ziel nicht mehr mit
der gleichen Optik für völlig veraltete Browser vereinbar ist und
da muß man sich entscheiden, was wichtiger ist.
Ich verzichte nicht auf Funktionalität für Standards
- ich befolge aber Standards, wenn dies bei gleicher
Funktionalität möglich ist.
Auch wirklich üble Tabellenkonstruktionen können (X)HTML Strict
und CSS valid sein, aber von http://www.w3.org/WAI/ und ähnlichen
Dingen sind sie natürlich dann sehr weit entfernt. Die Verwendung
eines CSS-Layouts ist nicht allein ein technischer Aspekt, viel
ist da auch eine "moralische" Überlegung gegenüber Besuchern,
die mit dem bisherigen (aufgrund der eher schlechten CSS-Unter-
stützung notwendigen) Tabellenlayout Schwierigkeiten haben.
Dazu kommt noch, dass feststehende Navigationsmenüs so wie ich
es auf http://favicon.de praktisch nur mit CSS so realisierbar
sind. In Deinem Fall hätte man wohl auch ein Frameset verwenden
können, wenn die daraus folgenden Nachteile vernachlässig werden.
Deshalb sind meine Dokumente zwar zum großen Teil XHTML
1.1 valide, aber mit vereinzelten target-Attributen.
solange man keine Frames verwendet (ich suche nach wie vor nach
einer sinnvollen Anwendungsmöglichkeit, wo sie auch die bessere
Alternative gegenüber einer Noframes-Lösung darstellen), braucht
man imho kein target-Attribut. _self, _top und _parent sind dann
überflüssig, _blank halte ich idr für nicht sinnvoll und alle
anderen Wert für das target-Attribut sollte man vermeiden.
So, jetzt habe ich wieder ewig lange und viel getippt, muß dann
mal so langsam für diesen Thread reichen, er ist vermutlich eh
schon im Archiv, wenn ich das nächste Mal hier im Forum vorbei-
schauen werde ...
Viele Grüße,
Stefan