Codecandies

Das Weblog von Nico Brünjes.

Conditional comments, wenige Requests

Ich halte conditional comments für eine Lösung, CSS direkt auf den Internet Explorer und seine verschiedenen Hydra Versionen zu werfen. Ob aber die typische Art wie sie benutzt werden wirklich effizient ist, daran sind mir in letzter Zeit Zweifel gekommen.

Zuviele Stylesheets

Zunächst scheint es eine gute Idee zu sein, jedem M$-Browser sein eigenes Stylesheet zu geben, andersherum gesagt, die guten Browser mit deren Download nicht zu belasten. Folgendes Szenario zeigt aber recht eindrucksvoll, dass das ggf. eine Menge Maintainanceaufwand wartet:

[syntax,conditionalcomments.html,HTML]

Extrem, aber da kommt einiges zusammen. Denn neben den ganzen normalen CSS-Dateien, kommen dann noch pro unterstütztem IE noch weitere hinzu. Diese sind zwar oft erstaunlich klein, aber da kann man schon mal ins Suchen kommen, so im Laufe der Zeit…

Ein anderes Extrembeispiel dagegen sieht so aus:

<link rel="stylesheet" href="http://codecandies.de/wp-content/themes/aalborg/style.css" type="text/css" />

Das ist hier aus dem Blog (Code von einigen Plugins habe ich jetzt aus Demonstrationszwecken mal unterschlagen). Aber wichtiger: ich nutze ebenfalls conditional comments und habe spezielle Styles fürs Drucken (die für Handhelds fehlen noch…). How come?

Conditional body comments

Für die IEs habe ich mir bei Paul Hammond die conditional classnames abgeschaut. Das sieht hier so aus:
[syntax,conditionalclassnames.html,xmll]

Statt mit unterschiedlichen Stylesheet-Links zu hantieren, bekommen die verschiedenen Browser eine unterschiedliche Klasse im body-Tag zugeteilt. Damit kann man die Spezialanweisungen z.B. für IE6 direkt ins normale Stylesheet schreiben. Hier ein Beispiel:

[syntax,iecssbeispiel.css,css]

Die einen sagen, alles schön voneinander trennen, ich sage: alles schön beisammen halten. Einfach so, aus Erfahrung bei einigen Projekten. Das nun etwas größere Stylesheet wird ja meist eh‘ gecached, dafür spart man aber mindestens einen zusätzlichen Request.

Und Druckstylesheets?

Weitere Request spart man sich, wenn man die Stylesheets für Drucker, handhelds etc. auch gleich mit in ein solches Multistylesheet packt. Das geht so:

[syntax,multistyles.css,css]

Aber das kennt ihr ja sicherlich alle schon… Jedenfalls sorgen diese Methoden dafür, dass man zwar ein größeres CSS-File bekommt, dafür aber alles an einem Ort hat. Selbst wenn das Projekt so groß wird, dass man doch mehrere (bspw. thematisch getrennte) Stylesheets braucht, mit diesen Methoden bleiben auch diese schön übersichtlich und inhaltlich begreifbar.

