Doch wie kommt man auf den Transparenzwert “7f”? Der Farbwert des Filters ist in hexadezimaler Schreibweise verfasst. Im Falle der Farbe wird aus rgb(0,0,0) einfach #000000. Für den heexadezimalen Transparenzwert multipliziert man 255 (der maximale RGB-Wert) mit der Transparenz (also 255*0.5). In diesem Falle bekommen wir 127.5 als Ergebnis. Wir benötigen eine ganze Zahl und müssen uns deshalb für Auf- oder Abrunden entscheiden. Dann suchen wir einen Zahlenkonverter auf und lassen uns den Dezimalwert in einen Hexadezimalwert wandeln. “127″ wird dann zu “7f”, 128 wird zu “80″. Diesen Wert stellen wir an den Anfang des Hexadezimalwertes im MS-Filter.

Nutzer von Präprozessoren wie Sass haben hier natürlich die Nase vorn, denn sie können diesem die Rechenarbeit überlassen.

Anhand der Formatierung einer Überschrift und eines über einem Bild liegenden Textes kann man den grossen Vorteil von rgba sehr gut ermessen. Die jeweils erste Version ist mit opacity, die zweite dann mit rgba formatiert.

Bei den meisten neuen CSS3-Features ist dies auch nicht notwendig. Ich weiss schon vorher, dass die alten IE keine runden Ecken haben und kann das entweder hinnehmen oder ihnen ein Javascript oder sonst eine Lösung servieren. Kennt ein Browser rgba() nicht, nutzt er halt die hoffentlich vorher definierte alternative Farbe.

Für Hintergrundbilder gibt es zwei neue Eigenschaften namens “space” und “round”. Modernizr fragt auch die Unterstützung dieser Eigenschaften nach, die aktuell nur von Opera und IE9 und IE10 unterstützt werden. Auf der Testseite eines sehr interessanten Artikels zu diesem Thema steht am Ende, ob Modernizr eine Unterstützung dieser neuen Eigenschaften in meinem Browser festgestellt hat.

Es kam, wie der Titel dieses Artikels vermuten lässt: Chrome 15 dev sagt, er kenne diese Eigenschaften, unterstützt sie aber tatsächlich nicht. Also: nicht auf die Aussagen der Browser verlassen, sondern kritisch prüfen. Browser können lügen.

Ein wichtiger Teil dieses GBS war immer die Einteilung der Browser in verschiedene Qualitätsgrade. Diese zogen einen angepassten Grad der Test- und Korrekturleistung nach sich. Eingeteilt waren diese Grade vollkommen unintuitiv in A-, C- und X-Grade. Yahoo! hat seinem GBS nun wieder eine Überarbeitung spendiert und einige grundsätzliche Änderungen vorgenommen. In meinen Augen ist der GBS dadurch nutzlos geworden.

Eine gute Änderung ist die grundsätzliche Eliminierung von Betriebssystemen. Der GBS nennt nun nur bspw. den IE8, ohne ihn auf eine Windows-Version einzuschränken. Das ist gut und sinnvoll. Die wesentliche Änderung hingegen ist die Abschaffung der Grade. Angesichts des Titels “Graded Browser Support” ist das seltsam unpassend. Auf das allgemeine Entwickler-Hassobjekt IE6 bezogen bedeutet die Abschaffung der Grade, dass der IE6 in Tests mit einbezogen wird. Es ist aber jedem Projekt – der GBS ist zu allererst eine Yahoo!-interne Geschichte – selbst überlassen, welche Konsequenzen dieses Tests herbeiführen. Die einen liefern dem IE6 nur ungestyltes HTML aus, die nächsten versuchen so gut es geht die Optik moderner Browser nachzubauen.

Um die Verwirrung komplett zu machen, beschreibt Yahoo! auf seiner GBS-Seite noch ausführlich die einzelnen, jetzt abgeschafften Qualitätsabstufungen.

