Technische Hinweise zu dieser Site

Das Layout dieser Seite wurde in der zweiten Häfte von 2005 massiv überarbeitet. Vor Jahresbeginn 2006 verwendete meine Seite Frames und milderte die bekannten Nachteile mit einer Anzahl von JavaScripts ab. Seit Anfang 2006 ist die „reloaded version“ meiner Gewürzseite online. Da sie auf einige sehr fortgeschrittene Methoden zur Webseitengestaltung zugreift, kann es auf manchen älteren Maschinen zu Darstellungsproblemen kommen.

Das neue Design ist flexibel und frei skalierbar. Es ist nicht für eine bestimmte Fenstergröße optimiert, auch wenn sehr kleine Fenster (unter 500 px) verschiedene Probleme aufwerfen. Es werden auch keine speziellen Fonts o.ä. verwendet. Die Seite verwendet, abgesehen vom Hintergrund, sehr wenig Graphik; die meisten Elemente auf der Seite sind reiner Text (auch die „Schaltflächen“ auf der linken Seite). Außerdem sind sowohl das HTML als auch das CSS vollkommen valide.

Die Nachteile des neuen Designs sind vor allem seine Komplexität und Kompliziertheit (überwiegend mein Problem); daraus folgt auch der auf älterer Hardware recht langsame Seitenaufbau. Die Filegrößen sind auch um ca. 5 kbytes gestiegen, aber dieser Nachteil wird durch die kleinere Zahl von http-Zugriffen zumindest zum Teil ausgeglichen. Ein weiterer Nachteil ist, daß die Besucher die „Frames“ nun nicht mehr abschalten können. Das kann man zwar mit JavaScript, alternativen Stylefiles und Cookies beheben, aber dieses Problem hat keine besonders hohe Priorität für mich.

An dieser Stelle möchte ich mich bei Jonas Fansa für seine Hilfestellung in allen Fragen von Ästhetik und Stil bedanken. Von ihm stammt auch das Hintergrundbild, das die chinesische Gewürzmischung 鹵水料 zeigt (siehe chinesischen Zimt).

HTML-Validierung

Diese Seiten sind in einem Dialekt des HTML 4.01 Transitional geschrieben, der einige Nicht-Standard-Elemente (insbesondete <NOBR>) verwendet. Die DOCTYPE-Deklaration am Anfang jeder Seite verlinkt auf eine DTD, in der dieser Dialekt formal definiert wird („custom DTD“).

Die Verwendung einer selbstgestrickten DTD sollte es möglich machen, die Seite mit SGML-Validatoren auf syntaktische Richtigkeit zu überprüfen („Validierung“). Die beiden meistbenutzten Validatoren sind der W3C-Validator und der WDG Validator. Leider versagt ersterer bei der Behandlung von custom-DTDs. Mit zweiterem können jedoch alle einzelnen Seiten validiert werden; zur einfacheren Handhabung findet man jeweils am Seitenende eine Graphik, die direkt zum WDG-Validationsergebnis verlinkt.

Ein weiteres validatorähnliches Produkt ist Validome. Dieses Programm überprüft nicht nur die syntaktische Richtigkeit gemäß der DTD, sondern führt noch umfangreiche weitere Tests durch, die auf Eigenschaften abzielen, die zwar Bestandteil der Definition von HTML sind, die aber nicht in der DTD geregelt werden. Seiten, die den WDG-Validationstest bestehen, können daher von Validome leicht für „nicht valide“ erklärt werden. Meiner Meinung nach ist das eine ziemlich Überdehnung des formal definierten Begriffs „Validation“, aber für Webseitenautoren sind die sehr peniblen Vorgaben von Validome oft sehr hilfreich.

Validome ist ein komplexes Programm, das sich noch in Entwicklung befindet. Daher kann es leicht vorkommen, daß eine zuvor als „valide“ eingestufte Seite plötzlich nicht mehr korrekt validiert, weil der Validator inzwischen zusätzliche Tests ausführt. Außerdem bedingt die ständige Weiterentwicklung von Validome gelegentliche Bugs, durch die dann einige Tage lang valide Seiten als invalide ausgewiesen werden.

Zeichen und Fonts

Wegen ihrer multilingualen Natur benötigt diese Site eine große Anzahl verschiedener Schriften. Diese werden ausschließlich auf der Basis des Unicode-Zeichenmodells codiert. Unicode ist ein hochentwickelter und komplexer internationaler Standard, der es erlaubt, beliebige Schriftsysteme auf ein und derselben Seite gemischt zu verwenden; die Arbeit an diesem Standard ist noch lange nicht abgeschlossen. Webseiten mit gemischen Schriften waren in der prä-Unicode-Ära nicht möglich.

