Heute hatte ich wieder einmal ein Problem, was speziell den InternetExplorer betrifft. Ziel war es einen transparenten Button (INPUT Type=Submit) zu erzeugen, der sich über einen beliebigen Text legt. Hintergrund hierfür ist, dass der IE6 ja das Button-Problem hat und zusätzlich im JSF-Framework einfache Links nicht für die Navigation (Navigation-Rules) verwendet werden können. Die Idee dahinter ist daher einen SPAN-Tag mit dem gewünschten Inhalt zu haben und darüber ein transparentes INPUT-Feld zu legen.
In den Browsern Firefox, Safari und Opera funktioniert dies auf Anhieb problemlos. Hierzu musste einfach dem Span-Tag die Position relative verpasst werden und das innere Input-Feld wurde absolut positioniert (Breite / Höhe 100%).
Im IE gab es dann jedoch schon den ersten Fehler. Der Button war weg!
Da der Button als Value nichts hat und zusätzlich transparent ist und keinen Rand besitzt wurde dieser einfach gar nicht gerendert und die Größe ignoriert. Er war nicht anklickbar. Abhilfe schafft hier das Setzen eines Hintergrundbildes in Form eines transparenten GIF-Pixels.
Im IE6 gab es zusätzlich noch das Problem, dass dieser die geerbte Breite von 100% nicht vom Elternelement mit Position, als in unserem Fall das Span-Tag, bezog, sondern vom Body selbst. Damit war der Button natürlich viel zu Breit. Einen Hinweis hierzu habe ich auf http://www.satzansatz.de/cssd/onhavinglayout.html gefunden. Dort wird das Verhalten des IEs beim Rendern erläutert. Abhilfe schafft hier ein display:inline-block im Span-Tag.

Der fertige Code sieht dann wie folgt aus:

Dies kann nun als CommandLink-Code verwendet werden, ohne dass hierfür JavaScript auf der Client-Seite notwendig ist.

Wieder einmal und wahrscheinlich auch nicht zum letzten Male bringt ein Browser einem zur Weißglut. Diesmal ist es (außnahmsweise) mal nicht der IE, sondern der Firefox. Dieser hat, auch in der aktuellsten Alpha (Firefox 3 Alpha 3), einen gravierenden Bug bei der Anzeige von Scrollleisten. Aber seht selbst:

Der gelbe und der Blaue Layer sind eigentlich über den Layer mit dem Bild und sollten demzufolge auch die Scrollleisten überdecken. Das es eigentlich auch geht zeigt der Firefox 2 unter Windows:

Und auch ein anderer Browser, hier der Safari, kann es unter Mac wunderbar anzeigen:

Für alle, die es selbst testen wollen bleibt noch die HTML-Variante.
Kann man nur hoffen, dass der Fehler bald behoben wird.

Gerade in komplexeren Anwendungen weiß man hin und wieder nicht welchen Typ eine bestimmte Variable hat und möchte daher dies prüfen. Ich hatte ja bereits in der Vergangenheit beschrieben, wie man zwischen Funktionen und Objekten unterscheidet.
Da sich Arrays jedoch auch als Objekte ausgeben hilft eine Unterscheidung zwischen einem Array und einem Objekt leider nicht. Abhilfe schafft hier jedoch eine Besonderheit bei “instanceof”:

var a = Array();
var b = new Object();
alert(a instanceof Array);
alert(b instanceof Array);
alert(a instanceof Object);
alert(b instanceof Object);

Als Ausgabe ist hier zu erwarten: true, false, true, true

Das der IE bei Fehlern im JavaScript dem Nutzer so “tatkräftig” zur Hand geht, ist ja allgemein bekannt. Interessant ist hierbei auch die Fehlermeldung “Mitglied nicht gefunden”.

Verändert man per JS den DOM-Baum, so kann man mit node.setAttributeNode neue Attribute hinzufügen. Ausgenommen hiervor scheint jedoch das Attribut “style” bei HTML-Elementen. Denn beim Setzen von diesen Attributen wird massiv vom IE gemeckert. Fehler: “Mitglied nicht gefunden”
Abhilfe schafft hierbei wohl nur der Weg über die Eigenschaft “style“, die das HTML-Objekt nach document.createElement bereits hat.

