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;
}
/* IE 6, IE 7 and 8 */
body #ie6andie7andie8{
display:block\9;
}
/* IE 8 only */
body #ie8{
display:block\9;
*display: none; /*overrule for ie6 and ie7 which also read this rule*/
}
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...
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 ...
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...