Einige der hervorstechendsten Merkmale des Unicode-Standards sind:

Der Standard definiert Characters (Buchstaben, Zeichen) und weist ihnen eindeutige Nummern (code points) zu.
Er ordnet jedem Zeichen eine Anzahl von Eigenschaften zu. Diese Eigenschaften legen das Verhalten jedes Zeichens fest und spezifizieren, ob es Platz benötigt, ob es mit anderen Zeichen spezielle Formen bildet, ob es in einfachere Zeichen aufgelöst werden kann, welche Schreibrichtung es hat, und noch vieles mehr.
Er soll alle jemals verwendeten Schriftzeichen umfassen. Zur Zeit sind alle Schriften mit offiziellem Status irgendwo auf der Welt erfaßt, und auch einige historische Schriften. Manche rezente Schriften fehlen noch, z.B. Balinesisch, das zwar nicht mehr in Schulen gelehrt wird, das aber immer noch in manchen Gruppen zum täglichern Schreiben verwendet wird.
Außer in einigen Sonderfällen (Kompatibilität!) werden visuelle Varianten desselben Zeichens nicht neu codiert; der Standard beschäftigt sich mit Zeichen, nicht Glyphen. Das Aussehen der letzteren wird von Fontdesignern festgelegt.

Wenn Sie mehr über Zeichendarstellungen lernen wollen, dann empfehle ich einen Einführungstext wie z.B. Character Set Issues von A. J. Flavell.

Um Zeichen am Bildschirm korrekt darstellen zu können, benötigt Ihr Browser natürlich auch die entsprechenden Fonts (diese sind in keinem Fall Bestandteil der Webseite!). Die Unicode Font Gallery von David McCreedy ist ein guter Ausgangspunkt für die Suche nach spezielen Fonts. Aber auch wenn ein geeigneter Font installiert ist, kann die Wiedergabe immer noch fehlerhaft erfolgen: Einige Schriften, besonders die indischen, werden nach sehr komplexen und detaillierten Regeln geschrieben, die Umordnung von Glyphen, Einbau von diakritischen Zeichen und Bildung komplexer Ligaturen umfassen. Diese Arbeit obliegt den Graphikkomponenten des Betriebsystems; in manchen Fällen sind auch spezielle Versionen des Browsers nötig. Wenn Sie die Fähigkeit Ihrer Systems zur Darstellung komplexer Schriften überprüfen wollen, dann probieren Sie es doch bei den Transcriptions of “Unicode”.

Cascading Style Sheets

Auf dieser Seite verwende ich CSS level 1 und 2, um ein komplexes Layout mit positionsfixierten Navigationshilfen zu erreichen. Obwohl CSS 2 bereits 1998 verabschiedet wurde, wird dieser Standard vom am häufigsten benutzten Webbrowser, Microsoft Internet Explorer, nicht unterstützt. Für die bedauernswerten Benutzer dieser veralterten und unfähigen Software mußten daher zahllose Tips und Tricks eingebaut werden, die eine echte CSS-2-Funktionalität zum Teil simulieren können.

CSS 2 bietet unter anderem hochflexible Selektoren, neue Boxattribute und neue Pseudoklassen. Die Selektoren benutzte ich zum typographischen Feinschliff und für gelegentliche „eye candies“ deren Ausfall verkraftbar bleibt. Dagegen sind die neuen Boxattribute für die Funktionalität essentiell. Das Attribut fixed ermöglicht es, Seitenelemente an einem fixen Platz des Browserfensters zu positionieren und vermeidet dabei die Nachteile von Frames, wie ich sie zuvor verwendet habe. Diese Technik wurde zuerst im Jahr 2000 von Stephanos Piperoglou im Web gezeigt (siehe auch seine exzellente Einführung HTML with Style). Seit ich bei ihm die Feinheiten von M.O.R.O.N.S. und transfirbulierten Webseiten erlernte, plante ich, positionsfixierte Boxen auf meinen Seiten anzuwenden; aber es dauerte noch mehr als ein halbes Jahrzehnt, bevor die Technik hinreichende Verbreitung aufwies und ich die Kompatibilitäsprobleme in den Griff bekam.

Die CSS-2-Pseudoklasse :hover wird für die Programmierung des Menüs in der linken Box gebraucht. Dieses Menü läuft nur mit CSS und benötigt keine Scriptsprache. Eine sehr ausführliche Erklärung der Methode findet man bei css/edge von Eric Meyer (siehe Pure CSS Menu Demo).

