english2009-02-01 CSS Voodoo - Die dunkle Kunst der CSS Hacks
CSS Hacks sind etwas über das man nur hinter verschlossenen Türen redet. Entwickler schämen sich sie zu benutzten. Sie sind schlecht, sie sind böse und man sollte sie wirklich überhaupt nicht benutzen...
... aber manchmal gibt es einfach keinen anderen weg - und dann verkauft man seine Seele an den Hack-Teufel...
Seit ich angefangen habe bei Yahoo! zu arbeiten habe ich aus Performance Gründen (weniger HTTP Abfragen) aufgehört Conditional Comments zu benutzen. Ich musste mich also plötzlich wieder mit den üblichen Hacks für Internet Explorer vertraut machen die ich schon völlig vergessen hatte.
Seither bin ich fast nie in Situationen geraten in denen sich auch andere Browser schlecht benommen hätten - aber es kam vor (immerhin sind sie alle nur Software und, wie wir alle wissen, gibt es keine Software ohne Bugs...).
Es folgt der aktuelle Stand meiner CSS Hack Sammlung. Man kann sich eine funktionierende Demo auf meiner CSS Hacks Beispielseite anschauen. Bitte nur mit besonderer Vorsicht benutzen und tu dir selbst den Gefallen und probier ALLES ERDENKLICHE BEVOR du aufgibst und sie selber benutzt.
In meiner Demo habe ich Absätze, die den Namen der Browser enthalten, die mit den Hacks angesprochen werden können, standardmäßig ausgeblendet.
body p { display: none; }
Dann benutze ich die Browser spezifischen Hacks um die jeweiligen Browsernamen wieder sichtbar zu machen:
Internet Explorer
/* IE 6 only */
body #ie6 {
_display: block;
}
/*IE 6 and IE 7 */
#ie6andie7 {
*display: block;
}
/* IE 7 only */
html > body #ie7 {
*display: block;
}
/* IE6, IE 7, IE 8 and IE 9 */
body #ie6andie7andie8andie9{
display:block\9;
}
/* IE 8 */
body #ie8{
display:block\9;
*display: none; /* overwrite for ie6 and ie7*/
}
body #ie8:nth-of-type(1n){ /* overwrite for ie9 which still also reads the \9 hack */
display:none;
}
/* IE 9+ */
body #ie9:nth-of-type(1n){ /* CSS3 Selector that is interpreted by many modern Browsers including IE9*/
display:block\9; /* Hack to specify Internet Explorers including 9 so we exclude FF, webkit, etc */
}
Firefox
#firefox2, x:-moz-any-link {
display: block;
*display: none; /*overrule for ie6 and ie7 which also read this rule*/
}
/*Firefox 3 only (for Firefox 2 only use the rule above and this to overwrite for Firefox 3*/
#firefox3, x:-moz-any-link, x:default {
display: block;
*display: none; /*overrule for ie6 and ie7 which also read this rule*/
}
/* Firefox 3.5+ */
BODY:nth-of-type(1) #firefox3_5, x:-moz-any-link, x:default {
display: block;
}
Safari
/* Safari */
@media screen and (-webkit-min-device-pixel-ratio:0) {
#safari {
display: block;
}
}
Opera
/* Opera */
@media all and (-webkit-min-device-pixel-ratio:10000), not all and (-webkit-min-device-pixel-ratio:0) {
head~body #opera {
display: block;
}
}
So - jetzt fühle ich mich schmutzig und gehe duschen...
update 2010-07-23 jetzt Support für Firefox 3.5+
update 2010-08-27 jetzt Support für Internet Explorer 9+
Comments (15)
Trackbacks
Den IE8 direkt ansprechen
Während meines letzten Projektes hatte ich bei einer Sonderform von Formularen die Notwendigkeit, für so ziemlich jeden Browser eine Sonderlösung in einem Detail zu schreiben. Ich mußte FF und IE 6 bis 8 auseinanderhalten. IE6 und ...
Während meines letzten Projektes hatte ich bei einer Sonderform von Formularen die Notwendigkeit, für so ziemlich jeden Browser eine Sonderlösung in einem Detail zu schreiben. Ich mußte FF und IE 6 bis 8 auseinanderhalten. IE6 und ...
Weblog: F-LOG-GE
Tracked: Apr 27, 19:10
Tracked: Apr 27, 19:10
Comments
Kennst Du einen Filter der Konquerer isolieren kann?
funktioniert (im Moment)nur im Konqueror.
Unter Windows passts.
So ward ich gezwungen für Linux noch ne extra CSS zu machen. die genau diese 1 (eine!) Problem ausbügelt.
Ist zwar mit PHP kein Aufwand, aber es nervt...
Jetzt muss ich aufpassen ob mit dem nächsten Realease der Bug nicht auf einmal behoben ist. Verschiedene Linux-Versionen detektieren werd ich mir definitiv sparen.
Gruß
Arno
Wir haben unser CSS sehr granular in viele Komponenten aufgeteilt und halten auch die Browserspezifischen Hacks in extra Dateien vor. Erst beim Push auf den Server werden CSS und Javascript-Dateien in einem Build-Prozess in wenige große Dateien kombiniert. Dadurch haben wir das beste aus beiden Welten: Übersicht und Performance
Zu den Opera- und Safari-Hacks: Wenn die nächste Version nachgearbeitet hat und den zu korrigierenden Bug nicht mehr zeigt, ist der Hack kontraproduktiv und muss entfernt werden, richtig? Die Strategie ist dann, nur für den jeweils letzten Safari und Opera zu hacken und vorherige Versionen außen vor zu lassen? Hmm. Wenn die vernachlässigbar sind, dann sind es doch auch diese Hacks?
Ich glaube immer mehr, dass diese ganze Korrigiererei einer Perfektion entgegenstrebt, die für das Medium nicht angebracht ist. Und dass man das mehr für die Coworker tut als für die User.
Dass der User eine Pixelperfektion will, ist bloß eine Annahme, sicher ist nur, dass er eine funktionierende Seite will.
Die Frage an die Coworker ist, ob es nicht auch ein hohes Gut ist, wenn man mit weniger Perfektion performanteren, verlässlicheren und wartbareren Code schafft.
Ich hoffe du merkst, dass du bei mir offene Türen einrennst. Ich bin definitiv kein Freund von Hacks und schon erst recht nicht von dem Irrglauben an pixelperfekte Layouts. Dankenswerterweise musste ich die genannten Hacks bisher jeweils nur ein einziges mal tatsächlich einsetzen (natürlich immer mit Ausnahme der Internet Explorer Hacks die leider zum täglichen Handwerk gehören...)
Interessant auch das Argument der schlechteren "Wartbarkeit" wie hier vertreten http://meiert.com/en/blog/20080824/to-be-clear/
Ansonsten Danke für die nützliche Übersicht an Hacks...
Ich stimme im großen und ganzen überein mit deinen Ansichten und wollte (auch wenn unpassend an dieser Stelle) ein dezentes Lob zu der Tatsache loswerden, dass du sowohl englisch als auch deutsch parallel veröffentlichst; leider immer noch zu selten im world wide web of wonders. Danke schön für die Mühe!
Aber zum Thema CSS ...
und insbesondere HÄCKXKXXSSSSSSSsssssssssssssss. sss. SSss.. s.
Ähem, mal eine Fangfrage, in einem deiner Slides hast du so schön beschrieben: "Du nutzt Frameworks aus Prinzip nicht? Du solltest es tun!" oder so ähnlich. Du hast mitten ins Herz getroffen damit, trotz Euphorie über die Möglichkeiten, missfällt mir dass es nicht meine Sprache ist die ich nutze wenn bspw. jQuery mein Auge streift.
Um auf den Punkt zu kommen:
Du scheinst mit Frameworks vertraut, jQuery bspw. verspricht CSS3-Einsatz unter allen möglichen jQuery & Browser -Versionen, sprich eine Hack/Patch/Flickenteppich-Sammlung wird da schon (sinnvollerweise in JavaScript clientseitig) angewand, richtig?
Wenn das so ist, wieso dann manuell deine Hacks einsetzen?
Ohne auf die Antwort gespannt zu sein, folgende Frage ergänzt:
Was ist der (deiner Meinung nach) resourcen-schonendste Weg deine Hacks in Form eines JavaScript-Loaders unterzubringen, der bei einem Template, dass mit abwärtskompatiblem HtML-5-MarkUp aufläuft via StyleSheet-Ersatz per JavaScript arbeitet.
Einfacher gefragt:
Siehst du eine elegante Möglichkeit mit Hilfe der Hacks eine Analyse via JavaScript durchzuführen, die schnellstmöglich die Best-Practice für den Folge-Aufbau der Seite findet?
Hmm, ich hoffe ich hab' mich kompliziert genug ausgedrückt.
Hoffe Anregung zum Denken gegeben zu haben und würd' mich über Antwort freuen.
Danke für's Lesen.
Claudius Raphael Paeth, A3lyphe
boss@a3lyphe.net
every breaking atom living ???
P.s.: So'n Browser is nich nur'n Pferd, das is' ne störrische Stute. So'n Conditional is vergleichbar mit Barren. Hacks sind eher ein dezentes von hinten aufzäumen um den Clapper in die richtige Richtung zu treiben; so seh' ich das. Nur hätt ich gern 'ne Mini-Micro-Blackbox für den Spaß, die sich nicht auf Libraries verlässt.
Also, lieber mit'm Handy in den Doppeldecker als Interkontinentalflug mit'm Airbus ...
Danke für die Aufmerksamkeit.
Ideen?
Die Hacks die ich hier zeige sind für CSS und sollten daher auch nicht von Javascript abhängig sein.
Ich rate grundsätzlich davon ab zu versuchen Styling mit Javascript zu fixen (daher kollidiert das auch nicht mit jQuery und Konsorten). So rate ich auch ab zu versuchen die CSS hacks via JS nachzuladen. CSS Hacks gehören einfach zum restlichen CSS (Du willst ja nicht, dass die Seite erstmal fehlerhaft dargestellt wird um sich dann nach kurzer ladezeit zu korrigieren. Das wäre kontra produktiv.
Hope it helps
