Das ganz normale Chaos, täglich frisch auf den Tisch. Direkt aus der hintersten Provinz in die Metropolen von Groß-Blogistan.


Web-Saurier

Fri, 06 Mar 2009 10:42:49 +0100

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.


0 Kommentare