Bei der XML-Verarbeitung mit AJAX bringt der Opera 8.52 ein komisches Verhalten mit. Neben der fehlenden synchronen Abfrage interpretiert er die XML-Datei auch etwas eigensinnig. Mit der Eigenschaft “responseXML” des XMLHttpRequest-Objektes kann auf eine XML-Datei per DOM-Struktur zugegriffen werden. Der Opera liefert dann die Tagnamen von XHTML jedoch immer in Großbuchstaben aus und ignoriert dabei völlig die Schreibweise in der übertragenen Datei. Dies ist vor allem bei einem Textvergleich eine leicht zu übersehende Fehlerquelle, zumal in XML-Dateien die Tags sowieso alle klein geschrieben sein sollten.

Soeben habe ich noch etwas bemerkenswertes festgestellt. Laut JavaScript ist eine einfache Function automatisch ein Objekt.

Folgender Code soll es verdeutlichen:

Dieser Code gibt folgendes aus: true, false, true, true

Es sollte also nie eine function auf “Object” mit instanceof geprüft werden.

Wenn man etwas aufwendigere Webseiten mit JavaScript verschönen will, kommt man vor allem bei den dynamisch erstellten Ereignissen schnell ins strudeln.
Dies möchte ich an einem kleinen Code-Beispiel zeigen:

Was wird hier wohl ausgegeben? Genau, nicht wie vielleicht erwartet 124, sondern 123. Denn die Variable v wird durch new t() am Ende wieder überschrieben und das Ereignis bezieht sich dann auf diese lokale Variable.

Nun kann man dies zwar hier umgehen durch einen anderen Variablennamen, in einer Schleife stellt sich das Problem dann jedoch schon etwas gravierender dar.

Abhilfe schafft an dieser Stelle, dass an fast jedes Objekt in JavaScript dynamische Properties hinzugefügt werden kann.
Ändern wir als den Code wie folgt ab:

Jetzt gibt der Code beim Klick auf das Element “test” den Wert 124 aus, denn es wurde vorher die Referenz auf v in obj.onclick_vars abgelegt, auf welche später zugegriffen wird.

Auf diese Art und Weise kann das Manko umgangen werden, dass man an Ereignisse keine zusätzlichen Variablen hängen kann. In meinen Augen ein klarer Design-Fehler, denn ein platz für ein Objekt wäre im Eventhandler sicherlich noch übrig gewesen.

Nutzt man beim Konqueror (Version 3.4.3) das XMLHttpRequest um per send einen String zu senden, so sendet der Konqueror den String zuzüglich eines 0-Zeichens. Dieses Zeichen wird häufig zur Terminierung von Zeichenketten verwendet, hat aber beim Senden wirklich nichts verloren. Folgender Code demonstriert das Phänomen, welches per Sniffer wie ethereal überwacht werden kann.

Es wird hier der Text “test” sowie das 0-zeichen im POST-Stream gesendet.

Opera unterstützt ja nun seit geraumer Zeit (glaube ab 8.0) auch das XMLHttpRequest-Objekt, welches für AJAX notwendig ist. Dies scheint jedoch nicht ganz dem von Mozilla zu entsprechen. Wenn man der Referenz für XMLHttpRequest folgt, so ist durch das Async-Flag im open-Befehl die Wahl zwischen synchroner und asynchroner Abfrage möglich. Der Opera bis Version 9.00 Build 3216 unterstützt die synchrone Übertragung nicht. Egal wie, es ist immer asynchron. Dies kann jedoch recht einfach nachgebildet werden:

Beim Testen von verschiedenen Eigenschaften habe ich gestern im Safari-Browser 2.0.3 einen interessanten Bug gefunden. Bei z.B. einem DIV-Layer werden die OnMouseOut-Ereignisse nicht korrekt erzeugt. Sobald der Layer oder ein anderes Objekt einen Text hat, wird beim überfahren dieses Ereignis immer wieder ausgeführt.
Hier ein Beispiel-Code:
(weiterlesen…)