Da der Internet Explorer dumm wie ein Ziegelstein nichts von alledem beherrscht, mußte ich Klimmzüge anwenden. Zum Glück fand ich eine Implementation von :hover mit dynamischem HTML von Arnoud Berendsen, Martin Reurings und Robert Hanson, die ich unverändert verwende. Noch mehr Tricks stecken hinter der Simulation der positionsfixierten Boxen: Für MSIE 6 hilft es, overflow-y: hidden auf das HTML-Element zu setzen; danach benehmen sich absolut positionierte Boxen wie fixiert (das funktioniert im standard-compliant mode). Der Nachteil dieser Methode ist, daß der Scrollbalken nun nicht mehr dem Wurzelelement (d.h., dem Viewport bzw. dem HTML-Element) gehört, sondern dem BODY-Element. Daher können sie bei überbreiten Seiten außerhalb des Viewports dargestellt werden. Das ist schlimm genug; aber durch einen Bug im Browser zerstört horizontales Scrollen das gesamte Layout, wodurch der Scrollbar praktisch unzugänglich wird.

Leider spielen die früheren Versionen bei diesem „Overflow-Hack“ nicht mit, weil der Viewport bei diesen fälschlich mit dem BODY-Element und nicht mit dem HTML-Element assoziiert ist. Das könnte man nun dadurch lösen, daß man den ganzen Seiteininhalt in ein zusätzliches DIV einschließt und wie bei IE6 verfährt, mit BODY statt HTML und DIV statt BODY (verwirrt? Willkommen in der Welt der IE-Idiotie!). Aber ich habe keine Lust, mir das Design durch zusätzliches Markup aufzublähen, um einen seit 5 Jahren obsoleten Browser zu unterstützen; stattdessen löse ich das Problem recht unelegant mit JavaScript, indem ich die Navigationselemente nach jedem Scrollvorgang wieder an die richtige Position rücke.

Bereits in CSS 1 gibt es eine background-attachment property (für alle Boxelemente), die man auf den Wert fixed setzen kann. Das erlaubt es, Hintergrundbilder für verschiedene Elemente nahtlos aneinanderzufügen, ohne die freie Wahl von Schriftgröße zu opfern. Leider wird diese Methode von Microsoft Internet Explorer bis Version 6 nicht unterstützt (außer für das BODY-Tag). Da dieser Browser auch für transparent PNG-Bilder zu dumm ist, simuliere ich den Effekt mit halfscreen-Bildern (GIF). Das sieht viel schlechter aus als die entsprechende Lösung für moderne Browser. Die meisten der verwendeten Techniken werden auf css/edge ausführlich beschrieben (siehe vor allem Complex Spiral Demo).

Positionierung der Bilder

Da das Design flexibel ist und sich der Fenstergröße anpaßt, ergeben sich gewisse Probleme bei der Anordnung der Bilder. Es erscheint vernünftig, alle Entscheidungen zur Bilderpositionierung dem Browser zu überlassen, aber da erst CSS level 2 dafür vernünftige Unterstützung bietet, mußten wieder einfache Notlösungen für Den Unfähigen Browser^TM implementiert werden.

Mit der CSS-property clear können Bilder auf der Seite nach unten wandern, ohne den normalen Textfluß zu unterbrechen. Aber alte Browser kennen nur das simple HTML-Konstrukt <BR clear=right>. Ich verwende das BR-Tag, aber schalte es via CSS 2 einfach aus; damit dient es als Notlösung für CSS-2-inkompatible Browser, während moderne Software dank CSS 2 flexibler darstellen kann. In vielen Fällen wird die Positionierung der Bilder aber auch im Markup explizit spezifiziert.

Darüberhinaus verwende ich CSS-2-Selektoren auch, um zwischen horizontaler und vertikaler Anordnung von aufeinanderfolgenden Bildern zu unterscheiden. Diese Funktionalität läßt sich schlecht ohne CSS 2 nachbilden, ohne das Markup aufzublähen. Deshalb werden inkompatible Browser Bilder gelegentlich untereinander darstellen, wenn eine horizontale Anordung eigentlich besser wäre; dabei können auch große Lücken im Fließtext entstehen.

Da alle Bilderpositionierung ohne Kenntnis von Fensterbreite oder Schriftgröße stattfindet, ergibt sich kein besonders großer Spielraum für Optimierung. Ein großes Browserfenster oder kleine Schrift führen oft zu Lücken im Text, da der rechte Rand von den Bildern eingenommen wird; umgekehrt werden Nutzer von kleinen Fenstern gelegentlich von horizontalen Scrollbalken geplagt, oder die Bilder unterbrechen den Text. Dagegen gibt es kein offensichtliches Mittel (wahrscheinlich kann man es mit dynamischem HTML machen, aber das verspricht, haarig zu werden).

