Browserbug - Zapps Blog

Ich habe momentan ein leichtes Déjà-vu-Erlebnis, das mich ein paar Jahre zurückwirft.

Als ich damals begann mich für HTML und CSS zu interessieren, fand ich die Möglichkeiten beider Sprachen faszinierend und das Konzept der Trennung von Inhalt und Layout einleuchtend. Der erste Tatendrang wurde zeitweise nur durch eine Software aus dem fernen Redmond gebremst: den Internet Explorer.

Version sechs verhielt sich oft anders, als man das angesichts des Codes erwarten sollte. Schnell war klar, dass das nicht nur am anfängerhaften Code sondern auch und vor allem am veralteten Browser lag und mit der Zeit und einigen Internetrecherchen lernte ich manche Eigenheiten des IE kennen. Begriffe wie „Star-HTML-Hack“ und „hasLayout“ verloren ihre Schrecken und so wurden Layouts möglich, die auch im im IE 6 und seinem grossen Bruder IE 7 akzeptabel aussehen.

Nun stehe ich mit JavaScript wieder am Anfang einer neuen Websprache und was soll ich sagen: Die Probleme sind ähnlich. Es gibt recht klare und einleuchtende Konzepte, die in der Praxis am IE scheitern.

So gibt es etwa die setAttribute-Methode, die einem Knoten ein Attribut zuweisen kann. Einem Link kann beispielsweise mit linkknoten.setAttribute("class","externer"); die Klasse „externer“ zugeteilt werden, die man mit der komplementären getAttribute-Methode auch wieder auslesen kann. Mit der gleichen Syntax könnte der Link auch noch href- und title-Attribute bekommen, bevor er schliesslich in den Dokumentenbaum eingehängt wird. setAttribute ist universell einsetzbar und hat eine leicht zu merkende Syntax, warum sollte man sich für das Setzen und Auslesen von Klassen noch mit dem Wissen um die vergleichsweise spezielle className-Eigenschaft eines Knotens belasten müssen?

Ganz einfach: Weil der Internet Explorer in seinen beiden am weitesten verbreiteten Inkarnationen nicht zuverlässig damit klar kommt.

Durch setAttribute gesetzte Klassen, die der IE-DOM-Inspektor auch sieht, werden dann auf einmal vom CSS nicht beachtet oder Klassennamen werden nicht korrekt ausgelesen, weshalb das betreffende Script dann natürlich nicht im IE funktioniert.

Genau das gleiche Problem existiert im IE bei der Behandlung des onclick-Attribut, auf das man verzichten und stattdessen knotenname.onclick = function(){}; einsetzen sollte.

Dummerweise stand das nicht in meinem ansonsten wirklich genialen Lehrbuch, was mir einige Stunden Gefluche mit meinem Lieblingsbrowser eingebracht hat. Bei einem so diffusen Problembild war meine Webrecherche erfolglos, und auf die Idee, bei SELFHTML ausgerechnet bei setAttribute nachzuschlagen um dort eine eindringliche Warnung inklusive Erklärung des Phänomens zu finden, bin ich leider nicht gekommen. So brachte erst ein beiläufiger Hinweis in einem JavaScript-Cheatsheet die Erleuchtung.

Und damit Google in Zukunft eine Stelle mehr im Web findet, die von Anfängerproblemen mit JavaScript, Klassen, Event-Handlern und dem Internet Explorer berichtet, habe ich diesen kleinen Beitrag verfasst.

• kann nicht mehr per

  html/*\*/>/*/*/body {} head/*\*/+/*/*/body {} html/*/*/>/*/*/body {} head/*/*/+/*/*/body {} html>/**/body {}

  von CSS ausgeschlossen werden.

  Zwischen Beta 1 und Beta 2 hat es hier wohl massive Änderungen in Richtung Standardkonformität gegeben, bei einer zugegebenermassen ziemlich kurzen Suche habe ich noch keinen funktionierenden Hack gefunden.

• versteht nun auch

  @import url(style.css) all;

