Die richtige Hack-Strategie

Browser sind fehlerhaft. Man kann eine Seite so exakt nach den Standards entwickeln wie man möchte, es werden immer Fehlinterpretationen vorkommen. Je älter die Browser sind, desto eher ist das der Fall. Deshalb ist es wichtig, eine Strategie zu haben, wie man mit den Fehlern der Browser umgeht. Dabei ist das zielgenaue Treffen des Browsers genauso wichtig, wie die Zukunftssicherheit. Und ganz nebenbei sollte man gerade bei Fehlerbeseitigungen an eine verständliche Kommentierung denken. So kann man selber, so können andere später die gemachten Korrekturen verstehen.

Zielgenauigkeit ist wichtig, damit exakt nur der gewünschte Browser zur Korrektur gebracht wird, nicht noch ein anderer, der den angepeilten Fehler überhaupt nicht hat. Zukunftssicherheit schlägt in die gleiche Kerbe und ist gerade bei der Nutzung der klassischen Hacks ein Problem. Denn es ist nicht gesagt, dass eine zukünftige Browserversion nicht auch über diesen Hack ansprechbar ist. Das entwickelt sich dann zu einem Problem, wenn der mit dem Hack zu begradigende Fehler in der neuen Browserversion behoben wurde.

Meiner Meinung nach ist es müssig darüber zu streiten, ob man Hacks gegen Browser anwenden solle. Da ich dem Endkunden eine möglichst störungsfreie Webseite präsentieren möchte, muss ich in irgendeiner Form die Fehler der einzelnen Browser ausgleichen. Das tue ich mit Hacks der unterschiedlichen Art. Der Endkunde kann nichts dafür, dass sein Browser fehlerhaft ist.

Mathias Bynens hat eine sehr umfangreiche und interessante Betrachtung über Hacks geschrieben. Sie ist nicht vollständig, bietet aber die wichtigsten Muster. Auch die Kommentare sind teilweise lesenswert. Sein Artikel verbreitet allerdings den Eindruck, nur der IE sei das Ziel von Hacks. Dem ist nicht so, auch wenn der IE ganz klar führend ist.

Ich persönlich sortiere nur die Hacks für IE6 und 7 in eine eigene Datei. IE8 und 9 müssen viel seltener korrigiert werden. Das mache ich dann mit speziellen Schreibweisen in der normalen CSS-Datei. Sehr hilfreich ist dabei die immer wieder aktualisierte Übersicht von Dirk Ginader.

Interessant fand ich, dass offenbar die von Paul Irish eingeführte Methode, Conditional Comments um das HTML-Element herumzupacken, im IE9 einen echten Nachteil hat. Das betrifft somit alle Nutzer on HTML5-Boilerplate.
Die Conditional Comments werfen den IE9 in den Kompatibilitätsmodus. Man kann dies nur serverseitig in einer htaccess-Datei korrigieren, weil das sonst nutzbare META-Element keine Conditional Comments vor sich in der Codereihenfolge mag. (Danke, Microsoft! Beides gibt es nur wegen Euch und ihr schafft es nicht, beides störungsfrei zu kombinieren.)

Hacks sind in meinen Augen ein leider notwendiger Teil unserer Arbeit. Der Artikel von Mathias ist eine super Ausgangslage, sich intensiv Gedanken über sein eigenes Hackmanagement zu machen und vielleicht noch unbekannte Strategien kennenzulernen.