Wir sehen nun also eine Tabelle, die sich nicht besonders von knappen Aufzählungen unterscheidet, die jeder Webentwickler in seine Angebote schreiben kann. “Ich teste folgende Browser: …” Der Reiz des GBS lag immer darin, dass von einem der weltweit am stärksten frequentierten Webseitenbetreiber eine qualitative Einordnung von Browsern vorgenommen wurde. In Sachen progressive enhancement konnte der GBS die Diskussion mit dem Kunden erleichtern. In der neuen Form braucht niemand den GBS.

Der IE10 wird also keinen eigenen CC-Vektor mehr haben und sich gegenüber Conditional Comments wie jeder richtige Browser verhalten.

Ich persönlich finde es ja schade, dass Conditional Comments nicht als Standard in HTML5 aufgenommen wurden. Abseits der sinnvollen Featuredetection könnte man so die speziellen Nickligkeiten und Fehler eines Browsers direkt ansprechen und beheben. Aber wir hoffen ja darauf, dass die Notwendigkeit dafür demnächst gegen Null tendiert. Oder?

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.

• Ein Stylesheet darf beim IE bis zu 4095 Regeln haben.
• Der IE akzeptiert bis zu 31 @import-Regeln in einem CSS.
• Der IE akzeptiert ein @import mit bis zu 4 Ebenen tiefer Verlinkung.

Die 2000 Klassen, die man pro Element auf alle Fälle vergeben kann, sollten jedem reichen. Opera, Safari (und Chrome?!) vertragen sogar mehr als 4000 Klassen.

Die Testseiten für die @import-Regeln und die 4095 Selektoren zeigen, daß diese Limitierungen offenbar browserspezifisch sind. Chrome, Firefox 4 und Opera 11 zeigen in beiden Tests keine Schwächen.

Die Argumente zeigen eine Sache deutlich: die Browser in Behörden und sicher auch in Großunternehmen sind nicht für die Benutzung im Internet, auf Facebook, Twitter & Co. ausgerichtet. Sie sollen interne Tools bedienen. Diese Grundidee finde ich korrekt. Doch leider ist sie an der Realität vorbei. Jede Statistik zeigt, daß vom Arbeitsplatz viel privat gesurft wird. Anbieter und Webentwickler müssen sich darauf einstellen.

Es kann sein, daß die Britische Regierung nun ihre Meinung ändert. Aktuell gibt es einen sehr interessanten frühen Prototypen, der die mögliche Optik und Usability künftiger Seiten der Regierung demonstrieren soll. Im Quellcode findet sich folgendes interessante Statement, das mittels conditional comment nur an IE6-Nutzer ausgeliefert wird:

Hello. This site has not been designed with your web browser, Internet Explorer 6, in mind. A very small percentage of web users in the UK (2.9%) use this browser and Microsoft are actively discouraging its use (see The Internet Explorer 6 Countdown).

To experience this site as intended may we suggest you try returning with a modern standards-compliant browser such as Internet Explorer 9, Firefox, Google Chrome, Opera, or Safari.

Ich hoffe, dass dieser Hinweis nicht nur eine eigenmächtige Idee eines Entwicklers ist, sondern daß sich die Haltung grundlegend geändert hat.

Nachtrag: Es scheint, als sei der Kommentar eher eine Entscheidung des Projektteams gewesen, als eine allgemein abgestimmte Strategie. Darauf deutet jedenfalls ein Blogeintrag hin. Vielleicht setzen sie dadurch die richtigen und entscheidenden Akzente. Das Projekt als solches ist jedenfalls klasse.

Ich wollte eine neue Screenshot-Erweiterung austesten und landete bei “Awesome Screenshot“. Dort mußte ich dann lesen, daß diese Erweiterung auf meinen ganzen Rechner und die History meines Browsers Zugriff hätte. Da fragt man sich doch, was eine solche Erweiterung so neugierig sein muss. Naja, dann nutze ich halt eine andere.

Allerdings werde ich jetzt die Frage nicht mehr los, was denn Firebug und Konsorten im Firefox hinter meinem Rücken so treiben. Schnüffeln die auch herum? Wir leben schon in seltsamen Zeiten.