JavaScript

Dank der Vielseitigkeit von CSS wird nicht viel JavaScript gebraucht. Die Hauptverwendung liegt im Umschreiben einiger CSS-Regeln, um bestimmte Browsereigentümlichkeiten auszugleichen (z.B. die dümmliche Verwechslung zwischen height und min-height im Eh-schon-wissen-Browser). Wie oben erwähnt, brauche ich JavaScript für die positionsfixierten Navigationselemente in Internet Explorer 5.x und 4. Bei abgeschaltetem JavaScript scrollt die Navigation davon; allerdings gibt es immer noch spezielle Befehle, um das Layout wenigstens einigermaßen vernünftig zu halten.

Eine wichtige Funktionalität wird allerdings für alle Browser mit JavaScript realisiert: Ich brauche es für die Navigation innerhalb eines Dokumentes. Wenn man auf einen benannten Anker positioniert, scrollt der Browser soweit, daß der Ankertext genau am oberen Boxrand zu liegen kommt. Allerdings liegt bei mir dort eine Box mit Navigationshilfen zur intra-Dokument-Navigation, die den Ankertext verbergen würde! Das gilt sowohl bei externen Links auf einen Anker als auch bei dokumenteninterner Navigation.

Um das zu korrigieren, verwende ich event handler und zeitverzögerte Ausführung, um den Text einfach zusätzlich nach unten zu scrollen. Das systematische und wohldokumentierte DOM der Gecko-Browser (Mozilla Seamonkey, Mozilla Firefox, Galeon, Epiphany) erlaubt es mir, die Höhe der horizontalen Navigationsbox genau auszumessen und präzise auf den Punkt zu scrollen; bei anderen Browsern verwende ich dagegen einen Schätzwert. Die Zeitverzögerung ist bei manchen Browsern merklich, während andere (vor allem die Gecko-Familie und Opera) den Eindruck von augenblicklicher Positionierung erzeugen.

Bei ausgeschaltetem JavaScript kann ich das natürlich nicht machen. Als Notlösung verschiebe ich die horizontalen Navigationsbox an den unteren Rand des Viewports, wo sich das Problem natürlich nicht stellt. Dabei gibt es aber immer noch ein Problem mit Microsoft Internet Explorer, der (wie ich meine) die absolute Positionierung der Boxen nicht richtig umsetzt.

Für Microsoft Internet Explorer kommt JavaScript in Form von dynamischem HTML zum Einsatz, um einige CSS-2-Funktionalität zu simulieren, nämlich die Pseudoklasse :hover. Wenn JavaScript ausgeschaltet wird, funktioniert die rechte Navigationsstruktur nur noch rudimentär.

Diese Seiten lesen Sie besser mit aktivem JavaScript!

Bei ausgeschaltetem JavaScript erscheint eine kleine Box, die dem Besucher nahelegt, Scripting einzuschalten, da die Funktionalität der Seite dann schlicht und einfach besser ist. Mit Internet Explorer 6 bleibt diese Box unglücklicherweise am rechten oberen Fensterrand fix stehen und kann nicht weggescrollt werden. Das ist eine unbeabsichtigte Nebenwirkung der Methode, wie die positionsfixen Elemente mit diesem Browser erzeugt werden (absolut positionierte Boxen verhalten sich ortsfest). Durch einen Click auf diese Box gelangen Sie dann hierher.

Browser-Liste und Bugs

Die Webseite wurde mit fast allen zur Zeit (Ende 2005) verfügbaren Browsern getestet: Konqueror 3.3, Mozilla Firefox bis zu 1.5 und andere Gecko-Browser Opera 8.51, und Safari 2.0.x. Nach aufwendiger Optimierung ist die gesamte Funktionalität mit jedem dieser Browser verfügbar. Anders sieht es mit den verschiedenen Versionen von Internet Explorer aus. Mit der aktuellen Version 6.0 läuft fast alles fast richtig, aber in den älteren Versionen kommt es zu Einschränkungen: Versionen 5 und 5.5 funktionieren großtenteils, allerdings ist die Anzeige unruhig. In Version 4 ist das Layout weitgehend zerstört, aber die Funktionalität stimmt noch. Sehr alte Browser wie Microsoft Internet Explorer 3 oder Netscape Navigator 4.x sowie seltene Exemplare ohne CSS-Unterstützung ergeben eine sehr schlechte Darstellung, obwohl ich ein minimales Sicherheitsnetz auch für diese Fälle implementiert habe. Internet Explorer für Mac wurde nicht getestet.

