Ich hatte ja auch schon darüber geschrieben, als Antwort auf einen Artikel bei Jens Grochtdreis und Peter Kröner. Jetzt schreibt auch das Web Accessibility Konsortium Einfach für Alle darüber: Der IE6 ist ein Dinosaurier aus der Webstandards-Vorzeit und bringt einen haufen Probleme mit sich. Dabei ist man dort anhand eines konkreten Beispiels auf eine "verblüffende" Lösung gekommen, die ich hier bei Rorkvell schon lange einsetze. Es geht um die mehrspaltige Darstellung von Inhalt. Bei Einfach für Alle war das eine Linkliste. Bei mir sind es die Inhalte dieses Blogs. Genauer, die einzelnen Beiträge. Bei mir sieht das seit Langem so aus:
div.entry-content {
-moz-column-width: 26em;
-moz-column-gap: 1.6em;
-webkit-column-width: 26em;
-webkit-column-gap: 1.6em;
column-width: 26em;
column-gap: 1.6em;
}
Der Klassenname entry-content geht dabei zurück auf die
hAtom Spezifikation der
Microformats. Im Gegensatz zu
Einfach für Alle habe ich hier absichtlich auf die Angabe von
column-count verzichtet. Aus folgendem Grund: Ich möchte nicht
unbedingt eine mehrspaltige Darstellung des Inhalts. Ich möchte diese nur dann,
wenn der Bildschirm (genauer: Der Viewport) breit genug ist. So breit, dass
einerseits die Zeilen sonst unleserlich lang werden, und andererseits die
Spalten nicht zu schmal werden. Also einfach ein sinnvoller Kompromiss.
Darüberhinaus sind sowohl die Spaltenbreite als auch die Lücke zwischen
den Spalten in em angegeben, und damit von der Schriftgröße
abhängig. Die Anzahl Spalten, die man hier zu sehen, bekommt, hängt also ab
von der Bildschirmbreite und von der Schriftgröße. Bei großen Schriften und/oder
schmalen Bildschirmen gibt's nur eine Spalte. Bei breiten Bildschirmen und/oder
kleinen Schriften gibt's mehr Spalten. Das können 2, 3 oder aber auch mehr
sein. Wie auch immer Bildschirm und Schriftgröße kombiniert werden, die
Spaltenbreite sollte einen sinnvoll lesbaren Text ergeben. Manchmal ist es
eben besser, bestimmte Dinge weg zu lassen, anstatt Alles pixelgenau vorzuschreiben.
Nun ist es so, dass der IE6 aus einer Zeit stammt, als solche Layoutmöglichkeiten
noch nicht vorgesehen waren. Hänge ich nun für IE6-Nutzer ein Schild an's Blog der
Art wir müssen leider draussen bleiben
? Nein. Baue ich einen Haufen Hacks
und Javascript und was weiss ich noch Alles ein, um diese mehrspaltige Darstellung
auch im IE zu ermöglichen? Nein! Bekommen IE6-Nutzer nun eine Seite ohne Layout?
Nein. IE6 Nutzer (und Nutzer anderer nicht-standardkonformer Browser) bekommen einfach
das Maximum dessen zu sehen, was ihr Browser von Haus aus kann. Beim IE6 geht
das manchmal auch schief, hier kann auch mal das eine oder andere Detail
verschoben sein. Stört mich nicht.
Gewisse Dinge stören natürlich. So habe ich erst kürzlich mitbekommen, dass
Googles Chrome mit alternativen Stylesheets nicht nur Nichts anfangen kann,
sondern diese zu allem Überfluss auch noch
wild durcheinander würfelt.
Hier muss ich mir überlegen, ob ich eingreife oder Müll einfach Müll sein lasse.
In diesem Fall habe ich eingegriffen und alternative Stile in der HTML-Version
abgestellt. Ein anderer Punkt ist das Navigationsmenue. Dies ist bei mir nicht
nur absolut standardkonform aufgebaut, sondern auch noch nach den Richtlinien
des semantischen Markups. Diese besagen u.A., wenn es ein HTML-Element gibt,
das seinem Inhalt die korrekte Bedeutung verleiht, dann ist dieses HTML-Element
zu verwenden. Beliebtes Beispiel dafür sind Überschriften. Ich könnte auch ein
span verwenden und dieses so stylen, dass es wie eine
Überschrift aussieht. Semantisches Markup verlangt aber, dass ich eine Überschrift
auch mit h1, h2,
h3 und so weiter auszeichne. Denn ein
h1 verleiht seinem Inhalt die korrekte Bedeutung, eine
Überschrift (erster Ordnung) zu sein. So funktioniert das auch mit meinen
Navigationsbuttons. Ein Button, der aussieht wie ein Button, der funktioniert
wie ein Button, der gedacht ist als Button, sollte also semantisch korrekt auch
mit einem
button ausgezeichnet sein. Ein Button ist zulässig
an beliebigen Stellen, an denen z.B. inline Inhalt stehen kann. Und was kann
als Inhalt eines a (Ankers) stehen? Inline Inhalt. Also
auch ein button. Wird auch von allen IEs von IE5 bis
IE7 korrekt dargestellt. Und was ist die Funktionalität eines
a (Ankers)? Wenn man auf dessen Inhalt klickt, wird
z.B. die Seite gewechselt. Ausser bei Microsoft. Dort wird die in der W3C
Spezifikation festgeschriebene Funktionalität eines Ankers nur dann ausgeführt,
wenn der Inhalt kein button ist. Der IE beherrscht
also noch nicht einmal die Grundfunktionalität eines Ankers (Links).
Diesen Fehler haben alle mir bekannten IEs, angefangen von der Version 5.0 bis
einschließlich der Version 7.0. So weit, so schlecht. Was ist hier zu tun?
Soll ich aufgrund dieser fehlerhaften Implementierung auf semantisches Markup
verzichten? Ungern. Also, was tun? Schauen wir mal, was man mit dem
button selber anfangen kann. Dieser löst
Javascript Events aus. Und solch einen Event kann man nutzen, um die nicht
vorhandene Funktionalität des Ankers per Javascript zu emulieren. Dazu muss
die Navigation des Ankers im Javascript Event Handler des buttons
wiederholt werden. Leider funktioniert das nicht, wenn Javascript abgeschaltet
ist. Doch hier endet meine Kompromissbereitschaft mit fehlerhaften Browsern.
Mit Javascript funktioniert es im IE, ohne nicht. Schluss.
Da der IE auch kein XHTML anzeigen kann, habe ich diesen Workaround auch nur in der HTML Version meiner Seiten drin.
Alles in Allem bin ich ohne Probleme bereit, gewisse Kompromisse mit fehlerhaften Browsern einzugehen. Aber das hat Grenzen. Wo diese liegen, muss natürlich Jeder selber entscheiden. Rorkvell ist ja nur meine Spielwiese, auf der ich die Möglichkeiten des Web auslote. Ich muss damit kein Geld verdienen. Also kann ich es mir leisten, hier und da Nutzer von billigen Browserimitaten auch mal im Regen stehen zu lassen. Ich leiste mir diesen Luxus allerdings nur dann, wenn die Kompromisse sonst zu drastisch würden.