JavaScript - 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.

Als momentan beste Lösung zu meinem im Beitrag Cookies prinzipiell „fies und hinterhältig”? beschriebenen Problem habe ich nun den Feed to JavaScript-Service von feed2js.org gefunden. Er erstellt ein JavaScript, mit dessen Hilfe man den Inhalt eines beliebigen RSS-Feeds in eine Internetseite einbauen kann. Das Ganze ist ziemlich frei konfigurierbar, Cookie-frei und ohne Werbung.

Wichtig war für mich im konkreten Fall, dass die erzeugten Links ein beliebiges target-Attribut mitbekommen können, da ich sie über target="_parent" den Signatur-Iframe sprengen lassen möchte.

Für Anwender wie mich, die momentan keinen Webspace zur Verfügung haben, der eine Scriptsprache wie PHP unterstützt, scheint mir dieser Service die optimale Möglichkeit, den RSS-Feed in HTML umzuwandeln. Allerdings mit der Einschränkung, dass Besucher, die JavaScript abgeschaltet haben, nichts bzw. nur einen Link zum Feed zu sehen bekommen.

In einem Internetforum benutze ich folgende Signatur in einem Iframe, in der mit Hilfe des BuzzBoost-Features von Feedburner bei Leuten, die JavaScript eingeschaltet haben, die letzten zwei Beitragsüberschriften aus diesem Blog zu sehen sind: [Link zum Iframe-Inhalt].

Beim Aufruf des Signatur-Iframes (aus forenspezifischen Gründen nicht anders lösbar) wird von BuzzBoost automatisch ein Cookie gesetzt, der nach 5 Minuten abläuft.

Auf den Hinweis eines Forum-Users, dass ein Cookie "unschön" wäre, erwiderte ich folgendes:

Da der Cookie an sich harmlos und nicht geeignet zur langfristigen Leserverfolgung ist, eh spätestens beim nächsten Browserstart gelöscht wird, die Leser keinen Nachteil durch ihn haben und geschätzte 99% aller User gar nichts von ihm mitbekommen, da sie Cookies entweder generell blocken oder zulassen, kann ich diesen konkreten Cookie gut mit meinem Gewissen vereinbaren.

Darauf bekam ich von einem anderen User vorgeworfen, den Cookie zu setzen wäre "fies und hinterhältig" und was ich auf seinem Rechner eigentlich zu suchen hätte. Wenigstens ein Hinweis darauf, dass ein Cookie installiert wird, wäre angebracht.

Nun stehe ich vor der Frage, ob Internetnutzer paranoid sind, oder ich fies und hinterhältig bin. Der Cookie ist aufgrund der lächerlich kurzen Laufzeit nachweisbar harmlos, meine Frage im Feedburner-Forum, wozu er überhaupt gesetzt wird, wurde noch nicht beantwortet.

Sollte man nun aus Rücksichtnahme auf unbegründete Datenschutzbedenken auf diesen Einsatz von BuzzBoost verzichten? Ein Disclaimer kommt für mich nicht in Frage, da er erstens zu spät kommt (der Cookie ist beim Lesen des Disclaimers schon geschrieben) und er zweitens meiner Meinung nach die Leser nur verwirrt. Cookies sind heute im Web allgegenwärtig und der mündige Surfer hat die Möglichkeit selbst zu entscheiden, wie der damit umgeht; ggf. halt auch durch den Einsatz einer entsprechenden Browser-Erweiterung.

Ich bitte ausnahmsweise mal ausdrücklich um Kommentare und Meinungen zum Thema, sie dürfen auch gerne kritisch ausfallen.

Nachtrag (24.07.): Aus bloginternen Gründen habe ich den direkt eingebundenen Iframe entfernt und durch einen Link zum Inhalt des Frames gesetzt.

Es gibt Dinge, bei denen ich mir als potentieller Kunde ziemlich verarscht (sorry für die deutlichen Worte) vorkomme. Zu diesen Dingen gehört sicherlich, wenn eine Webseite zunächst komplett lädt, ich während der relativ langen Ladezeit schon zu lesen anfange, und mich die Seite gerade nachdem ich das erste interessante Produkt gefunden habe, damit überrascht, neu zu laden und nur noch diese Meldung zu zeigen:

This site requires Javasript to be enabled. Enable Javasript from your browser. Then go to the front page of the site.

Sowas löst bei mir automatisch den Tab-Schliessen-Reflex aus und ist meiner Meinung nach noch mal eine Kategorie schlimmer als eine "Meine Seite ist so schlecht, dass sie ohne JS gar nicht funktioniert"-Meldung gleich zu Beginn.