Ein Schlüsselschritt zur Realisierung dieses Layouts war die Möglichkeit, verschiedene Versionen des Microsoft Internet Explorers parallel zu installieren. Damit konnte ich die Bugs und Bizarritäten aller Versionen (3.0, 4.0, 5.0, 5.5 und 6.0) einzeln studieren und geeigentes CSS als Gegengift entwickeln. Dazu nütze ich conditional comments, d.h., valide HTML-Kommentare, die von bestimmten MSIE-Versionen „unkommentiert“ (d.h., ausgeführt) werden. Das in solchen Kommentaren enthaltene HTML ist für alle Browser bis auf die ausgewählten Versionen von MSIE unsichtbar (downlevel-hidden conditional comment). Microsoft bietet auch downlevel-revealed conditional comments an, die allerdings nicht valide sind (diese Information verschweigen sie allerdings auf ihrer Website).

Mit dem neuen Internet Explorer 7 gelang es Microsoft wirklich, mich positiv zu überraschen. IE7 beta 2 unterstützt alle für meine Seite wichtigen CSS2-Elemente; attributbasierte Selektoren werden zwar nicht unterstützt, sind für meine Seite aber auch nicht so essentiell. Der letzte Feinschliff ist noch nicht ganz fertig, aber im wesentlichen sollte fast alles mit IE7 genauso funktionieren wie mit den anderen modernen Browsern. Meine offiziell nicht unterstützte IE7-Parallelinstallation zeigte einige kleinere Krankheiten und einige offenbar aus Kompatibilitätztgründen eingebaute Bugs, die enteder nur mindere kosmetische Probleme aufwerfen oder mit zusätzlichem CSS ganz gut beherrschbar sind. Lediglich bei JavaScript gibt es noch substanzielle Probleme, die ich in der nächsten Zeit zu lösen hoffe.

Einige immer noch offene Probleme finden sich in der folgenden Liste. Einige davon sind Limitierungen, die aus den technischen Gegebenheiten folgen und die sehr schwer, wenn überhaupt, zu korrigieren sind. Andere werden sich in Zukunft vielleicht beheben lassen. Wieder andere sind Browserfehler, die mit einer neuen Version vielleicht hinfällig werden.

Allgemeines

Die Hintergrundbilder sind immer noch ziemlich voluminös. CSS2-kompatible Browser bekommen insgesamt 82 kbytes an Hintergrundbild geliefert, während die älteren Versionen von Internet Explorer (bis Version 6) nur 41 kbytes Hintergrund sehen, da sie die gewünschten Hintergrundeffekte ohnehin nicht darstellen können. Zum Vergleich: In der alten Version kosteten Hintergrund und die Verwaltung der Frames 27 kbytes, plus einen zusätzlichen http-Zugriff pro Click beim Surfen innerhalb der Seiten. Die Länge eines durchschnittlichen Gewürztextes beträgt 31 kbytes Text und 117 kbytes Bilder.
Drucken funktioniert nur näherungsweise.
Unerwartete kleine Layout-Unregelmäßigkeiten in verschiedenen Versionen von MSIE. All die verschiedenen und einander widersprechenden Style-Sheets, die die verschiedenen Versionen und ihre individuellen Bugs abdecken sollen, wachsen mir langsam über den Kopf.
Die Suchresultate werden von Google geliefert und erscheinen in Google-typischem Layout.
Die komplexen CSS-Deklarationen verlangsamen den Seitenaufbau auf älteren Maschinen.
Internet Explorer hat Schwierigkeiten beim Anzeigen mancher Sonderzeichen, z.B. bei altgriechischem Text oder unüblichen Diakritika auf lateinischen Buchstaben. Dazu habe ich einen Workaround entwickelt, der ganz gut zu funktionieren scheint, der aber leider Eingriffe ins Markup erfordert.
Die rumänischen Sonderzeichen ț und ș werden z.T. auf vielen Systemen schlecht unterstützt. Ich betreibe beträchtliche Verrenkungen, um Internet Explorer unter Windows XP zu einem Fontwechsel zu veranlassen (ț,ș) und anderen Systemen (Konqueror, Windows vor XP, Suchmaschinen) eine Surrogatschreibweise mit ţ und ţ unterzuschieben.
Konqueror 3.3 zeigt einige Schwächen: So scrollt das Eingabefeld für die Suche nicht ganz korrekt, und während des Aufbaus einer Seite wird die Anzeige sinnloserweise gelöscht (auch bei dokumentinterner Navigation). Version 3.3.2 läuft etwas besser. Mit Version 3.5 bin ich dagegen recht zufrieden.
BIDI-Support ist bei Konqueror und Safari nicht ganz perfekt (das sieht man vor allem in der Kopfzeile des arabischen Index).
Dieser Bug ist ganz witzig: MSIE unterscheidet nicht zwischen kaf ك und keheh ک in den Namen von Ankern (und weiß Gott wo sonst noch überall nicht). Soweit ich das verstehe, kann man die beiden Buchstaben in keinem Unicode-konformen Sinn als „äquivalent“ ansehen. Trotzdem zeigen spice_arabic.html#init_ك und spice_arabic.html#init_ک für alle Versionen von IE an die gleiche Stelle.
Gecko-Browser erzeugen sinnlosen Leerraum unter rechten Floats, wenn diesen ein LI folgt. Die Verkürzung des Zeilenlänge durch die Float wird fälschlich dem LI-Block zugeordnet, statt jede Zeile bis zum unteren Rand der Float einzeln zu verkürzen. Dieser Bug geistert seit 2002 in Bugzilla herum und geht offenbar auf eine absichtliche Entscheidung der Entwickler zurück. Man kann das richtige Verhalten mit der proprietären Style-Regel LI {-moz-float-edge: content-box} erreichen, was jedoch die Darstellung von Listen in Zusammenhang mit links gefloatetem Material verferkelt (linke floats kommen auf meiner Seite zum Glück nicht vor). Siehe auch diese Demonstration des Problems. Um das Stylesheet valide zu halten, füge ich die geckospezifische Regel per JavaScript ein. Die Auswirkungen des Bugs kann man im Artikel über Borretsch sehen (die falsche Darstellung sieht man offenbar nur, wenn man JavaScript abschaltet).
Konqueror leidet am selben Bug und hat keine Lösung dafür.
Die Darstellung von komplexen Schriften ist eigentlich eine OS-Aufgabe und jenseits meiner Einflußnahme als Webautor. Aktuelle Versionen von Microsoft Windows (mit MSIE) und Mac OS (mit Safari) schneiden ganz gut ab, aber unixoide Systeme bieten nur kümmerliche Unterstützung.