7 Responses to “Die richtige Hack-Strategie”

  1. Anselm H. sagt:

    Scheinbar hast du nicht ganz genau gelesen und getestet. Die H5BP-CCs werfen den IE9 nicht in den Kompatibilitätsmodus, sondern initieren lediglich, dass der IE9 den Kompatibilitätsmodus-Button anzeigt. Dieser ist jedoch erst nach einem Klick darauf aktiv.
    Abhilfe (auf die schnelle würde ein leerere CC in Line 1 vor dem Element schaffen. Aber das ist suboptimal.

    Es wird hierüber schon heftig diskutiert und man versucht mit einer .oldie-Klasse Abhilfe zu schaffen: https://github.com/paulirish/html5-boilerplate/commit/e5e057e53815ed55f4ecfaef3057bf2940c7c0b2

    Ansonsten übrigens ein sehr guter Artikel 🙂

    • Jens Grochtdreis sagt:

      Okay, der Button wird aktiviert. Wer das sieht, klickt vielleicht drauf. Jedenfalls sollte eine solche Reaktion überhaupt nicht kommen, oder? Ich nutze diese Methode nicht, deshalb ist es mir relativ egal. Es zeigt aber, dass alle Lösungen leider mit potentiellen Nachteilen verbunden sind, die irgendwann später mal erscheinen. So wird es uns nicht langweilig, das ist mein einziger Trost.

  2. Schepp sagt:

    Korrektur die CCs zwingen den IE nicht in den Kompatibilitätsmodus, sondern der IE wird durch ihren Einsatz dazu bewegt, dem Benutzer den Kompatibilitätsmodus offensiver anzubieten (per aufdringlichem Icon). Er traut dann sozusagen dem Braten nicht. Nachzuvollziehen mit den „F12“-Werkzeugen und dann in der ersten Zeile bei „Browser Mode“.

    Eine Abhilfe: Das CC-Verfahren nicht auf das html-, sondern das body-Element anwenden. Setzt aber voraus, dass man seine Stylesheets nicht abhängig von anderen body-Klassen macht, da der IE6 ja dummerweise keine Klassenkombinationen erkennt (à la body.ie6.downloadarea a {color: pink;}). Alternativ könnte man beim body auch auf IDs ausweichen. Oder man nutzt den Stars-Hack: * html body.downloadarea a {color: pink}. Macht es für Fremdbearbeiter aber weniger intuitiv und foolproof.

    Oder eben bei einem Apache-Server eben einfach folgende Zeilen in eine im Root liegende .htaccess Datei schreiben, die den IE beruhigen:

    <IfModule mod_headers.c>
    Header set X-UA-Compatible „IE=Edge“
    </IfModule>

  3. Abgesehen davon sehe ich gerade, dass Paul das Ganze im letzten commit in GitHub ziemlich umgeschmissen hat — es gibt jetzt nur noch eine CSS-Klasse .oldie für IE kleiner als 9.

  4. Dirk sagt:

    @Matthias,

    was macht eine allgemeine „oldie“ Klasse, eingefügt per CC überhaupt für einen Sinn? Die multiplen CC’s hatten ja den Anspruch (und den finde ich charmant), mit einfachen Klassen, statt vieser Hacks den IE adressieren zu können. Das ist mit der „oldie“ Klasse nicht zu erreichen.

    Und damit dürfen sich die Performance-Fetischisten mit den Standard-Fetischisten wieder herumstreiten, ob CSS-Hacks im regulären Stylesheet böser sind als ein zusätzliches, ggf. blockierendes Stylesheet für den IE. Ich habe da eine klare Meinung dazu, ich präferiere den zweiten Weg.

    Jens, Du hast Recht. Langweilig wird es nicht.

  5. Jens Grochtdreis sagt:

    Es ist interessant, wie schnell die Boilerplate-Entwickler reagiert haben. Allerdings finde ich die Lösung wie Dirk eher suboptimal. Der Klassenname ist witzig, ansonsten kann man auch gleich ganz normal ein CC hinzufügen, so wie Dirk das bei YAML macht. Eine einzige Klasse, die man dann wieder mit Voodoo-Hacks separieren muss, ist relativ witzlos. Die Vorherige Lösung hatte ja eindeutig ihren Charme. Bis Microsoft den IE9 rausbrachte …

  6. […] Mathias Bynens hat mal eine sehr schöne Auflistung verschiedener sinnvoller/etablierter CSS-Weichen für die IEs zusammengestellt. Dabei geht es um verschiedene Verfahren auf Conditional Comments Basis, sowie um klassische Parserhacks und was da zu bedenken ist. Mit Vor- und Nachteilen. Bei den HTML5 Boilerplate machern hat der Artikel zu hektischer Betriebsamkeit geführt, weil nämlich die dort praktizierte Variante ein paar der aufgelisteten Schönheitsfehler hatte. Jens und ich waren uns aber einig, dass die das bestimmt bald wieder zurückstellen werden. Außerdem hat Jens darüber auch gebloggt. […]