Die folgende Liste erhebt keinen Anspruch auf Vollständigkeit. Ich lasse mich auch gerne korrigieren, falls ich Befehle falsch verstanden oder angewendet habe. In diesem Fall bitte ich um eine eMail.
Nicht berücksichtigt werden zusätzliche Möglichkeiten wie Layer (Netscape Communicator), dynamische Filter (Microsoft IE) oder Marquee (Microsoft IE).
In einem mit align=justify als Blocksatz ausgerichteten Absatz erscheint durch den eingefügten Wortzwischenraum eine Unterstreichung (<u>...</u> bzw. <a href="...">...</a>) als unterbrochene Linie. Das sieht nicht nur nicht schön aus, sondern suggeriert zudem bei einem Link mehrere Verweisziele.
Konsequenz: Diese optisch ansprechende und in jeder Textverarbeitung gängige Absatzausrichtung kann in HTML-Dokumenten nicht sinnvoll verwendet werden.
Ein mit Style-Sheets farbig hinterlegter Absatz wird durch align=center oder text-align:center zwar in der Seitenmitte angeordnet, es ist mir jedoch nicht gelungen, Zeilen, z. B. nach einem <br> zu zentrieren. Der Versuch, das Problem mit einer blinden Tabelle oder geschachtelten Absätzen zu lösen, schlug völlig fehl, da sie gar nicht in den farbigen Bereich ausgegeben wurden.
Konsequenz: Idee nicht realisierbar.
Spaltenbreiten in Tabellen werden durch die Breitenverhältnisse der Inhalte unbeeinflußbar bestimmt. Die Tabelle wird dadurch unsymmetrisch.
Konsequenz: Anzuzeigender Text muß in der Hintergrundfarbe in der leeren Spalte wiederholt werden, bzw. bei Grafiken eine Grafik mit der Hintergrundfarbe auf die entsprechende Größe gestreckt eingefügt werden. Das bringt längere Übertragungszeiten, bei Text Unregelmäßigkeiten im Mauszeiger und Chaos, wenn der Anwender die Hintergrundfarbe im Browser manuell geändert hat.
Universalattribute werden nur sehr vereinzelt unterstützt.
Konsequenz: Der Seitennutzer hat keinen Zugriff auf zusätzliche Informationen z. B. durch title.
Die pixelgenaue Größenangabe eines Frames wird nur recht ungenau umgesetzt. Geringe Änderungen bewirken gar nichts, dann kommt plötzlich ein größerer Sprung.
Konsequenz: Frames, die genau für eine Grafik passen sollen, können optisch nicht optimal gestaltet werden, bzw. es wird Platz verschwendet.
Bei Größenänderungen des Fensterausschnitts wird offenbar die Seite neu geladen. Das führt dazu, daß nachträglich auf eine Seite geschriebene Informationen verloren gehen.
Konsequenz: Der Seitennutzer darf die Größe entsprechender Seiten nicht verändern, sonst wird der Programmablauf gestört bzw. abgebrochen.
Beim neuen Schreiben von maskierten HTML-Steuerzeichen geht die Maskierung verloren.
Konsequenz: Einzelne Zeichen und Textbereiche verschwinden, es kommt zu Falschdarstellungen.
Auch wenn er nie gebraucht wird, muß einem Formularelement bei der Definition explizit ein Name zugewiesen werden.
Konsequenz: Dies herauszufinden hat mich eine Stunde Fehlersuche gekostet, ausgelöst durch nicht genau zu lokalisierende JavaScript-Fehler, die dazu führten, daß sich Netscape kommentarlos mit einer Schutzverletzung verabschiedete. Einige andere ungewöhnliche Vorkommnisse habe ich noch nicht klären können.
Die Formateigenschaft background-attachment wird nicht interpretiert, obwohl sie schon ab der CSS-Version 1.0 definiert ist.
Konsequenz: Wenn es auch nicht überlebensnotwendig ist, so fehlt doch wieder ein schöner Effekt zur ansprechenden Seitengestaltung. (Übrigens: Der IE hat sogar schon seit Version 2.0 einen entsprechenden HTML-Zusatz.)
Eigenschaften von Objekten, die sich auf ein Dokument von einer anderen Domäne als der der JavaScript-Datei beziehen, dürfen weder geändert noch ausgelesen werden. Warum darf ein Dokument nicht wissen, welches Dokument im benachbarten Frame geladen wird?
Konsequenz: Als Ersatz einer einzigen Anweisung werden programmtechnische Klimmzüge nicht vertretbaren Aufwandes nötig, die z. T. erheblich unsicherer sind (oft ist nur ein in den blauen Dunst gesetztes setTimeout die einzige Lösung) oder gar nicht existieren. Die Programmierung insbesondere komplexerer Seiten auf mehreren Servern wird unzumutbar erschwert und teilweise sogar verhindert.
Viele Objekteigenschaften können unverständlicherweise nur gelesen werden. Was spricht dagegen, z. B. die Breite eines Bildes zur Laufzeit zu ändern?
Konsequenz: Die Möglichkeiten von JavaScript im Zusammenhang mit HTML zur dynamischen Seitengestaltung werden unnötigerweise eingeschränkt.
Der Inhalt eines HTML-Dokuments kann nicht ausgelesen werden (vgl. document.all.outerHTML und ähnliche Methoden beim Internet Explorer).
Konsequenz: Dynamisches HTML wird eingeschränkt, der Inhalt anderer Seiten kann nicht verwendet werden.
Die image.complete-Eigenschaft scheint nicht zu funktionieren.
Konsequenz: Der Ladezustand von Bildern kann nicht überprüft werden. Sinnvoll kontrolliertes Laden im Hintergrund ist nicht möglich.
15. November 1998