Positionsfixierte Navigationselemente

Ohne Javascript muß die horizontale Navigationsleiste vom Seitenkopf an den Seitenfuß verschoben werden. Das sieht nicht gut aus, aber andernfalls funktioniert die dokumenteninterne Navigation nicht mehr richtig.
Microsoft Internet Explorer bis Version 5.5 braucht JavaScript. Die Anzeige ist unruhig (außer auf sehr schnellen Rechnern).
Microsoft Internet Explorer 6 funktioniert erstaunlich gut. Wenn ein Seitenelement, z.B. ein Bild, den rechten Rand überragt (das ist möglicherweise beim Basilikum der Fall), dann liegt auch der Scrollbalken rechts außerhalb des Viewport; horizontales Scrollen zertört aber die Anzeige der Navigationsboxen. Somit ist der Scrollbalken unzugänglich, aber Scrollen per Mausrad oder Tastatur funktioniert wie gewohnt. Das ist ein übler Fehler, aber ich sehe keinen Ansatz, ihn zu beheben.
Bei IE6 bleibt die Aufforderung zum Einschalten von JavaScript ständig am Bildschirm und kann sogar Seiteninhalte verdecken. Das wirks aufdringlich, ist aber leider nicht zu beheben.
Wenn die horizontale Navigationsleiste am Seitenfuß dargestellt wird, dann erreicht ihre Breite nicht die ganze Fensterbreite (nur bei Internet Explorer bis Version 6).
Mit Internet Explorer 7 erreicht die Seite volle Funktionalität. Zur Zeit sehe ich zwei mittelschwere Probleme, die beide mit dem onLoad-Eventhandler zusammenhängen: Erstens wir der Event zu früh ausgelöst, so daß Scrolling nicht funktioniert. Zur Lösung habe ich eine Verzögerung implementiert, die allerdings von der Länge des Dokuments abhängen muß. Auf Maschinen mit anderer Prozessorgeschwindigkeit als meiner wird dieser Ansatz wahrscheinlich versagen.
Ein zweites Problem mit onLoad-Events bei IE7: Auch ein Zurückgehen in der History löst einen onLoad-Event aus, was zu einem zusätzlichen und unerwünschten Scrolling führt. Leider kann ich zwischen den verschiedenen Quellen für die Events im Script nicht unterscheiden. Zur Demonstration des Problems: Clicken Sie bei eingeschaltetem JavaScript auf diesen Link: Das Wort „Etymologie“ am oberen Rand des Hauptfensters erscheinen. Folgen Sie nun einem Link auf der Seite und drücken Sie den Back-Knopf: Die ursprüngliche Ansicht sollte wiederhergestellt werden. Auf meiner Maschine funktioniert jedoch nur ersteres.
Mozilla Seamonkey 1.5α (nicht aber die stabilen 1.0-Releases) hält die positionsfixierten Elemente während eines Scrollvorganges nicht fest und schiebt erst danach sie mit Zeitverögerung an ihren alten Platz. Das sieht extrem schlecht aus, fast so schlimm wie mein JavaScript-Hack für Internet Explorer 5.x. Laut Bugzilla ist der Fehler bekannt und soll bis zur nächsten stabilen Version behoben werden. Möglicherweise werden zwischenzeitlich auch noch andere Gecko-Produkte betroffen sein.
Das Positionieren auf dokumenteninterne Anker ist immer noch ein Glücksspiel. Die meisten wichtigen Browser scheinen es in meinen Tests richtig zu machen, aber Probleme sind bei unüblichen Browsern/Konfigurationen/Einstellungen vorprogrammiert; insbesondere langsame Maschinen könnten Schwierigkeiten bekommen. Hoffentlich funktionieren meine Notlösungen gut genug.