• interpretiert manche CSS-Angaben aber immer noch so saudumm wie seine Vorgänger.

  Die Unterstützung von @font-face kann man nicht unbedingt erwarten, aber warum produziert das Ding bei

  @font-face { font-family: GraublauWeb; src: url(../fonts/GraublauWeb.otf) format(truetype); /* www.fonts.info */ }

  eine Anfrage nach

  GraublauWebBold.otf)format(truetype

  und damit unweigerlich einen 404?

Grumpf!

Bei meinem Blogumzug bin ich auf zwei mir bislang unbekannte Browserbugs gestossen, über die auch eine kurze Google-Recherche keine Informationen lieferte. Beide betreffen eher experimentelle Browser, nämlich den Internet Explorer 7 und Safari 3.02 für Windows.

Die Standard-Sidebar ist bei Wordpress eine Ansammlung verschachtelter Listen:

Mit dem dazugehörigen CSS kommen beide Browser nicht so recht klar:

• Safari ignoriert – mindestens für ul – komplett den Universalselektor * {margin:0; padding:0;} und benötigt für diese eine eigene Formatierung, also ul {margin:0; padding:0;}

• Der IE 7 produziert – erstaunlicherweise im Gegensatz zum IE 6 – Abstände über den inneren ul, obwohl laut IE-Web-Developer-Toolbar das CSS richtig vom Browser verstanden wird. Der Bug hat mal wieder mit der hasLayout-Eigenschaft der IEs zu tun und Abhilfe schafft ein *:first-child+html #navi ul {height:1%}

  Um die Gefahr von irgendwelchen Ãœberraschungen mit anderen Browsern zu verringern, habe ich hier im Selektor den Star-Plus-HTML-Hack angewendet, der momentan nur den IE 7 ansprechen sollte.

Es ist doch immer wieder schön, wie viele Ãœberraschungen man mit den verschiedenen Browsern erleben kann. Vielleicht hat ja auch noch jemand einen Tipp, warum Opera 9.2 das padding-top der li in meinen Bilderstreifen ul.bildergallerie li { display:inline; padding-top:15px; } ignoriert? Momentan kleben die Vorschaubilder in diesem Browser doch etwas eng aneinander, wenn sie nicht mehr alle in eine Zeile passen.

Gestern hat Steve Jobs eine Beta-Version des Apple-eigenen Browsers Safari (Download) angekündigt, die auch unter Windows schneller laufen soll, als Microsofts Internet Explorer oder Firefox.

Und wie bei einer Ankündigung aus dem Hause Apple nicht anders zu erwarten war, stürzte sich die Presse auf breiter Front auf die neue Software. Leider ist sie unter Windows momentan noch weitgehend unbrauchbar, da erstaunt die positive Einschätzung in der Süddeutschen schon ziemlich. Vielleicht hätte man dort auch mal einen Blick auf die Windows-Version werfen sollen ...

Man merkt der aktuellen Beta von Safari an, dass sie rechtzeitig zur Job'schen Keynote auf der WWDC fertig werden musste und bei der Entwicklung zum Schluss die Prioritäten etwas seltsam gesetzt wurden. So besteht Safari/Win zwar den Acid2-, aber nicht den Praxistest, da selbst auf den Seiten des W3C die Überschriften verschluckt werden. Aber immerhin hat Apple es mal wieder geschafft, überall in den Medien präsent zu sein. Ob sie das allerdings mit Berichten zu einer extrem verbuggten Software erreichen wollten, wage ich zu bezweifeln.

Ich würde mich ja über eine stabile Safari-Version für Windows freuen, deren Rendering der Mac-Version entspricht, da so das Testen von Webseiten erleichtert wird. Aber von diesem Ziel ist Apple leider noch ein ganzes Stück entfernt.

Nachtrag: Einige der aktuellen Safari/Win-Probleme scheinen an einer Inkompatibilität mit Nicht-US-Windows-Versionen zu liegen:

• Apple's Safari 3: a crashing experience for non-US users (The Register)
• Apples Safari ins Unvollkommene (heise)

Update (17.07.07): Die aktuelle Safari-Version 3.0.2 für Windows wird auch in der deutschen Version nicht mehr von Abstürzen geplagt. Der Browser scheint ganz brauchbar zu sein, wobei mir abgesehen von der ganz hübschen Feed-Ansicht keine Alleinstellungsmerkmale gegenüber Firefox oder Opera aufgefallen sind. Die Geschwindigkeit ist (noch?) nicht herausragend.