20 Kommentare zu “Conditional comments, wenige Requests”

    1. Im Bezug auf Requests sehe ich das als Vorteil, im Bezug auf Umfang und Übersicht empfinde ich eine Trennung der einzelnen Stylesheets optimal. Ich trenne auch die print- und mobile-StyleSheets und lade nur dann, wenn sie auch benötigt werden.

    2. Habe bis vor kurzem genau so gemacht. Hat aber, zumindest im großen etwas heterogenen Team nicht sehr gut funktioniert. Ebenfalls haben sich die IE-Stylesheets bei sehr großen Umgebungen nicht bewährt.

      Deswegen wollen wir einen anderen Weg gehen: die Styles werden modularisiert und über Buildscripte zu einer Datei zusammengefasst (und geschrumpft). Da macht es Sinn alles zu einem Modul gehörige, inkl. Printstyles und IE-targeted styles in einer Moduldatei zu haben.

      Für mein kleines Block ist die Lösung aber ebenfalls praktisch, und für WP-Templates sowieso… 😉

    3. ich habe sehr gute Erfahrungen mit get_browser gemacht. Damit verpasse ich dem body-Tag eine ID, die mich auch zwischen firefox0.5 und firefox3 unterscheiden lässt.

      Außerdem bleibt mein Quellcode schlank und ich erspare den richtigen Browsern die unsäglichen Kommentare

    4. Ja das ist so eine Sache mit dem Browsersniffing. Könnte man ja auch mit Javascript machen beispielsweise. Und für ein WordPress-Blog käme get_browser sicherlich auch in Frage.

      Nebenbei: browsersniffing ist auch nicht gerade angesehen. Properitäre Microsoft-Technologien aber natürlich auch nicht. 😉

      Das fällt aber in anderen Arbeitsumgebungen, mit denen ich zu tun habe kategorisch aus. Dort steht weder PHP zur Verfügung, noch darf an einer solchen Stelle mit JS gearbeitet werden.

    5. Solange Dein CMS das zuläßt ist die Idee nicht schlecht. ich habe mir sagen lassen, daß Typo3 das nicht zuliesse, weil es selber eigenen Müll in den body-Tag reinschreibt. Das Template wird dadurch nicht besser lesbar und das Codehighlighting im Editor sicherlich getrübt. Seltsam: irgendwie brauche ich nie so viele Extrawürste für den IE6. daß ich dringend ein extra Stylesheet benötige. Und ich arbeite an großen Setien, nicht kleinen Blogs.

    6. Mit den Extra-Stylesheets habe ich bis dato zwecks Codesauberkeit gearbeitet. Das die nun übermäßig groß wären, hat ja nie jemand behauptet.

    7. @Jens Grochtdreis: Typo3 lässt das natürlich schon zu. Man kann jederzeit den head oder body-Tag beliebig erweitern.

    8. @Jens: In TYPO3 kann man den body-Tag über die TypoScript-Eigenschaften bodyTagCObject und bodyTag manipulieren.

      Man bräuchte die Conditional body comments noch nichtmal direkt ins HTML schreiben, sondern könnte die TypoScript-Bedingungen von TYPO3 selbst nutzen und je nach Browser unterschiedliche body-Tags ausgeben.
      Das könnte ungefähr so aussehen (ungetestet):
      http://pastebin.com/f642be2b5

      Aber unübersichtlich wirds durch die ganzen Hacks schon.

    9. Hmmm… wir arbeiten ja mit einem XSLT-Prozessor, der das XML aus unserem Contentstorage zur Laufzeit in HTML transformiert. 😉 Anyone?

      @Simon: thanx, habe Deine Kommentare zusammengelegt.

    10. Eine überlegenswerte Sache ist auch, komplett auf CCs zu verzichten. Jens Meiert hat hierzu einen interessanten Artikel geschrieben:

      http://meiert.com/en/blog/20070201/why-conditional-comments-are-bad-repeat-bad/

    11. Ja, den Artikel kenne ich. Drum auch der erste Teilsatz dieses Artikels: »Ich halte conditional comments für eine Lösung…«. Viel Kritik, die Herr Meiert äussert bezieht sich allerdings auch auf die Strategie der verschiedenen Stylesheets für verschiedene Browsertypen. Zumindest der Kritikpunkt wäre ja bei meiner Lösung eben obsulet.

      Natürlich nicht die anderen, durchaus berchtigten Kritikpunkte, die für mich aber einer idealen Vorstellungswelt entspringen, die derzeit nicht meiner Arbeitsrealität entspricht.

      Damit das nicht ausser Acht gerät: besser ist es überhaupt, wenn man keine Hacks und/oder CCs braucht.

    12. @Christoph: Was Jens Meiert geschrieben hat, entbehrt imho jeder praktischen Relevanz. Ein Artikel aus der Reihe „ich behaupte einfach mal, $xy einzusetzen ist böse“, ohne, dass es wirklich handfeste und unumstößliche Argumente dafür gibt. Und die Argumente, die er bringt, sind teilweise wirklich hanebüchen. Siehe auch hier.

    13. Ich bin auch für die Conitional Comments Methode, dennoch finde ich es eine Sauerei von Microsoft. So viele Menschen haben wegen einer Firma die eine Monopolstellung im IT Bereich hat nötige Probleme.

    14. Ich lass print und screen auch getrennt, den komischerweise wenn ich es in einer hab funktionieren manche scripte nicht mehr. warum? keine ahnung^^

    15. Ich habe diese Methode zwar noch nie eingesetzt, aber ich bleibe lieber bei der anderen Variante. Für mich ist es so übersichtlicher, da ich genau weiss, wo ich was habe.

    16. Harald Engels
      01.09.2009, 12:36 Uhr

      Separate CSS-Dateien können die Übersicht verbessern aber auch verschlechtern. Hier spielt der Aufbau und die logische Anordnung der Styles eine große Rolle.
      Freunde einer Vielzahl von CSS-Dateien können dem Problem der HTTP-Requests dadurch aus dem Weg gehen, indem Sie auf dem Server die CSS-Dateien via PHP zusammenfügen.