CSS Menüs

Dafür brauche ich eingeschaltetes „Active Scripting“ in allen Versionen des Microsoft Internet Explorers. Sonst gibt es keine hierarchischen Menüs, sondern man muß sich durch mehrere Seiten durchclicken.
Microsoft Internet Explorer: Inkonsistente Farbgebung der Menüpunkte. Wenn man ein Untermenü aktiviert, dann verschwindet die optische Hervorhebung des übergeordneten Menüpunktes – aber nur, wenn dieser selbst bereits in einem Untermenü stand, nicht wenn er in der Navigationsbox steht. Ich glaube nicht, daß ich das lösen kann (der Code ist jetzt bereits haarsträubend). IE7 ist besser, weil die Hervorhebung immer verschwindet, wenn man ein untergeordnetes Menü aufruft.
Verschiedene IE-Versionen: Einige Objekte verändern mysteriöserweise ihre Größe, sobald man sie mit dem Mauscursor berührt: Die dunkle Fläche rund um die Suchbox (IE6) oder die Dropdown-Menuepunkte (IE7).
Ältere Gecko-Browser (z.B. Firefox 1.0.x) erzeugen manchmal unsinnige vertikale Linien, wenn man das Menü aktiviert. Bei neueren Gecko-Versionen können immer noch kleine Verwerfungen in der Hauptbox auftreten, während man das hierarchische Menü aktiviert.
Ein erratisch auftretender Gecko-Bug bei Tabellen: Die Linien werden gelegentlich im oberen Teil der Tabelle (im Bereich des Viewports) nicht dargestellt. Es hilft, wenn man die Seite neu lädt.
Konqueror hat Probleme mit dem Scrolling, wenn man dokumentinterne Anker anwählt. Oft funktioniert es beim zweiten Versuch. Das Problem hat bei verschiedenen Konqueror-Versionen offenbar unterschiedliche Ursachen: So signalisiert 3.3 einen onLoad-Event, wenn man innerhalb des Dokuments navigiert, die anderen Versionen und Browser tun das aber nicht.
Konqueror 3.5 scrollt mit lächerlich geringer Geschwindigkeit.
Opera vergißt gelegentlich, die Linkbeschreibungen (sollten beim Schweben über einem Link links unten in der Navigationsbox erscheinen) wieder zu löschen. Als Notlösung vergrößere ich die hervorgehobene Fläche, damit zumindest „übriggebliebener“ Text mit hoher Wahrscheinlichkeit gelöscht wird.

Hintergrundbilder

Microsoft Internet Explorer versagt in allen Versionen. Ich mußte beim Layout Kompromisse eingehen, um (mit allen Tricks) die Seite für MSIE darstellbar zu halten. Durch eine kreative Kombination haariger Methoden sieht es fast so aus, als ob es funktioniert, sogar mit älteren Versionen.
Die „halfscreen“ GIF-Bilder sind nicht besonders hübsch (zumindest, wenn man weiß, wie es wirklich aussehen sollte), aber ich brauche sie zur Erzeugung von „Schaltflächen“ und den entsprechenden Mauseffekten. Da der MSIE weder fixierten Hintergrund noch transparente PNG-Bilder beherrscht, sind diese GIF-Bilder mit einem schachbrettartigen Muster aus transparenten und opaken Pixeln die einzige Möglichkeit, den gewünschten Effekt zu simulieren.
Wenn keine Hintergrundbilder geladen werden, dann wird das Navigationsmenü für Internet Explorer schlecht lesbar, da ich nur die Textfarbe, aber nicht die Hintergrundfarbe, verändern kann.

