Datei oder nicht?

[Daniel]

Hi,

wenn ich das so richtig sehe, dann haben doch style-Abschnitte(CSS) im head, priorität vor einer externen Datei. Ist das so richtig und was würdet ihr empfehlen.

Ich denke mal das eine Datei doch etwas langsamer ist. Der Browser muss doch bei Laden der Seite immer wieder da reinschauen, oder?
Bei 50Kb. der Seite ist doch besser wenn es schneller wäre!?!?

Daniel :)

[Mathias Bigge]

Hallo Daniel,

da CSS eine reine Textdatei ist, gibt's keine Geschwindigkeitsprobleme. Und für die Wartung einer Site ist der Vorteil einer externen CSS-Datei einfach riesengroß! Also raus mit den style-Dingern in die externe Datei, wenn sie sich nicht ausschließlich auf eine einzige Seite beziehen!

Viele Grüße

Mathias Bigge

[Kai Lahmann]

hi

wenn ich das so richtig sehe, dann haben doch style-Abschnitte(CSS) im head, priorität vor einer externen Datei. Ist das so richtig und was würdet ihr empfehlen.

japs, haben Priorität (auch gut so, wenn man mal was für eine spezielle Datei ändern will)

Ich denke mal das eine Datei doch etwas langsamer ist. Der Browser muss doch bei Laden der Seite immer wieder da reinschauen, oder?

Bei Ladezeiten ist es immernoch wichtiger das Datenvolumen klein zu halten - und da ist der Vorteil einer externen CSS-Datei (neben verbesserter Wartbarkeit). Die CSS-Regeln landen so oder so im RAM, da gibt's keinen Unterschied!

Grüße aus Lüneburg

Kai

[Daniel]

Alles Klar. Danke euch. ;)

Ich hab aber noch eine Frage. Denn das hab ich noch nicht kapiert/rausgefunden.

Ich definiere in den styles z.B. h1 mit color=abc.

Ich schreibe jetzt einen Text in h1. Soweit so gut. Der hätte ja die Farbe abc.

Wenn ich weiter unten wieder einen Text schrieben will in h1 in einer anderen Farbe bzw. in standardfarbe, was ist dann los?
Da bringt mir das CSS doch nichts, oder?

Daniel :)

[Orlando]

Hi, Daniel

Wenn ich weiter unten wieder einen Text schrieben will in h1 in einer anderen Farbe bzw. in standardfarbe, was ist dann los?
Da bringt mir das CSS doch nichts, oder?

Nehmen wir folgendes an:

