nicht angemeldet
Mehrere CSS Dateien
0 0 0 0 0 0 0 1 0 0 0 0
1 0 
suit
Mehrere CSS Dateien
Gunnar Bittersmannhi,
s. Thema, wann macht das denn Sinn, mehr als eine CSS-Datei zu linken?
Danke für Hinweise,
viele Grüße,
Horst Hagelschauer
--
Alles was ins Gesicht fliegt, geht ins Auge.
Alles was ins Gesicht fliegt, geht ins Auge.
-
Hallo
das kann verschiedene Gründe haben, z.B.
Übersichtlichkeit
Wenn eine CSS Datei zu groß ist wird sie unterteilt. So können z. B. Formatierungen für die Navigation oder für Formulare ausgeliedert werden
Ausgabegerät
Die CSS-Angaben für Bildschirm oder Drucker oder Handys können getrennt gespeichert werden
Browserfixe
Die Korrekturen für bestimmte Browser können ausgelagert werden
Gruss
MrMurphy
-
Hallo,
gerade in groeszeren Projekten kann es recht schnell unuebersichtlich werden mit den Stylesheets. Daher bevorzuge ich bei der Entwicklung mit mehreren CSS-Files zu arbeiten. Teilweise koennen das gut bis zu 20 Stueck werden - je nach dem wie unterschiedlich das Projekt gestrickt ist, wieviel Teilbereiche es gibt, die miteinander nichts zu tun haben.
Beim Deployment lasse ich dann ein Script laufen, welches die CSS-Files zu einem einzigen File zusammenfuegt (und dabei gleichzeitig auch von Leerzeichen und Kommentaren entfernt).
So hat man in der produktiven Version eine bessere Performance, aber gleichzeitig beim Entwickeln eine gute Uebersicht.
MfG
Mirko-
hi,
So hat man in der produktiven Version eine bessere Performance, aber gleichzeitig beim Entwickeln eine gute Uebersicht.
Vielen Dank bisher! Was die Größe betrifft: Ich bin gerade dabei, einen kleinen Webbaukasten zu entwerfen, da wird es oben ein horizontales Menu geben, so wie auf meiner Seite, nur etwas kleiner
Startseite Impressum [Suche u.a. Optionales] Hauptindex
und unter dem Hauptindex kann dann der Editor/Redakteur eine Baumstruktur entwickeln mit Ordnern, in denen HTML-Dokumente abgelegt sind. Also ersteinmal nichts Größeres, ich denke, dass dafür eine CSS-Datei reichen sollte, damit alles einheitlich aussieht...
Viele Grüße,
Horst Hauptmann--
Egal wie falsch, Hauptsache einheitlich.-
Hi,
[...] ich denke, dass dafür eine CSS-Datei reichen sollte, damit alles einheitlich aussieht...
dies sollte auf jeden Fall das Ziel sein, da jede Ressource vom Client einzeln abgeholt werden muss und dies nur bedingt parallelisierbar ist. Je mehr CSS-Ressourcen Du einbindest, umso länger muss der Nutzer warten, bis die Darstellung beginnt (oder hat schlimmstenfalls den berüchtigten Flash Of Unstyled Content). Mit JavaScript-Ressourcen verstärkt sich dieser Effekt übrigens, da sie in der Praxis _gar nicht_[1] parallelisiert geladen werden können.
Und wie Mirko schon schrieb: Während der Entwicklung können und sollten es durchaus mehrere Dateien sein. Ein modularer Aufbau macht sich durchaus bezahlt. Mir ist nur nicht klar, wie er mit nur 20 Dateien auskommt ;-)
Cheatah
[1] Bzw. nur mit Wegen, die das ganze effektiv noch langsamer und schwerer zu handhaben machen.
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hi,
[...] ich denke, dass dafür eine CSS-Datei reichen sollte, damit alles einheitlich aussieht...
dies sollte auf jeden Fall das Ziel sein, da jede Ressource vom Client einzeln abgeholt werden muss und dies nur bedingt parallelisierbar ist. Je mehr CSS-Ressourcen Du einbindest, umso länger muss der Nutzer warten, bis die Darstellung beginnt (oder hat schlimmstenfalls den berüchtigten Flash Of Unstyled Content). Mit JavaScript-Ressourcen verstärkt sich dieser Effekt übrigens, da sie in der Praxis _gar nicht_[1] parallelisiert geladen werden können.
Danke für die Info, es gibt ja immer so Empfehlungen... also ich hab mir gedacht, dass für den kleinen Webbaukasten (ich nenne den mal Pico), das CSS-Zeugs aus der Konserve kommt und per <style type="text/css"> eingebunden wird, genau wie der Body per <body>. Ergo gar keine extra Datei, contents (bodies) und css kommt aus einer kleinen DB, die Konserve.
Und wie Mirko schon schrieb: Während der Entwicklung können und sollten es durchaus mehrere Dateien sein. Ein modularer Aufbau macht sich durchaus bezahlt.
Die Löcher zum aufbohren sind im System 'Pico' schon vorgezeichnet. Das wird alles modular und scalierbar ohne Klimmzüge ;-)
Hotti
--
Mist, Gewitter, ich mach mal PC aus und geh Essen..
-
Hi,
Danke für die Info, es gibt ja immer so Empfehlungen... also ich hab mir gedacht, dass für den kleinen Webbaukasten (ich nenne den mal Pico), das CSS-Zeugs aus der Konserve kommt und per <style type="text/css"> eingebunden wird, genau wie der Body per <body>. Ergo gar keine extra Datei, contents (bodies) und css kommt aus einer kleinen DB, die Konserve.
diese Daten sind somit nicht cachebar und müssen auf *jeder* Seite erneut mitgeladen werden. In fast allen Fällen ist das eine ziemlich schlechte Idee.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
hi,
Danke für die Info, es gibt ja immer so Empfehlungen... also ich hab mir gedacht, dass für den kleinen Webbaukasten (ich nenne den mal Pico), das CSS-Zeugs aus der Konserve kommt und per <style type="text/css"> eingebunden wird, genau wie der Body per <body>. Ergo gar keine extra Datei, contents (bodies) und css kommt aus einer kleinen DB, die Konserve.
diese Daten sind somit nicht cachebar und müssen auf *jeder* Seite erneut mitgeladen werden. In fast allen Fällen ist das eine ziemlich schlechte Idee.
Cache: Last-Modified, jede Seite kriegt diesen header. CSS ist in jeder Seite drin, warum sollte das nicht gechached werden??? Status 304 wird per HTTP-Header ausgehandelt. Oder wo hast Du da Bedenken?
Hotti
-
Hallo,
die CSS-Angaben im header einer html-Seite werden nicht gecached.
Es können nur ganze Dateien gecached werden, nicht Teile von ihr. Wird demnach eine neue html-Datei geladen ist die Seite für das Betriebssystem neu und wird komplett geladen und ausgewertet. Es sei denn, die html-Datei wurde bereits einmal geladen und befindet sich noch im Cache-Speicher, darum geht es hier aber nicht.
Das Betriebssystem sowie der Browser gehen den Inhalt der Datei nicht durch und vergleichen, ob er mit dem Inhalt einer Datei im Cache übereinstimmt. Das wäre ja auch vollkommen albern, da dazu ja auch zunächst die neue Datei komplett geladen werden müsste.
CSS-Angaben werden demnach nur aus dem Cache gelesen, wenn sie sich in einer externen CSS-Datei befinden.
Wobei die Größe einer CSS-Datei das Laden bzw. Anzeigen einer Datei im Browser sowieso kaum beeinflußt. Jedes Bild bzw. Foto ist meist größer als alle gleichzeitig geladenen CSS-Dateien zusammen. Viel schlimmer für die Performance sind unsinnige oder gar ungültige CSS-Angaben, die die Browser so gut wie möglich auszugleichen versuchen.
Gruss
MrMurphy
-
Hallo,
die CSS-Angaben im header einer html-Seite werden nicht gecached.
Oops, <head> </head> gehört zur html-Seite, wenn die gecached wird, wird das da oben auch.
Es können nur ganze Dateien gecached werden, nicht Teile von ihr.
Sag ich doch. CSS+HTML ist _eine_ ganze Datei, die kann in den Cache.
Das Betriebssystem sowie der Browser gehen den Inhalt der Datei nicht durch und vergleichen, ob er mit dem Inhalt einer Datei im Cache übereinstimmt.
Das OS hat damit nüschd zu tun. Zum Cachen geht ETag oder Last-Modified, das ist Sache der Browser und des Webservers.
CSS-Angaben werden demnach nur aus dem Cache gelesen, wenn sie sich in einer externen CSS-Datei befinden.
Hoppla, bei einer miss-Konfiguration des Webservers wird jede gelinkte Ressource jedesmal neu geladen am Cache vorbei. Von ungeschickten Browsereinstellungen am abgesehen.
Hotti
-
-
Hi,
Cache: Last-Modified, jede Seite kriegt diesen header. CSS ist in jeder Seite drin, warum sollte das nicht gechached werden???
die Seite wird gecached, nicht Teile von ihr. Die nächste Seite mit dem selben CSS-Code wird vollständig neu geladen.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hi,
Cache: Last-Modified, jede Seite kriegt diesen header. CSS ist in jeder Seite drin, warum sollte das nicht gechached werden???
die Seite wird gecached, nicht Teile von ihr. Die nächste Seite mit dem selben CSS-Code wird vollständig neu geladen.
Ahh, jetzt verstehe ich, wie Du meinst. Wenn jede HTML-Seite einen Link auf x.css hat, wird x.css nur einmal geladen, für alle anderen Seiten dann aus dem Cache geholt. Ich hab mir das grad mal mit Wireshark angeguckt, das ist so.
Wenn ich das CSS Zeugs hingegen in jede Seite reintu, wird das erst dann mitgechached, wenn die Seite selbst (im Ganzen) gekäschd wird. Logo ;-)
Hotti
-
Hi,
Ahh, jetzt verstehe ich, wie Du meinst. [...]
jepp, genau so :-)
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hi,
Ahh, jetzt verstehe ich, wie Du meinst. [...]
jepp, genau so :-)
Hajo, weil das so schön ging heute, hab ich diesen Teil für meinen kleinen Webbaukasten schonmal fertisch:
http://rolfrost.de/cgi-bin/pico.cgi?menu=2
Ergo: CSS-Zeugs raus aus den HTML-Dateien, da gibts Dateien und Basda. Dasselbe in hellgrün für JS-Zeugs.
Schönen Abend (Rest),
Horst-
@@hotti:
nuqneH
[…] schonmal fertisch:
http://rolfrost.de/cgi-bin/pico.cgi?menu=2Fertisch? Den XHTML-Fehler verrät dir der Validator. Und deine Sprachangaben sind falsch.
Ergo: CSS-Zeugs raus aus den HTML-Dateien, da gibts Dateien und Basda. Dasselbe in hellgrün für JS-Zeugs.
Hellgrün heißt aber nicht gleich. JS-Zeugs wird sinnvollerweise an anderer Stelle eingebunden. [PERFORMANCE-BP2]
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
hi,
Fertisch? Den XHTML-Fehler verrät dir der Validator.
Hat der mir schon längst verraten. Gähn....
Das Zeugs hat alles Zeit bis nach meinem nächsten Umzug. Bis dahin fließt noch viel Wasser den Rhein hinunter ;-)
Gute Nacht,
Horst Siebenschläfer (Bilch)-
@@hotti:
nuqneH
Das Zeugs hat alles Zeit bis nach meinem nächsten Umzug. Bis dahin fließt noch viel Wasser den Rhein hinunter ;-)
Bis dahin willst du Clients (i.e. auch Suchmaschinen) mit falscher Sprachinformation versorgen?
Warum machst du dir die Mühe, eine Sprache anzugeben, gibst dann aber nicht die richtige an?
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)
-
-
-
Hallo Horst,
<meta http-equiv='Content-Type' content='text/html; charset=UTF-8' /> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />Was soll das genau bringen?
Grüße
Brillo
-
-
-
-
-
-
-
-
-
-
-
Übersichtlichkeit
Ein File ist übersichtlich. Mehrere sind es nie.
Wenn eine CSS Datei zu groß ist wird sie unterteilt. So können z. B. Formatierungen für die Navigation oder für Formulare ausgeliedert werden
Und was hast du dadurch gewonnen?
Ausgabegerät
Was hast du gewonnen?
FX fordert ein media print css an, auch wenn es noch nicht verwendet wird.Die CSS-Angaben für Bildschirm oder Drucker oder Handys können getrennt gespeichert werden
schreckliche redundanz
Browserfixe
Die Korrekturen für bestimmte Browser können ausgelagert werdenfixe dein Konzept!
Es gibt sowohl die Möglichkeit, von CSS Selektoren als auch via CC gesetzte Identifikatoren.Ich kenne nur einen Grund, warum es zum allgemeinen CSS ein besonderes CSS geben kann
Ein Subset der Seiten verwendet Markup, die aus einem selten gebrauchten Modul entspringen.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Übersichtlichkeit
Ein File ist übersichtlich. Mehrere sind es nie.
Sicher:
- 1 File für die Struktur
- 1 File für das Schriftbild
- 1 File für Formulare
- 1 File für Tabellen
- 1 File für generisches Zeug
...
Diese werden serverseitig zusammengebaut.
Wenn ich nun etwas bei den Formularelementen ändern möchte, muss ich nicht in einem 1200-Zeilen-File suchen :p
Und was hast du dadurch gewonnen?
Übersichtlichkeit.
Die Korrekturen für bestimmte Browser können ausgelagert werden
fixe dein Konzept!
Ersetze "bestimmte Browser" durch ältere Internet Explorer, dann ist das Konzept gut :p
Es gibt sowohl die Möglichkeit, von CSS Selektoren als auch via CC gesetzte Identifikatoren.
Zwei herangehensweisen die man nicht so dogmatisch betrachten sollte.
Ich kenne nur einen Grund, warum es zum allgemeinen CSS ein besonderes CSS geben kann
Wie wäre es mit einer Seite mit verschiedenen Farbschemata - je nach Kategorie wird ein zusätzliches CSS-File ergänzt welches entsprechend andere Farben enthält.
Alternative dazu ist natürlich eine Klasse oder ID im body-Element und einfach wieder Selektoren verwenden. Für mich ist beides egitim.
Ein Subset der Seiten verwendet Markup, die aus einem selten gebrauchten Modul entspringen.
Umsomehr ein Grund, das in ein eigenes File zu packen - wenn man 200 Unterseiten hat und für eine spezielle Bildergalerie oder sonstwas ein paarhundert Zeilen extra CSS benötigt, wird man das wohl nicht bei jeder Seite mitschleifen und den Parser gängeln.
-
@@suit:
nuqneH
Wenn ich nun etwas bei den Formularelementen ändern möchte, muss ich nicht in einem 1200-Zeilen-File suchen :p
Firebug zeigt Zeilennummern an; ein vernünftiger Editor auch. :-b
Und wieso hat dein Smiley keine Nase?
Aber ja, Stylesheet-Module können sinnvoll sein. Eigene Module für bestimmte Strukturen …
Ersetze "bestimmte Browser" durch ältere Internet Explorer, dann ist das Konzept gut :p
… aber nicht eigene Module für bestimmte Browser. (Und schon gar nicht als getrennte Ressourcen ausliefern.)
Alternative dazu ist natürlich eine Klasse oder ID im body-Element und einfach wieder Selektoren verwenden. Für mich ist beides egitim.
Du meinst „egal“? ;-)
Ich würde diese Variante (alle Farbschemata in einem Stylesheet) bevorzugen. Hängt aber auch vom Umfang ab.
Ein Subset der Seiten verwendet Markup, die aus einem selten gebrauchten Modul entspringen.
Umsomehr ein Grund, das in ein eigenes File zu packen - wenn man 200 Unterseiten hat und für eine spezielle Bildergalerie oder sonstwas ein paarhundert Zeilen extra CSS benötigt, wird man das wohl nicht bei jeder Seite mitschleifen und den Parser gängeln.
Yep.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Firebug zeigt Zeilennummern an; ein vernünftiger Editor auch. :-b
Wenn das mal kein Argument ist - ich schreibe in zukunft also sämtliches Zeug nur noch in gigantische Einzelfiles mit viele if-"Schleifen" :p weil: 1 File mit Zeilennummern reicht ja.
Und wieso hat dein Smiley keine Nase?
Damit er nichts hinrotzen kann und immer schon sprechen muss :)
… aber nicht eigene Module für bestimmte Browser. (Und schon gar nicht als getrennte Ressourcen ausliefern.)
Wie du meinst - wie wir schon so oft hatten: je nach Anwendungsfall belästige ich vernünftige Browser nicht mit dem IE-Müll - eben bei Umfangreichen korrekturen/Änderungen. Für kleine Änderungen sind Hacks aber ok.
Du meinst „egal“? ;-)
;)
Ich würde diese Variante (alle Farbschemata in einem Stylesheet) bevorzugen. Hängt aber auch vom Umfang ab.
Und davon wie oft welche Farbschemata in welchem Umfang gebraucht werden - siehen unten.
Umsomehr ein Grund, das in ein eigenes File zu packen - wenn man 200 Unterseiten hat und für eine spezielle Bildergalerie oder sonstwas ein paarhundert Zeilen extra CSS benötigt, wird man das wohl nicht bei jeder Seite mitschleifen und den Parser gängeln.
-
-
-