Galerie: Hall of Fame und Hall of Shame

Die folgenden Screenshots dokumentieren, wie verschiedene Browser meine Seiten darstellen (Februar 2006). Der angezeigte Url ist in jedem Fall gleich, und es wurde eine kleine Fenstergröße gewählt; die Screenshots sind nochmals um den Faktor Zwei verkleinert.

I buoni…

Dieser Satz zeigt Browser mit funtionierender CSS2-Unterstützung: Konqueror 3.3, Opera 8.51, Internet Explorer 7, Firefox 1.5 und Mozilla 1.7.7. Für jeden Browser zeige ich die Darstellung ohne (links) und mit (rechts) JavaScript.

Diese Browser machen fast alles richtig. Mozilla zeichnet störende vertikale Linien um die Menüs (auf dem rechten Bild gut zu sehen). Die Verbindung zwischen den verschiedenen Ebenden des Menues ist bei IE7 nicht transparent. Andere Browserfehler sind auf diesen Bildern nicht zu sehen (siehe die obige Aufzählung für Details)

… i brutti …

Internet Explorer 6.0 (obere Reihe) ist heute der dominierende Webbrowser. Es verschlang beträchtliche Arbeit, die Seiten auf diesem Browser (fast) zum Laufen zu bringen. Internet Explorer 5.5 in der unteren Reihe arbeitet deutlich schlechter (5.01 ist sehr ähnlich). Beide Browser wurden mit (rechts) und ohne (links) JavaScript getestet (Mircosoft nennt es „Active Scripting“.

Mit der aktuellen Version des Internet Explorer 6.0 (obere Reihe) ergeben sich einige Einschränkungen: Ohne JavaScript funktionieren die hierarchischen Menüs nicht; die Transparenzeffekte sind schwierig zu erreichen und können nur unvollständig simuliert werden (in der Verkleinerung sehen sie besser als in natura aus). Die Popup-Menüs sind nicht transparent und werden inkonsistent eingefärbt. Außerdem erscheint der Hinweis auf ausgeschaltetes JavaScript positionsfixiert und kann den Text überdecken. Ein kleineres Ärgernis ist die Absatzformatierung (die erste Zeile des ersten Absatzes wird fälschlich eingerückt). Ohne JavaScript erstreckt sich die untere Navigationsleiste nicht über die ganze Seitenbreite.

Mit der älteren Version 5.5 (und auch mit 5.01) sieht es noch schlimmer aus. Die Navigationselemente werden durch JavaScript gegenläufig zum Scrolling bewegt und funktionieren bei abgeschaltetem JavaScript daher überhaupt nicht. Die Menüs haben einen unerwünschten linken Rand, der die Farbe nicht korrekt wechselt. Die Breite der Hauptbox wird falsch berechnet; ich vermute, daß das mit den extrabreiten Bilder auf der Chiliseite zusammenhängt. Dieser Bug betrifft nur ein paar Seiten, stört aber beim Lesen beträchtlich, da der Text nur mit horizontalem Scrolling vollständig zugänglich wird. Soferne möglich, sollten Leser das Fenster vergrößern.

Mit IE 4 konnte ich keine Screenshots erzeugen; das Programm stürzt permanent ab und erzeugt en masse JavaScript-Fehler (allerding ohne brauchbaren Fehlertext). Ich nehme an, daß eine native Installation (anders als meine gehackte Parallelinstallation) besser arbeitet. Die Formatierung der Navigationselemente funktioniert sehr schlecht, und die ihre Positionsfixierung per JavaScript versagt völlig.

… i cattivi

Netscape Navigator 4.8 (oben links) und Internet Explorer 3 (oben rechts) unterstützen CSS1 und JavaScript nur sehr unvollständig und funktionieren daher nur sehr beschränkt. Das Design erscheint stark vereinfacht und funktioniert nur zum kleinen Teil, aber die Texte sind problemlos lesbar. In beiden Browsern kann ich den Prolog (der auf besseren Browsern als Menü erscheint) per JavaScript überspringen, was die Lesbarkeit verbessert. Allerdings beschert IE3 dem Leser eine Menge Fehlermeldungen ohne Informationswert und läuft auch recht instabil (Abstürze bei bestimmten Dokumenten sind reproduzierbar).

Die Browser der unteren Reihe (links Dillo, rechts Lynx) beschränken sich bewußt auf die Darstellung von reinem HTML. Zum Unterschied von den vorherigen kann man sie weniger als fehlerhaft denn als extrem minimalistisch bezeichnen, weswegen sie nur für einen kleinen Anwenderkreis interessant sind.

Rückmeldungen bitte an