Browser-Spezialitäten

Standort: Alexander Foken > Projekte > Web > Browsertest > Browser-Spezialitäten

Hinweis: Die verwendeten Testmethoden "beißen" sich mit allen HTML-Standards -- wie auch die diversen propritären HTML-Ergänzungen -- deswegen ist diese Seite leider kein valides HTML. Die meisten Browser zeigen sie trotzdem richtig an.

Test	Ergebnis	Bemerkungen
<NOSCRIPT>-Tag	Javascript ist abgeschaltet, der Inhalt des <NOSCRIPT>-Tags wird versteckt.	Der Satz links sollte exakt ein "NICHT" enthalten, alles andere deutet auf Probleme mit dem Browser hin.
LANGUAGE-Attribut des <SCRIPT>-Tags		Wird das LANGUAGE-Attribut beachtet oder immer Javascript angenommen ? (Einige Tests setzen voraus, daß das LANGUAGE-Attribut beachtet wird.)
TYPE-Attribut des <SCRIPT>-Tags		Wird das TYPE-Attribut beachtet oder immer text/javascript angenommen ?
text/plain equivalent mit text/javascript		Wird außer text/javascript auch text/plain für das TYPE-Attribut des <SCRIPT>-Tags akzeptiert?
HTML Entities		Netscape-spezifisch. HTML-Entities erlauben, Attribute von HTML-Tags durch Javascript zu besetzen: <HR WIDTH="&{15+3*10-5};%" ALIGN="LEFT"> ist identisch mit <HR WIDTH="40%" ALIGN="LEFT">
"Conditional Comments" nach Art des Hauses Microsoft	nein	Microsoft definiert eine Spezialsyntax, die es erlaubt, Teile der Seite vor der Auswertung zu verbergen. Damit ist die HTML-Seite nicht mehr W3C-konform, das Ganze funktioniert nur mit dem IE5 und neuer , und verläßt sich ansonsten darauf, das Browser HTML-Schrott ausfiltern und ignorieren.  Microsofts Dokumentation (und bei Microsofts Wahn, die Webseite alle paar Wochen umzusortieren, eine  Google-Suche).
data:-URLs nach  RFC2397		data:-URLs sind im August 1998 erfunden worden. Trotzdem kann sie nicht jeder Browser verarbeiten. Wenn links ein kleiner grüner Haken erscheint, kann der Browser Data-URLs verarbeiten.
<IFRAME>-Tag		IFRAMEs sind - wer hätte es gedacht - mal wieder eine Microsoft-Erfindung, seit HTML 4.0 aber Bestandteil des Standards. Auch hier zeigt ein kleiner grüner Haken an, daß IFRAMEs unterstützt werden.
document.all-Objekt		MSIE-spezifisch
document.layers-Objekt		Netscape-spezifisch
window.opera-Objekt		Opera-spezifisch
RegExp-Objekt		ab Version 1.1
screen-Objekt		ab Version 1.2
Date.getUTCDate()-Methode		ab Version 1.3
Date.getFullYear()-Methode		ab Version 1.3 Zum Jahr-2000-Problem von Javascript siehe unten.
Ergebnis der Date.getYear()-Methode für die Jahre 1999 und 2001		Zum Jahr-2000-Problem von Javascript siehe unten.
document.getElementById()-Methode		ab Version 1.5 (DOM 1.0)

Das Jahr-2000-Problem von Javascript

Auch die Javascript-Definition hat ein Jahr-2000-Problem. Date.getYear() lieferte ursprünglich nur die letzten zwei Stellen des Jahres, damit läge 2000 vor 1999, denn 0 ist kleiner als 99.

Warum zur Zeit der Erfindung von Javascript, kurz vor dem Jahrtausendwechsel noch jemand auf die Idee gekommen ist, in einer Megabyte-großen Anwendung zwei Stellen beim Jahr einzusparen, ist nur mit konsequenter Denkverweigerung zu erklären.

Lösungsansätze:

Natürlich gibt es nicht eine Lösung, jeder Hersteller hat mal wieder sein eigenes Süppchen gekocht:

Definition von Date.getYear() ändern:

Date.getYear() liefert nicht mehr die letzten zwei Stellen des Jahres zurück, sondern das aktuelle Jahr minus 1900. Für die Jahre bis 1999 ist das Ergebnis identisch, ab 2000 sind die Ergebnisse dann dreistellig. So manche Webseite fand sich nach Silverster 1999 im Jahr 19100 wieder, weil ein "kluger" Webmaster eine Addition eingespart hatte, indem er dem Ergebnis von Date.getYear() einfach konstant "19" vorangestellt hatte.

Date.getYear() als "obsolet" erklären und stattdessen eine neue Methode Date.getFullYear() einführen, die das gesamte Jahr zurückliefert.

Damit schmeißt man "nur" allen bestehenden Javascript-Code über den Haufen, der Date.getYear() benutzt. Letztlich ist dies für neuen Code aber die sauberste Lösung.

Übereilte Korrektur

Einige Programmierer alternativer Javascript-Engines schienen schon lange vor 2000 bemerkt zu haben, das Date.getYear() in der Netscape-Version Unsinn ist. Deshalb liefert ihr Date.getYear() grundsätzlich das vollständige Jahr.
Auch das sabotierte existierenden Code, führte aber letztlich zu brauchbaren Standard-Korrekturcode, um das Jahr zu ermitteln.
Kurzsichtige Programmierer schrieben:
 y=mydate.getYear(); if (y<100) y+=1900;
Programmierer, die weiter als bis 1999 dachten, schrieben stattdessen:
 y=mydate.getYear(); if (y<200) y+=1900;
Und ganz extreme Programmierer dachten bis 2899:
 y=mydate.getYear(); if (y<1000) y+=1900;

Denkverweigerung in letzter Konsequenz

Für Jahre vor 2000 liefert Date.getYear() zweistellige Jahreszahlen, ab 2000 liefert Date.getYear() das vollständige Ergebnis.
Warum ?
Um fehlerhaften Korrekturcode für eine fehlerhaft definierte Funktion zu kompensieren:
Nur dieses Funktionsergebnis liefert mit dem "kurzsichtigem", fehlerhaften Korrekturcode von oben (y=mydate.getYear(); if (y<100) y+=1900;) ein vernünftiges Ergebnis.
Aber sollte es die Aufgabe einer Sprache sein, Fehler der Programmierer zu umgehen? Sollten nicht vielmehr die Programme von Fehlern befreit werden ?

Vorschlag für eigenen Code mit Date.getYear():

Da nicht jeder Javascript-fähige Browser Date.getFullYear() implementiert, scheidet Date.getFullYear() aus. Man könnte zwar prüfen, ob Date.getFullYear() implementiert ist, aber auch ohne diese Funktion kommt man bis 2899. Wer seinen Code so robust schreiben will, daß er auch nach 2899 noch funktioniert, soll das tun. Ich empfehle, Date.getFullYear() für die nächsten drei Jahrhunderte zu ignorieren, und stattdessen zum Rückgabewert von Date.getYear() 1900 zu addieren, wenn der Rückgabewert kleiner als 1000 ist.

Beispiel, sicher bis 2899:

	var now=new Date();
	var year=now.getYear();
	if (year<1000) year+=1900;
	document.write('Current Year: '+year);

Beispiel, sicher auch nach 2899:

	var now=new Date();
	var year;
	if (Date.getFullYear) {
		year=now.getFullYear();
	} else {
		year=now.getYear();
		if (year<1000) year+=1900;
	}
	document.write('Current Year: '+year);