h1 { color:#0f0; ... }      /* Überschriften sind grundsätzlich grün */

Du kannst dann eine unabhängige Klasse definieren:

.blau { color:#00f; ... }   /* Klasse blau */
  .rot  { color:#00f; ... }   /* Klasse rot */

und dann der Überschrift eine Klasse zuweisen:

<h1 class="blau">Blaue Überschrift</h1>

Alternativ funktioniert auch

<h1 style="color:#00f; ... ">Blaue Überschrift</h1>   /* direkt blau formatiert*/

oder

<h1><span style="color:#00f; ... ">Blaue Überschrift</span></h1>   /* direkt blau formatiert*/

Wie du siehst, gibt es für jeden Zweck das richtige Mittel. Du musst dich nur in http://selfhtml.teamone.de/css/formate/zentrale.htm etwas einarbeiten.

LG Orlando

[Sven Rautenberg]

Moin!

Wenn ich weiter unten wieder einen Text schrieben will in h1 in einer anderen Farbe bzw. in standardfarbe, was ist dann los?
Da bringt mir das CSS doch nichts, oder?

Nehmen wir folgendes an:

h1 { color:#0f0; ... }      /* Überschriften sind grundsätzlich grün */

Du kannst dann eine unabhängige Klasse definieren:

.blau { color:#00f; ... }   /* Klasse blau */
  .rot  { color:#00f; ... }   /* Klasse rot */

und dann der Überschrift eine Klasse zuweisen:

<h1 class="blau">Blaue Überschrift</h1>

Viel schöner wirkt das Prinzip aber, wenn man eine abhängige Klasse definiert.

h1 { color:#000; font-weight:normal; text-decoration:none; }
p  { color:#00F; font-weight:normal; text-decoration:none; }
b  { color:#00F; font-weight:bold;   text-decoration:none; }

Damit sind drei Tags formatiert. Wenn du jetzt einige Passagen besonders hervorheben willst, kannst du das über eine Klasse "hervorheben" machen - und zwar pro Tag verschieden:

h1.hervorheben { color:#F00; font-weight:bold; text-decoration:none; }
p.hervorheben  { color:#00F; font-weight:normal; text-decoration:underline; }
b.hervorheben  { color:#FF0; font-weight:bold; text-decoration:blink; }

Mit diesem Satz CSS-Formatieranweisungen kannst du jetzt normale Überschriften, Absätze und fetten Text schreiben, und durch <h1 class="hervorheben">, <p class="hervorheben"> oder <b class="hervorheben"> einfach bestimmte Teile hervorheben, ohne daß du dich noch erinnern mußt, wie die passende Klasse dazu denn geheißen hat: Wenn etwas im definierten Stile der Seite hervorgehoben werden soll, dann ist dafür die Klasse "hervorheben" zuständig.

Natürlich macht es unter Umständen Sinn, eine allgemeine Klasse "hervorheben" zuerst zu definieren, damit alle Tags hervorgehoben werden können, und danach spezielle Definitionen für einzelne Tags nochmal umzuändern.

- Sven Rautenberg

[Orlando]

Hi, Sven

Viel schöner wirkt das Prinzip aber, wenn man eine abhängige Klasse definiert.
...

Das ist natürlich alles richtig, allerdings wollte ich Daniel schön verdaulich beibringen, dass mehrere Wege nach Rom führen. Er sollte sich erstmal das CSS-Kapitel in aller Ruhe durchlesen und anhand einfacher Beispiele das System an sich verstehen. Im Moment sieht er ja den Wald vor lauter Bäumen nicht.

Die nächste Stufe wäre dann #div h1.hervorheben, gefolgt von CSS3-Selektoren, Browser-Workarounds usw. Aber so weit ist er glaube ich noch nicht ;)

LG Orlando

b.hervorheben  { text-decoration:blink; }

Don't do this at home *g*

[Daniel]

Hi,

Die nächste Stufe wäre dann #div h1.hervorheben, gefolgt von CSS3-Selektoren, Browser-Workarounds usw. Aber so weit ist er glaube ich noch nicht ;)

Ja, Ja, verarscht mich nur.

Daniel :)

[Sven Rautenberg]

Moin!

wenn ich das so richtig sehe, dann haben doch style-Abschnitte(CSS) im head, priorität vor einer externen Datei. Ist das so richtig und was würdet ihr empfehlen.

Ich denke mal das eine Datei doch etwas langsamer ist. Der Browser muss doch bei Laden der Seite immer wieder da reinschauen, oder?
Bei 50Kb. der Seite ist doch besser wenn es schneller wäre!?!?

Die externe CSS-Datei wird insgesamt einmal geladen und befindet sich dann auf der lokalen Festplatte, vermutlich auch im lokalen RAM des Rechners. In jeder HTML-Datei enthaltene <style>-Angaben müssen immer wieder durch's Modem gequält werden - das erhöht die Ladezeit!

Man kann zwar durch serverseitige Techniken erreichen, daß man nur eine Datei mit CSS-Formatierungen ändert, und die dann in alle HTML-Dateien dynamisch eingefügt wird, aber das ist von allen Lösungen die schlechteste: Der Server wird belastet, die Leitung wird belastet, und der User hat nichts davon.

Und so riesengroß werden CSS-Dateien nicht. Die CSS-Datei für's Forum hier hat knapp 7 KB, die für SelfHTML hat nur knapp 2 KB. Ich habe eigentlich noch keine CSS-Dateien gesehen, die größer waren als 20 KB.

Externe Dateien sind in jedem Fall besser!

- Sven Rautenberg

[Michael Schröpl]

Hi Sven,

Die externe CSS-Datei wird insgesamt einmal geladen
und befindet sich dann auf der lokalen Festplatte,
vermutlich auch im lokalen RAM des Rechners.

Das schon. Aber der Inhalt der externen CSS-Datei ist halt leider in den meisten Fällen völlig irrelevant.

In fast allen Fällen wird nämlich viele viele Male immer wieder vom Browser beim Server nachgefragt, ob denn der Inhalt dieser Datei auch wirklich immer noch im Cache gehalten werden darf. Manchmal mehrfach innerhalb derselben Sekunde durch denselben Browser!

In jeder HTML-Datei enthaltene <style>-Angaben
müssen immer wieder durch's Modem gequält werden -
das erhöht die Ladezeit!

Wenn sie auf diese Weise aber komprimiert werden können (mod_gzip), dann erhöht das die Ladezeit nur ganz marginal. Und wenn sie sogar auf weniger als 1 KB komprimiert werden können - was bei CSS ja nicht so ungewöhnlich wäre - dann ist das schon mal billiger als ein zusätzlicher HTTP-Request, der genau 0 Bytes Information und einen HTTP-Status 304 bewirkt, dafür aber 1 KB Traffic in Form zweier HTTP- und etlicher TCP-Header kostet, ganz zu schweigen von den diversen Handshake-Aktionen während des Verbindungsaufbaus.

Man kann zwar durch serverseitige Techniken
erreichen, daß man nur eine Datei mit CSS-
Formatierungen ändert, und die dann in alle HTML-
Dateien dynamisch eingefügt wird, aber das ist von
allen Lösungen die schlechteste: Der Server wird
belastet, die Leitung wird belastet, und der User
hat nichts davon.

Exakt das tue ich - und der Benutzer hat sehr wohl etwas davon, nämlich eine schnellere Übertragung von insgesamt weniger Daten. Jedenfalls dann, wenn es sehr viele sehr kleine CSS-Dateien sind - und das ist zumindest bei uns der Normalfall.

Sehr wenige sehr große CSS-Dateien würden sich in einem Cache gut machen - wenn einerseits die Benutzer ihre Browser richtig konfigurieren würden (tun sie leider nicht) und andererseits der Server entsprechende Angaben mitsenden würde, um den Browser von diesen unsinnigen Prüfungen abzuhalten (das zu tun ist Serverkonfiguration, geht also nicht von selbst - und es hat leider auch seine Nachteile).

Und so riesengroß werden CSS-Dateien nicht.
Die CSS-Datei für's Forum hier hat knapp 7 KB,
die für SelfHTML hat nur knapp 2 KB. Ich habe
eigentlich noch keine CSS-Dateien gesehen, die
größer waren als 20 KB.

Eben. Und je kleiner CSS-Dateien sind, desto schrecklicher sind die HTTP-Header dazu - und desto
besser wird die SSI-Lösung.

Externe Dateien sind in jedem Fall besser!

Die Existenz separater Dateien ist schon aus Wartungsgründen zu bevorzugen.
Aber ob sie dann serverseitig dynamisch eingebunden werden sollten oder clientseitig, das hängt von einer ganzen Reihe von Parameter ab, die man sehr gründlich durchrechnen sollte ...

Viele Grüße
      Michael

[gurumed]

Hallo M., kurz nachgehakt:

andererseits der Server entsprechende Angaben mitsenden würde, um den Browser von diesen unsinnigen Prüfungen abzuhalten (das zu tun ist Serverkonfiguration, geht also nicht von selbst - und es hat leider auch seine Nachteile).

Bitte erläutere das! Wie muss ich den Server einstellen? Welche Nachteile genau muss ich befürchten?

Gruß

[Michael Schröpl]

Hi,

andererseits der Server entsprechende Angaben
mitsenden würde, um den Browser von diesen
unsinnigen Prüfungen abzuhalten (das zu tun
ist Serverkonfiguration, geht also nicht von
selbst - und es hat leider auch seine Nachteile).
Bitte erläutere das! Wie muss ich den Server
einstellen?

HTTP-Header mitsenden, welche dem Browser sagen, wie lange er bitte _nicht_ mehr nachfragen soll, ob der Inhalt seines Caches noch etwas taugt:

• Für HTTP/1.0: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21
• für HTTP/1.1: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
  Also genau das Zeug, was man normalerweise dazu verwendet, Caching zu _verhindern_ - man kann es dadurch auch _ermutigen_.

Lesetips (Apache):
http://httpd.apache.org/docs/mod/mod_expires.html
http://httpd.apache.org/docs/mod/mod_headers.html

Der Browser muß dazu aber auch mitspielen.
Netscape 4 tut das prima (selbst wenn er auf "check always" steht, glaubt er "Expires:"-Header bedenkenlos - HTTP/1.1 versteht er eh nicht).
M$IE und Mozilla sollten in der Cache-Konfiguration auf "automatisch" stehen - dann glauben auch sie den mitgeschickten Headern (falls vorhanden) und hören auf, ständig zu fragen.
Das ist eventuell auch eine Vertrauensfrage gegenüber den Benutzern. Einige von denen haben vielleicht Angst, durch zu aggressives Caching aktuelle Änderungen nicht mitzubekommen - und sie haben dabei nicht ganz unrecht.
Allerdings können sie selbst natürlich einen expliziten Server-Zugriff erzwingen, wenn sie mit ihrem Browser umgehen können (Shift-Reload in Netscape, Cntrl-F5 in M$IE).

Welche Nachteile genau muss ich befürchten?

Solange Du anschließend nichts mehr ändern willst - erst mal keine.
Aber bedenke, daß die Browser sich dann eben die Inhalte wirklich so lange merken, wie Du es ihnen geraten hast!

Wenn Du da beispielsweise "eine Woche" empfohlen hast und dann an Deinen Seiten irgendwas änderst, dann hast Du bis zu eine Woche lang eine Migrationsphase, in welcher in den Browsern alte bzw. neue Versionen Deiner Seite drin sein können - und eventuell sogar beide Versionen gemischt bei einer inhaltlich zusammengehörigen Datei-Menge. (Das macht beispielsweise eine eventuelle Fehlersuche sehr viel lästiger.)
Du darfst also beispielsweise nicht Dateien löschen, auf welche Du in der vorherigen Version noch verwiesen hast, bloß weil Du jetzt eine neuere Version hochgeladen hast - für die Dauer der Migrationsphase müssen alle referenzierten Objekte noch weiter existieren.
Natürlich könnte man das Problem entschärfen, indem man Dateien nicht ändert, sondern neue Dateien unter neuen Namen anbietet. In diesem Falle verletzt man aber das "heilige" Prinzip "ewiger" URLs ... auch nicht schön, vor allem wenn man über Suchmaschinen gefunden werden möchte und diesen keine broken links spendieren will.

Du mußt also bei Änderungen entweder viel besser aufpassen (selbst ein automatischer Links-Checker reicht nun nicht mehr) oder 'rechtzeitig' vor einer Änderung diese Header-Erzeugung wieder abschalten und das aggressive Caching "austrudeln lassen".
Und letzteres läßt den Performance-Gewinn dann erst mal wieder verschwinden, bis nach der Änderung die Browser-Caches sukzessive wieder geladen werden. Zudem bedeutet dies natürlich, daß Du lange vorher wissen mußt, ob Du etwas ändern willst ...

Und außerdem solltest Du dann für sich tatsächlich oft ändernde Seiten auch entsprechende Header senden, welche dort das Caching abschalten oder kurz halten.
Über hinreichend feine Apache-Konfigurationen (<FilesMatch> etc.) kannst Du theoretisch für jede einzelne Datei individuelle Header erzeugen, falls Du so viel Arbeit investieren willst. Sinnvoller ist wahrscheinlich, über Namensmuster der Dokumente (bzw. ihrer Pfade) entsprechende Caching-Klassen zu bilden und das Problem mit einer Handvoll regulärer Ausdrücke anzugehen.

Viele Grüße
      Michael