Diese Seiten lesen Sie besser mit aktivem JavaScript!

Technische Hinweise zu dieser Site

Rang Gewürz Anteil Zugriffe
5Ingwer1.947%
6Safran1.834%
7Koriander1.622%
8Chili1.580%
12Basilikum1.340%
13Tonka1.282%
15Cardamom1.254%
16Oregano1.177%
17Minze1.139%
18Wasabi1.112%
19Pfeffer1.081%
20Kreuzkümmel1.056%
21Curcuma1.048%
23Bärlauch1.003%
24Nigella1.000%
25Muskat0.999%
26Lavendel0.949%
27Thymian0.945%
28Beifuß0.925%
29Tamarinde0.913%
30Salbei0.904%
31Curryblätter0.896%
32Piment0.881%
33Bockshornklee0.868%
34Galgant0.846%

Das Layout die­ser Seite wurde in der zweiten Häfte von 2005 massiv über­arbeitet. Vor Jahres­beginn 2006 ver­wendete meine Seite Frames und milderte die bekannten Nach­teile mit einer Anzahl von Java­Scripts ab. Seit Anfang 2006 ist die reloaded version meiner Gewürz­seite online. Da sie auf einige sehr fort­geschrittene Methoden zur Webseiten­gestaltung zugreift, kann es auf manchen älteren Maschinen zu Dar­stellungs­problemen 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. Für jene Minderheit an Lesern, denen das Default-Layout Schwierigkeiten bereitet, biete ich eine Lösung mit alternativen Stylefiles an (siehe weiter unten).

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

Landkarte mit Zugriffen
Zugriffe auf die deutschen Gewürzseiten innerhalb der ersten beiden Juliwochen 2006. Die kleinsten Punkte repräsentieren 4 Besucher im Erfassungszeitraum. Zum Vergrößern clicken.

analytics.google.com

Rechts sehen Sie eine Tabelle der 25 belieb­testen Gewürze und ihren Anteil an den ge­samten Seiten­zugriffen; sie be­ziehen sich auf den Zeit­raum 2006 bis 2012. Die am wenig­sten gelese­nen Gewürze sind übrigens Reisfeld­pflanze, Indo­nesische Lorbeer­blätter und Viet­namesi­scher Zimt mit jeweils 0.013% Anteil am Gesamt­traffic. Die Graphik der Zugriffs­orte bestätigt wenig über­raschend, daß deutsche Seiten vor allem im deutschen Sprach­raum gelesen werden; sie ist leider sehr alt, weil spätere Versionen von Google Analytics keine so schicken Bilder erzeugen können.

HTML-Validierung

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

Mit dem WDG validator validieren 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 (in Opera ist leider dieser Validator fest eingebaut). 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.

Mit dem Validome Validator validieren 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 ziemliche Ü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.

HTML oder XHTML?

Ich wurde einige Male gefragt, warum ich die Seiten in HTML und nicht in XHTML geschrieben habe. Die schnelle Antwort ist, daß ich dazu keinen Grund sehe; die Argumente dazu wurden schon oft vorgetragen und wurden beispielsweise von Spartanicus klar zusammengefaßt; eine etwas längere Diskussion findet sich bei David Hammond.

Hier gebe ich nur eine kurze Übersicht: XHTML funktioniert mit den verbreitetsten Browsern (IE) nicht und wird von anderen (Gecko) weniger gut als HTML unterstützt (kein inkrementales Rendering); daher muß es als HTML serviert oder per content negotiation verhandelt werden. Nun ist XHTML aber trotz aller gegenteiligen Behauptungen nicht zu HTML kompatibel und wird von HTML-Renderern nur aufgrund deren Fehlertoleranz richtig angezeigt (eine Konstruktion <BR/> bedeutet in HTML etwas anderes als in XHTML). Unter den Bedingungen von content negotiation sind JavaScripts sehr heikel, da sie für XHTML anders als für HTML geschrieben werden müssen (document.write funktioniert für XHTML nicht, und das DOM ist anders aufgebaut). Und auch HTML läßt sich syntaktisch stringent schreiben, wenn man zum Testen außer Browsern auch Validatoren verwendet.

Der einzige wirkliche Vorteil von XHTML liegt in der Zusammenarbeit mit anderen XML-Dialekten wie MathML oder SVG. Die Browserunterstützung für diese Techniken ist aber so schwach, daß deren Einsatz auf einer für allgemeines Publikum gedachten Webpage ohnehin undenkbar ist.

Zeichen und Fonts

Unicode Encoded

Unicode

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:

Nicht wenige Webseitenautoren haben diese Punkte immer noch nicht verstanden, daher will ich es wiederholen: Jede in HTML geschriebene Webseite kann den vollen Bereich der Unicode-Zeichen nutzen. Das hat weder mit dem characer set (Encoding) des HTML-Editors noch des Betriebssystems zu tun. Old Persian sign Auramazdaa (U+103C8) Es gibt wirklich keinen Grund, weshalb Webseiten falsche Buchstaben zeigen und sich auf technische Gründe herausreden müßten. Zwar stimmt es, daß viele Encodings nur einen kleinen Teil des Unicode-Standards direkt enthalten, aber ein Dokument kann die fehlenden Zeichen immer über numerische character references adressieren. Wenn Sie zum Beispiel Ihre Leser mit dem altpersischen Keilschrift-Logogramm für Ahura Mazda, 𐏈, beeindrucken wollen, dann schreiben Sie einfach &#x103C8;; das Resultat sollte etwa der Graphik auf der rechten Seite des Absatzes entsprechen. Das funktioniert unabhängig von ihrer Software und unabhängig von Ihrem Server; die einzige Voraussetzung ist, daß der Besucher zumindest einen entsprechenden Font auf seinem System hat und der Browser diesen finden kann.

Wenn Sie mehr über Zeichendarstellungen lernen wollen, dann empfehle ich einen Einführungstext wie z. B. Character Set Issues von A. J. Flavell (der Autor ist verstorben, aber die Seite ist noch über archive.org erhältlich).

Die Seiten verwenden UTF-8 als transport encoding, um die Filegrößen etwas zu reduzieren. Das Encoding wird im http-Header deklariert und zusätzlich noch per <META>-Tag im File angegeben, um Probleme mit lokal abgespeicherten Seiten zu vermeiden. In früheren Zeiten hatte ich die Conservative Recommendation (UTF-8 bei 7-bit-Inhalt mit &-Konstrukten für alle nicht-ASCII-Zeichen) befolgt, aber selbst die ältesten mir zur Verfügung stehenden Browser (außer Dillo) und alle getesteten Suchmaschinen können mit UTF-8-Sequenzen eigentlich ganz gut umgehen, so daß mir diese Krücke mittlerweile eher obsolet erscheint.

Fonts

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 speziellen 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 CTL-fähige 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.

Ich halte es für eine schlechte Idee, Fonts per CSS fest vorzugeben; immerhin ergeben sich aus unterschiedlichen Ausgabegeräten und Lesesituationen zu Recht unterschiedliche Vorlieben des Lesers. Die Seiten verwenden also die im Browser fix voreingestellten Fontpräferenzen, für deren Sinnhaftigkeit der Leser, nicht der Autor, die Verantwortung trägt (Ausnahmen dazu sind diverse Hacks, um Browserschwierigkeiten vor allem von Internet Explorer auszugleichen).

Nach langem Experimentieren bin ich für mich persönlich zum Schluß gekommmen, daß mir Fonts mit breiter Laufweite und gering angedeuteten Serifen am angenehmsten zum Lesen sind (ganz im Gegensatz zur oft vehement vertretenen Vorliebe für serifenfreie Fonts). Als Standardfont für lateinischen Text verwende ich DejaVu Serif, der sich durch sein breites Zeichenrepertoir auszeichnet. Glyphenbau mit diakritischen Zeichen funktioniert im Lateinbereich hervorragend, und der Font bringt auch sehr gute Unterstützung für viele weitere Schriftsysteme mit (er versagt alledings bei vietnamesischen Vokalzeichen). Für manche Schriften muß ich dagegen auf spezialisierte Fonts ausweichen, wobei natürlich nur solche in Frage kommen, die auf meinem Defaultbrowser (Firefox 3, Linux) richtig arbeiten. Die einzige Schrift, die bei mir überhaupt nicht funktioniert, ist Aramäisch.

Armenisch DejaVu Serif
Bengali Code2000
Chinesisch DejaVu Serif (sprachabhängige Glypenformen)
Devanagari DejaVu Serif (versagt beim eyelash ra)
Ge‘ez Abyssinica SIL
Georgisch DejaVu Serif
Griechisch DejaVu Serif
Gujarati Samyak (einige Ligaturen sind korrumpiert)
Gurmukhi Code2000
Hebräisch DejaVu Serif
Japanisch DejaVu Serif
Kannada Kedage
Khmer Code2000
Koreanisch DejaVu Serif
Keilschrift Akkadian
Kyrillisch DejaVu Serif
Linear B Aegean
Malayalam Samyak (keine chillu-Formen in der Unicode-4.0-Konvention)
Oriya Samyak (viele Ligaturen fehlen)
Sichuan Yi SIL Yi
Sinhala DejaVu Serif
Tamil Samyak
Telugu Pothana2000
Thaana ???
Thai DejaVu Serif
Tibetisch Jomolhari

Hier sind ein paar Bemerkungen über die Fontauswahl in Firefox angebracht. Leider bestimmt Firefox die Font für jedes einzelne Zeichen aus der Dokumentensprache, was immer wieder zu einem fast komischen Versagen führt: Transkribiertes Hindi, Russisch oder Koreanisch (als Beispiele) erscheint daher in dem Font, der sonst für Devanagari, kyrillisch oder Hangul eingestellt ist, und nicht (was vernünftig wäre) im voreingestellten Lateinfont. Folglich sieht die Seite wie ein Flickenteppich verschiedener Schriftstile aus. Das ist unschön, aber nicht wirklich dramatisch.

Schlimmer wird es z. B. mit Dogri. Diese Sprache verwendet das Devanagari-Alphabet, aber Firefox weiß das nicht – Dogri fehlt einfach in Firefox’ interner Liste von Devanagari-Sprachen. Daher fällt der Browser auf einen sprachunabhängigen Default-Font zurück, der für alle unbekannten Sprachen zum Einsatz kommt. Wenn dieser zufällig mit dem Devanagari-Defaultfont identisch ist, haben Sie Glück gehabt; im allgemeinen ist er das natürlich nicht, und Sie bekommen z.B. Hindi und Dogri in verschiedenen Fonts zu sehen. Der schlimmste Fall tritt ein, wenn der Default-Font zwar Devanagari-Zeichen enthält, aber nicht Informationen für Ligaturbildung, die man in der indischen Typographie unbedingt braucht. Dann ist der Dogri-Text nämlich unlesbar, und es gibt keine vernüftige Möglichkeit, das zu beheben.

Außerdem kann man nicht alle Schriften oder Sprachen mit einem Default-Font versehen: In dem entsprechende Konfiguationsdialog fehlen z. B. Thaana, Keilschift oder Sichuan Yi. Stößt Firefox nun auf ein solches Zeichen, dann wird er alle installierten Fonts danach absuchen und mehr oder minder zufällig einen auswählen, der den Glyphen enthält. Fehlen in diesem Font aber Kerning- und Ligatur-Informationen, dann bekommen Sie nichts Lesbares; und das können Sie auch nicht leicht ändern, außer vielleicht mit expliziten CSS-Angaben im user style file, was wieder eigene Nebenwirkungen hat. Es ist auch schwierig, so etwas zu debuggen, weil Firefox nirgendwo mitteilt, aus welchem Font ein am Bildschirm dargestelltes Zeichen eigentlich stammt. Manchmal bekommt man ein funktionierendes Resultat, weiß aber nicht, welcher Font nun eigentlich genutzt wird – wenn Sie dann irgendeinen Font zusätzlich installieren, dann funktioniert es vielleicht nicht mehr (und Sie haben immer noch keine Ahnung).

Das schlimmste sind aber Sprachen, die mt zwei verschiedenen Schriften geschrieben werden können, z. B. Kashmiri (Devanagari und Arabisch) oder Konkani (Kannada, Devanagari und Latein). Jetzt ist der Alptraum perfekt, denn mit keinem Trick (nicht mal explizitem CSS) können Sie diese Sprachen an den Font für das jeweilige Schriftsystem binden, da helfen nur noch Klassen im Markup, und die bringen auch nicht viel. Theoretisch gibt es die Möglichkeit, die Sprachangabe im HTML-Source mit einer Spezifikation des Schriftsystems auszurüsten, aber das wirkt bestenfalls erratisch.

Fazit: Wirklich schmerzlos geht es nur, wenn man einen einzigen Font für alle Schriften verwenden kann. Das ist jedoch eine ziemlich unwahrscheinliche Option (ich frage mich allerdings, ob man sich aus all seinen Lieblingsfonts einen Firefox-tauglichen persönlichen Defaultfont zusammenbasteln kann).

Cascading Style Sheets

Valid CSS! 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 von einem weitverbreiteten Webbrowser, Microsoft Internet Explorer Version 6, 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 6 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ß die 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 und der Leser nur per Tastatur, Mausrad oder änlichem nach unten kommt.

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. Das hat auch den Vorteil, daß das Script als Fallback wirkt, wenn IE aus irgendeinem Grund in den Quirks-Modus geschoben wird (IE7 im Quirks-Modus ist allerdings eine Katastrophe).

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 partiell transparente PNG-Bilder zu dumm ist, simuliere ich den Effekt mit halfscreen-Bildern (PNG). 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).

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. Diese Methode hat eine Handvoll Nachteile, und kürzlich habe ich von einer besseren Technik erfahren (siehe unten). Leider funktioniert sie aber ohne JavaScript auch nicht sonderlich gut, versagt bei manchen Links und ist außerdem mit manchen Browsern sehr problematisch. Zur Zeit verwende ich daher beide parallel.

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.

Das Problem kann grundsätzlich auch ohne JavaScript gelöst werden. Eine Möglichkeit besteht darin, den Hauptbereich der Seite in eine eigene Box zu stecken und nicht innerhalb des BODY fließen zu lassen, aber diese Option wirft weitere Probleme auf, für die ich keine Lösungsmöglichkeit sehe (Fokus, Scrolling per Tastatur, dynamische Größenanpassung).

Eine vielversprechende Alternatve besteht darin, die Anker mit einem zusätzlichen padding auszustatten und könnte ohne JavaScript hinreichend passabel funktionieren, so daß die Notwendigkeit für zwei unterschiedliche Layouts entfällt; bei Opera und Internet Explorer konnte ich durch einen schnellen Hack diese Technik sogar nutzen, um die Anzeige während des Positionierens ruhig zu halten. Einer allgemeinen Verwendung für alle Browser auch bei abgeschaltetem JavaScript stehen aber noch einige ernste Probleme entgegen: Wegen der unvorhersagbaren Höhe der oberen Navigationsbox gibt es Komplikationen, es braucht satte Eingriffe ins Markup, mit Konqueror funktioniert es offenbar überhaupt nicht, IE7 fällt subtil auf die Nase und IE6 erwartungsgemäß weniger subtil. Fürs erste fehlt mir leider die Zeit, diese Technik entsprechend auszubauen.

Die Methode funktioniert so: Ein vergrößertes padding in einem Blockelement ist unmöglich, weil es das Layout zerstört. Bei Inline-Elementen wirkt ein solches padding nicht auf den Textfluß, aber auch unsichtbar überlagert es den davorstehenden Text, so daß dieser nicht mehr markier- oder clickbar ist. Nur bei leeren Inline-Elementen, also Konstruktionen der Form <H1><A name="ankername"></A>Abschnittstitel</H1>, ist es wirklich harmlos und kann theoretisch mit CSS A[name] {padding-top:100px} gesetzt werden. Wenn man auf einen solchen Anker positioniert, erscheint der Abschnittstitel 100 Pixel unter dem oberen Fensterrand. So weit, so gut.

In der Praxis klappt das aber nicht: Erstens enthalten alle A-Elemente auf meiner Seite Text (mühsam zu ändern), zweitens funktioniert die CSS2-Stilregel mit IE6 nicht (also eine Klasse hineineditieren), drittens müßte statt der 100px die aktuelle Höhe der oberen Navigationsbox stehen, die der Browser selbst festlegt (braucht also JavaScript, Vorsicht bei Wechsel von Fenster- oder Fontgröße), viertens ignoriert IE6 sowieso jedes Padding leerer Elemente (also doch nicht umeditieren?) und fünftens haben Padding beim Positionieren mit Konqueror gleich überhaupt keine Wirkung (Acid2 somewhere?). Und bei externen Links mit fragment identifier stellt sich dann auch noch ein Timingproblem: Die Höhe der oberen Box ist ja erst bekannt, wenn die ganze Seite bereits gelayoutet ist. Nichts davon ist unüberwindlich, aber vieles unangenehm.

Was man aber mit JavaScript machen kann: Das Padding eines nicht-leeren Ankers aufblasen, den Url auf diesen Anker setzen und das Padding wieder zurücksetzen. Das funktioniert reibungslos wenn – ja, wenn es eben funktioniert. Mit Konqueror klarerweise niemals. Internet Explorer (alle Versionen) zickt, wenn der Ankername in einer Tabelle steht. Kein Browser schafft es, wenn der Anker von einem JavaScript dynamisch generiert wurde (muß ein verbreitetes DOM-Problem sein, oder ich verstehe eine subtile Eigenschaft des DOM nicht). Zur Zeit checke ich das mit einer heuristische Abfrage und verwende die Methode wenn ich keine Probleme erwarte, und sonst eben das gewönliche window.scrollBy mit seiner unruhigeren Anzeige.

Dynamisches HTML

Unter dem Schlagwort dynamisches HTML (DHTML) versteht man verschiedene Techniken, den document tree direkt per Skriptsprache (typischerweise Javascript oder eine Variante davon) zu manipulieren. Damit kann man Inhalt und Stil einer Seite ändern, ohne neues Material vom Server zu laden.

Für Microsoft Internet Explorer bis einschließlich Version 6 kommt dynamisches 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.

Einige experimentelles und optionale Features, die nur für einige Browser implementiert sind, verwenden ebenfalls DHTML:

  1. Einige der fremdsprachigen Indices enthalten eine Gruppe von Checkboxen, mit denen man bestimmte Sprachen auswählen kann. Das funktioniert nicht mit Internet Explorer 5 und Opera vor Version 9.01 (und auch dann nur, wenn der Browser sich als als Opera identifiziert). Die Checkboxen sollten nur für die unterstützten Browser sichtbar sein. Ein Bug in Gecko betrifft den chinesischen Index: Das Layout kollabiert nach einigen Wechseln in der Anzeige. Es hilft, die Seite neu zu laden.
  2. Auch der große alphabetische Index enthält nun eine leistungsfähige Sprachselektion. Dieses Feature kann je nach Browser den Seitenaufbau deutlich verlangsamen und ist daher per Default ausgeschaltet. Ich verwende einige ziemlich schiefe Tricks, um einen guten Kompromiß zwischen Geschwindigkeit und Filegröße zu erreichen (insbesondere die sonst recht flotten Gecko-Browser und Opera zeigten recht üble Performance-Probleme mit unoptimiertem Code). Teilweise existieren zwei Versionen derselben JavaScript-Funktion, die je nach Browser ausgewählt werden. Ein Blick auf den Source wird Sie überraschen!
  3. Die teilweise langen Listen von fremdsprachigen Namen am Kopf der Gewürzartikel werden per JavaScript auf die wesentlichsten Sprachen begrenzt und erst durch Click auf einen Link wieder vollständig sichtbar gemacht. Ich hoffe, daß dies die Lesbarkeit verbessert, da die meisten Besucher die Liste ohnehin überspringen. Besucher ohne JavaScript (oder solche mit Opera vor Version 9.01, auf dem mein Script nicht so recht laufen will) sehen die volle Liste ohne eine Möglichkeit, sie abzuschalten.
  4. Erreicht man einen Gewürzartikel über einen der fremdsprachigen Indices, so wird jene Sprache, aus der der angeclickte Name stammt, zusätzlich zu den wesentlichsten Sprachen sichtbar.
  5. Die interne Suchmaschine arbeitet mit einem unsichtbaren Filterwort, das per JavaScript hinzugefügt wird; bei ausgeschaltetem JavaScript funktioniert die Suchmaschine immer noch, aber das Filterwort wird sichtbar.
    Die meisten dieser Tricks arbeiten weniger mit Manipulationen im Inhalt des Dokuments als mit Veränerungen an den assoziierten Stylesheets. Die eigentlich simple Aufgabe, eine CSS-Regel per Skript zu verändern, besteht aus zwei Teilen. Zunächst braucht man die Regel als Objekt, was relativ einfach ist: Die n-te Regel im m-ten Sheet heißt document.styleSheets[m].cssRules[n], aber der Internet Explorer besteht auf der Bezeichnung document.styleSheets[m].rules[n].

    In meinem Fall geht es darum, eine Tabellenzeile per display-Property ein- oder auszublenden. Um das Umschalten zu bewerkstelligen, gibt es vier Syntax-Alternativen, von denen IE6 und IE7 jeweils nur eine (aber jeweils eine andere) verstehen. Die Befehle zum Einschalten lauten

    1. document.styleSheets[m].rules[n].style.cssText="display:inline" für IE6 und IE8
    2. document.styleSheets[m].rules[n].style["display"]="inline" für IE7 und IE8
    3. document.styleSheets[m].cssRules[n].style.display="table-row" für IE8 und andere wirkliche Browser
    4. document.styleSheets[m].cssRules[n].style.setProperty("display","table-row",null) für wirkliche Browser (aber nicht IE8)
    Internet Explorer 8 versteht auch die dritte Variante, wenn man den inkorrekten Namen rules verwendet; spiegelbildlich beherrschen Opera und Konqueror auch die ersten beiden Versionen, wenn man das korrektere cssRules schreibt; für Gecko muß es dagegen unbedingt eine der letzten beiden sein. Internet Explorer vor Version 8 akzeptiert nur display:inline, obwohl für Tabellenzeilen in CSS2 ein eigener display-Wert table-row vorgesehen ist; der korrekte Wert display:table-row führt perverserweise zu einem JavaScript-Fehler, aber IE8 kann mit table-row richtig umgehen. Nun die gute Nachricht: Beim Ausblenden der Tabellenzeile braucht man zwar immer noch vier Typen von Zuweisung, aber display:none wird sogar von allen Browsern gleichartig verstanden. Wow.

Noch eine frustrierte Bemerkung zu diesem Thema: Seit Version 5 erlaubt Chrome nicht mehr, Styleregeln per JavaScript umzuschreiben wenn (a) die Regel aus einem externen Stylesheet (<LINK rel=...) stammt und (b) das Dokument offline gelesen (file:///...) wird. Das betrifft wahrscheinlich wenige Leser, aber mich bei der Entwicklung. Für das Ein- und Ausblenden der fremdsprachigen Namen in den Gewürzartikelnhabe ich die Funktionalität zähneknirschend per DOM-Manipulation nachgebaut, aber im alphabetischen Index ist mir das zu kompliziert, und andere Lösungen würden die Filegr&aouml;ße noch weiter aufblähen. Dumm gelaufen.

DHTML erzeugt Anzeigezustände, die nicht mit einem URL adressierbar sind. Um Besuchern zu erlauben, eine bestimmte Anzeige zu bookmarken oder zu verlinken, biete ich eine Lösung mit URL-Parametern an; diese werden intern auch bei der Sprachumschaltung zwischen Deutsch und Englisch genutzt, um das anderssprachige Dokument gleich wie das aktuelle anzuzeigen. Siehe dazu den Abschnitt über Links und beachten Sie, daß solche erweiterten Links auf manchen Browsern sehr langsam laufen.

Alternative Seitenstile

HTML enthält einen Mechanismus, mit dem der Autor mehrere Seitenstile anbietet, zwischen denen der Besucher dann auswählen kann. Das funktioniert leider nur mit JavaScript, und daher ist der Menüpunkt Display im linken Menü auch nur bei eingeschaltetem JavaScript sichtbar. Das Umschalten zwischen den alternativen Seitenstilen ist ziemlich geradlinig möglich (wie üblich aber mit browserabhängiger Syntax), der schwierige Teil liegt darin, den gewählten Seitenstil auch auf Folgeseiten zu übertragen. Die Standard-Methode erfordert Cookies, aber ich bevorzuge ein anderes Verfahren, das nur mit DHTML auskommt.

Diese DHTML-Lösung umfaßt ein Script, das alle ausgehenden Links mit einem Parameter markiert, der nach dem Click auf den Link vom onLoad-Handler der aufgerufenen Seite ausgewertet wird. Daher sind die Anzeigen mit einem alternativen Stil vollständig verlinkbar (anders als bei der Cookie-Methode). Als Nachteil ergibt sich ein langsamer Seitenaufbau, speziell auf älteren Maschinen (DHTML ist nun einmal nicht effizient); am schlimmsten ist es auf Seiten, die viele ausgehende Links enthalten, zum Beispiel in den Indices. Recht unangenehm ist es auch, daß das Zurückblättern mit der Back-Schaltfläche zum Teil unerwartete Resultate bringt. Und zuletzt gibt es Browser (na, welche wohl?), die bei mehrmaligem Wechsel des Layouts auf ein und derselben Seite den Geist aufgeben.

Die alternativen Stylefiles sind recht simpel, da sie ja im Kern nur selektiv Features des Default-Stils abschalten müssen. Lediglich der Flow-Stil, in dem die Navigationselemente mit dem Text mitfließen und nicht ortsfest bleiben, braucht etwas heftigere JavaScript-Unterstützung, um die Höhe der Navigationsbox der inneren Fensterhöhe anzupassen (bei Veränderung der Fenstergröße sollte sich das automatisch anpassen).

Kein JavaScript unterstützt?

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.

Positionierung der Bilder

Positionierung per CSS

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

Positionierung per Dynamic HTML

Selbst bei CSS2-kompatiblen Browsern bleiben nach dem Gesagten noch viele Schönheitsfehler. Der Grund ist, daß eine optimale Verteilung der Bilder auf den Text von Faktoren wie Fontgröße und Fenstergröße (bzw. Breite der Textbox) abhängt; besonders probematisch ist der Zoom-Faktor, da die Bilder bei full page zoom (optional bei Gecko, zwingend bei Opera und Webkit) mitskaliert werden und sich somit die relative Bedeutung der vorher genannten Größen zur Dimension der Bilder ändert. Nur mit HTML und CSS ist dabei nicht viel zu gewinnen, da alle diese Faktoren jenseits meiner Kontrolle liegen und nur sehr rudimentär durch fontspezifische Maßeinheiten behandelt werden können.

Natürlich ist dynamisches HTML ein Ausweg: JavaScript weiß fast alles über die relevanten Größen und könnte die Verteilung der Bilder über die Seite für jede Wahl von Fensterbreite (relevanter ist die Boxbreite), Font und Zoomfaktor neu bestimmen; sinnvollerweise macht man das in einem onResize-Eventhandler. Das ist allerdings extrem haarig, und ich tue mit die Arbeit nur an ausgesucht problematischen Stellen an – das sind aber immer noch drei oder vier in einem durchschnittlichen Gewürzartikel.

Zum besseren Verständnis lohnt es sich, die Probleme, die sich aus fließenden Objekten für die Typographie ergeben, etwas zu systematisieren. Dabei setze ich voraus, daß der Text am linken Rand der Seite gesetzt wird, während sich am rechten Rand Bilder tummeln. Die Bilder sind im wesentlichen einfache Boxen fixer Breite, die im Source am Beginn von Absätzen deklariert sind. Im einfachsten und naheliegensten Fall sollten daher die Oberkanten der Bilder genau mit den Oberkanten der damit assoziierten Absätze zusammenfallen. Manche Absätze sind auch mit mehreren Bildern assoziiert, die dann auf gleicher vertikaler Position der Reihe nach von rechts außen nach innen dargestellt werden.

In der Praxis gibt es noch weitere Gesichtspunkte: Immerhin haben Bilder ja auch inhaltliche Bezüge untereinander oder zu bestimmten Textportionen und sollten daher nicht von einem inhaltsblinden Script weit umhergeschoben werden. Manchmal gibt es auch für ziemlich lange Wörter keine Silbentrennung (schmecken kann im Rahmen von HTML/CSS/JS nur umständlich und mit geringer Erfolgsquote in schmek-ken aufgelöst werden – TeX macht das seit dreißig Jahren richtig, und natürlich kann es auch einen Buchstaben tiefstellen, ohne den Abstand zur nachfolgenden Zeile absurd aufzublähen – ich wollte ich hätte \phantom und \smash). Und in den definition lists am Anfang aller Gewürzartikel ist selbst die einfache Sentinel-Methode ganz und gar nicht schmerzlos: Die fetten Schlüsselwörter sollten als Sentinel für den folgenden Absatz dienen, brauchen aber selbst einen, wenn sie aus mehreren Worten bestehen und folglich mehrzeilig dargestellt werden können.

Dazu kommen noch die Browser-Bugs. Sentinels funktionieren am besten mit no-break-spaces, was aber bei dynamischem HTML sehr unbequem ist. Macht man es dynamisch mit white-space:nowrap, dann muß man auf einige Absonderlichkeiten von Opera und Konqueror Rücksicht nehmen, was besonders lästig wird, wenn der Sentinel mit einer Silbentrennung enden soll; und WebKit kommt heftig durcheinander, wenn ein mehrzeiliges Label einer definition list einen Umbruchsschutz erhalten soll. Ältere Gecko-Versionen können mit Trennhinweisen überhaupt nicht umgehen, und selbst ein aktueller Gecko (mehr noch Konqueror) hat oft Schwierigkeiten mit der automatischen Worttrennung an Sonderzeichen, etwa in chemischen Bezeichnungen wie 3-Methyl-4-propyl-dodecan-2-on. Dagegen hilft das proprietäre WBR-Element, das von fast allen Browsern komisch interpretiert wird und das ich daher selbst über dynamisches HTML nachrüsten muß.

Ein tückischer Bug in Opera bewirkte, daß die Sentinel-Methode oft versagte: Wenn ein Absatz wegen eines rechts fließenden Bildes gebrochen werden muß, und wenn der Umbruch an der ersten möglichen Stelle im Absatz erfolgt, dann wird bei der Berechnung der Zeilenlänge auf den Absatzeinzug vergessen; folglich ragt der Text um die Länge von text-indent in das Bild. Dieser Bug ist geradezu maßgeschneidert dazu, meine Sentinels zu konterkarieren, während er sonst keinen Schaden anrichtet (und wahrscheinlich von niemandem außer mir jemals bemerkt wurde). Glücklicherweise kann man ihn mit dynamischem HTML loswerden.

Der Vollständigkeit halber erwähne ich noch, daß Webkit fürchterlichen Ärger macht, wenn man Bilder nicht mit Absätzen sondern mit Tabellen assoziiert: Bei böser Wahl der Bildschirmgröße werden Tabelle und Bild sogar überlappend dargestellt. Full page zoom bedeutet, daß der Browser mir falsche Werte für die aktuelle Boxdimensionen liefert, in der Hoffnung, ich würde das Richtige damit machen; aber jeder lügt dabei auf eine andere Art und Weise, und keiner so, daß ich mit den manipulierten Angaben wirklich schlüssig rechnen könnte. Alle Browser (außer IE7) lassen die Bilder links unter die Navigationsbox rutschen, wenn die Fensterbreite kleiner als die Bilderbreite wird. Dieses Verhalten ist vom CSS2-Standard so vorgegeben, und zwar in der folgenden eleganten Prosa: The left outer edge of a left-floating box may not be to the left of the left edge of its containing block. An analogous rule holds for right-floating elements. Trotzdem ist es kontraproduktiv und braucht eine Menge Code im onResize-Handler zur Korrektur. Erstaunlicherweise bewirkt aber sogar dieser ätzend lange Eventhandler kein ernsthaftes Performance-Problem beim Spielen mit der Fenstergröße, nicht einmal beim lahmen IE.

Manchmal verstehe ich die Leute, die ihren Besuchern einfach eine feste Boxbreite und einen einzigen Font vorschreiben…

Browser-Liste und Bugs

Die Webseite wurde mit fast allen zur Zeit (seit Ende 2005) verfügbaren Browsern getestet: Konqueror (seit Version 3.3), Mozilla Firefox (seit 2.0) und andere Gecko-Browser (Epiphany, Galeon, Mozilla, Seamonkey, Camino), Opera (seit 8.51), Safari (sporadisch auf den alten Mac-Versionen 1.3.1 und 2.0.3, danach etwas regelmäßiger mit Version 3.0 auf Mac und Windows) und dessen Cousin Google Chrome. 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. Internet Explorer bis einschließlich Version 6 ist eine grauenvolle Ansammlung von Bugs und halbimplementierten Features, die einem Webdesigner nur drei Alternativen läßt: Entweder, man verzichtet auf raffinierte Techniken. Oder man bricht alle Standards und verscherzt es sich mit den Browsern, die es richtig machen. Oder man implementiert Features mehrfach, für jeden Browser anders. Eine schöne Zusammenfassung zum Thema IE-Irrwitz ist No, Internet Explorer did not handle it properly von Mark Wilton-Jones auf howtocreate.co.uk.

Nach aufwendiger Programmierarbeit läuft mit dem leider immer noch weitverbreiteten Internet Explorer 6.0 fast alles fast richtig (wenngleich optisch nicht optimal), aber in den älteren Versionen kommt es zu Einschränkungen: Versionen 5 und 5.5 mit eingeschaltetem JavaScript funktionieren zum guten Teil, 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. Die Syntax lautet <!--[if IE version]> This is IE version <![endif]-->, wobei man für version eine Versionsnummer (5, 5.0, 5.5000, 6 oder 7) einsetzt. Auch Vergleichsoperatoren (lt, lte, gt, gte) sind möglich. Dieser Typ von Kommentaren heißt downlevel-hidden conditional comment, wobei in Microsofts newspeak das Wort downlevel soviel bedeutet wie alles was den Standard befolgt.

This is not IE

This is not IE 5

This is not IE 6

This is not IE 7

This is not IE 8

This is acceptable

This is IE6 or Standard

This is brain-dead

Microsoft bietet auch downlevel-revealed conditional comments an, die ihren Inhalt einer gewählten Version von IE und allen nicht-IE-Browsern sichtbar machen sollen. Allerdings sind diese Kommentare nicht valide, was Microsoft in der Dokumentation dezent verschweigt. Man kann ihre Funktionalität aber auch sauber mit den validen downlevel-hidden conditional comments nachbilden. Mit der Syntax <!--[if IE version]><!--> This is IE version or standard <!--><![endif]--> erhält man z. B. einen Ausdruck, der für jeden Browser bis auf die gewählte IE-Version sichtbar ist. Dabei nutzt man aus, daß der vertrottelte Internet Explorer Kommentare grundsätzlich falsch parst und das > in den roten Sequenzen unsinnigerweise als Kommentarende auffaßt (wenn Sie im vorangehenden Satz das Wort vertrottelt sehen, dann zeigt Ihr Browser genau diesen Bug). Siehe die nebenstehende Tabelle (ein Click zeigt den Source).

Die Verwendung von conditional comments ist meiner Meinung nach erheblich vorteilhafter als die verschiedenen CSS Hacks, die auf CSS-Parsingfehlern beruhen und spätestens mit dem Erscheinen von IE7 einen neuen Alptraum heraufbeschwören.

Da ich diese Seiten unter Linux entwickle, finde ich sehr sehr angenehm, daß man Internet Explorer auch mit WINE betreiben kann. Mit geringem Aufwand kann man sich IE5, IE5.5 und IE6 von IEs 4 Linux herunterladen (benötigt satte 329 M auf der Platte). Man findet dort auch eine experimentelle aber funktionsfähige Version der IE7-Engine für Linux. Damit kann man nun bis zu einem gewissen Grad Seiten unter Linux debuggen, ohne ein anderes OS hochzufahren. Dabei gibt es aber Grenzen: Zwar wird die originale rendering engine genutzt, aber das Fontmanagement und die Bildschirmdarstellung liegen immer noch beim linuxeigenen X Windows. Daher kann man Fonts, die nur unter MS Windows erhältlich sind, nicht verwenden, und das CTL (ein wirklich starker Punkt von Windows) funktioniert ebenfalls nicht. Allerdings wird behauptet, die Installation dieses Programmes ohne gültige Lizenz für MS Windows sei illegal.

Mit dem neuen Internet Explorer 7 gelang es Microsoft wirklich, mich positiv zu überraschen. IE7 unterstützt seit beta 2 alle für meine Seite wichtigen CSS2-Elemente; er ist zwar keineswegs perfekt und unterstützt auch keine attributbasierte Selektoren, aber diese sind für meine Seite auch nicht so essentiell. 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ätsgründen eingebaute Bugs, die entweder nur mindere kosmetische Probleme aufwerfen oder mit zusätzlichem CSS ganz gut beherrschbar sind. Lediglich bei JavaScript gab es einige substanzielle Probleme, die ich mittlerweile aber für gelöst halte.

Nach den Ankündigungen Microsofts, ihr neuer Internet Explorer 8 würde den Acid2-Test schaffen, war ich voller positiver Erwartungen, die allerdings nach einer peinlichen Diskussion über das Anfordern verbuggter rendering engines im http-Header und nach zwei unterirdischen β-Versionen rasch unter den absoluten Nullpunkt abkühlte. Der erste Release Candidate scheint das vollmundige Versprechen allerdings wirklich einlösen zu können. Die Gewürzseiten liefen fast von selbst, nach gründlicher Inspektion bewegt sich die Anzahl der IE8-spezifischen JavaScript- oder CSS-Zeilen im gleichen Bereich wie bei anderen funktionierenden Browsern. Es scheint, als ob wir uns wirklich über den ersten standardkompatiblen Browser aus dem Haus Microsoft freuen können.

Browser-Sündenliste

Diese Liste umfaßt nicht nur jene Renderingprobleme, die sich aus den diversen Schwächen von Browsern ergeben sondern auch grundsätzliche Nachteile des gewählten Layouts. Rote Farbe kennzeichnet jene Einträge, die für Ihren Browser eine Rolle spielen.
Allgemeines
  • Hintergrundbilder und Verwaltung sind leider ziemlich voluminös. CSS2-kompatible Browser bekommen insgesamt 59 kbytes an Hintergrundbild geliefert, während die älteren Versionen von Internet Explorer (bis Version  6) nur 23 kbytes Hintergrund sehen, da sie die gewünschten Effekte ohnehin nicht darstellen können. Für CSS und JavaScript sind zur Zeit etwa 150 kbytes zu veranschlagen, plus ein paar weitere kbyte für die verschiedenen Versionen von Internet Explorer. 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 38 kbytes Text und 157 kbytes Bilder; das längste Einzeldokument ist der alphabetische Index mit etwa einem Megabyte inclusive (alles inclusve).
  • Drucken funktioniert nur näherungsweise.
  • Einige Browser enthalten bereits kleine Teile des irgendwann einmal kommenden Standards Cascading Style Sheets level 3, den ich dann selektiv mit JavaScript einschalte. Einerseits kann man Internet Explorer und Konquerer kaum einen Vorwurf daraus machen, einen unfertigen Standard nicht implementiert zu haben; andererseits bedeutet das ein paar Aufhübschungen für Besucher mit besseren Browsern: Transluzente Hervorhebungen (Gecko, Opera, WebKit), dynamische Spalten und abgerundete Ecken (WebKit, Gecko).
  • Die Graphiken, die zu den Validierungsresultaten verlinken, verwenden Alpha-Transparenz und werden auf Internet Explorer bis einschließlich 6.0 mit falschen Farben dargestellt. Ich benutze JavaScript, um sie durch opake Versionen zu ersetzen, die dann natürlich weniger gut aussehen.
  • 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. IE8 benimmt sich dagegen seit RC1 vernünftig.
  • Die Suchresultate werden von Google geliefert und erscheinen in Google-typischem Layout (klarerweise ist das kein Browserbug).
  • Die komplexen CSS-Deklarationen verlangsamen den Seitenaufbau auf älteren Maschinen.
  • 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, abgesehen davon, daß das Eingabefeld beim Scrollen immer noch komische Effekte macht und daß der Browser im DHTL-Bereich quälend langsam arbeitet.
  • Arora (und auch frühere Versionen anderer Browser) löscht den Bildschirm, während des Ladens einer neuen Seite – ziemlich witzlos, wenn die positionsfixierten Elemente ohnehin wieder an derselben Stelle stehen. Das führt zu einem unangenehmen Flackern, liegt aber jenseits meiner Einflußnahme als Autor.
  • IE8 bietet ein neuen Zoom-Feature, bei dem Text und Bilder gleichermaßen skaliert werden (eigentlich existiert es bereits in IE7, ist aber dort nur für fortgeschrittene Masochisten geeignet). Es funktioniert ganz brauchbar, auch wenn es das Scrollen der Seite merklich verlangsamt. Gelegentlich kommt es beim Zoomen einer Seite zu Layout-Fehlern, die sich nur mit Shift-Reload beheben lassen.
  • 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.
  • Als mikrotypographisches I-Tüpfelchen verwende ich gerne ein thin space zwischen Zahlen und Einheiten, etwa in 8 cm statt 8 cm. Opera kann damit nicht umgehen und ersetzt das Zeichen durch ein gewöhnliches Leerzeichen, was ich ganz OK finde. Internet Explorer bis einschließlich Version 7 ersetzt es jedoch durch ein überbreites Leerzeichen, was nur noch besch…n aussieht.
  • Unglaublich aber wahr: Seit mehr als zehn Jahren ist das Tag <Q> für kurze Zitate in Anführungszeichen Bestandteil des HTML-Standards, aber Mircosoft ignorierte es bis Internet Explorer 8! Grundsätzlich bietet das Q-Element den Vorteil, daß der Browser die Form der Anführungszeichen je nach Sprache (The motto is: To hell with bad browsers!) und Schachtelungstiefe selbständig wählen kann; außerdem verwendet man in Wörterbucheinträgen andere quotation marks Anführungszeichen als in direkter Rede und verwandten Strukturen. Browser ohne vollständigen CSS2-Support (erstaunlicherweise Chrome und Safari) können wenigstens Standardanführungszeichen zeigen, aber Internet Explorer macht – gar nichts. Dazu sage ich nur Für IE5–7-Anwender bedeutet das leider dumm gelaufen.
  • Konqueror hat zwei wahrscheinlich zusamenhängende Probleme beim Rendern der Tabelle mit fremdsprachigen Namen am Anfang aller Gewürzartikel. Das erste ist, daß die Tabelle verschweinert wird wenn (a) die letzte Sprache mehrere Zeilen umfaßt und (b) in der Defaultansicht einige aber nicht alle dieser Zeilen unterdrückt werden. Das passiert recht oft mit Vietnamesisch, das eben gerne am Ende der Tabelle steht: Die Zeile mit der Surrogat-Schreibweise ohne die für Vietnamesisch nötigen Betonungszeichen wird in der Default-Ansicht grundsätzlich nicht gezeigt. Da Konqueror das nicht verträgt, bleibt mir nichts anderes übrig, als die Zeile eben doch zu zeigen (andere Browser stellen sie nur dann dar, wenn man die volle Tabelle anwählt). Komischerweise macht Internet Explorer 8 exakt denselben Fehler (weniger überraschend, daß WebKit ihn auch macht).
  • Chrome spinnt: Ab Version 5 will er mir nicht mehr erlauben, per JavaScript auf den Inhalt externer Stylefiles zuzugreifen; stattdessen behauptet er einfach, das entsprechende cssRules-Objekt hätte die Länge Null. Das Problem tritt nur auf, wenn ich meine Files lokal betrachte; über einen Webserver (http:-Protokoll) läuft alles richtig. Geht’s noch?
  • Es gibt noch ein ähnliches, wahrscheinlich verwandtes Problem: Konqueror versemmelt die rechte Kante der Tabelle wenn (a) die Defaultansicht Sprachen mit drei oder mehr Zeilen enthält (das trifft auf die meisten arabischen oder japanischen Einträge zu) und (b) der Besucher auf den Link Alle Sprachen anzeigen clickt. Die Lösung ist die gleiche wie oben: Spracheinträge müssen ganz oder gar nicht gezeigt werden, deshalb muß ich vokalisiertes Arabisch und Hiragana/Katakana-Umschreibungen von Kanji eben auch in der Default-Ansicht zeigen.
  • Ein Gecko-Bug betrifft jene fremdsprachigen Indices, in denen man durch DHTML bestimmte Sprachen auswählen kann. Nach einigen Wechseln in der Anzeige können die Spalten unsinnig schmal werden, was zu unnötigen Umbrüchen innerhalb der Einträge führt. Die Anzeige wird jedoch wieder normal, wenn man alle Sprachen einblendet und danach eine beliebige Selektion wählt.
  • In der Gewürzübersicht (und an enigen anderen Stellen) verwende ich ein mit Block-Elementen fest codiertes fünfspaltiges Layout, das für entsprechend fähige Browser zu einem echten CSS3-multicolumn-Layout mit einer variablen Spaltenanzahl umgebaut wird (zur Zeit können das aber nur Gecko und Webkit, dazu Opera seit Version 11.10). Die Implemntierungen sind aber unterschiedlich: Opera arbeitet richtig, aber weder Gecko noch WebKit erkennen das Attribut bread-inside. Daher zerreißen sie gerne mehrzeilige Gewürznamen durch enen Spaltenumbruch. Bei Gecko gibt es dau eine umständliche Lösung: Dazu blähe ich das Markup ziemlich auf und setze alle Gewürznamen als Tabellenzellen – das scheint bei Gecko break-inside:avoid zu implizieren.
Zeilenumbrüche
  • Opera hat ein kleines Problem mit den Anführungszeichen: Folgt auf das mit Anführungszeichen umschlossene Zitat (oder ähnliches) eine Klammer, dann wird das dazwischenliegende Leerzeichen bei der Berechnung des Zeilenumbruchs nicht berücksichtigt. Ein zero-width space nach dem Q-Element löst das Problem: Danke, gaaanz lieb (per DOM-Manipulation mit JavaScript mache ich das an allen Stellen außer im ersten Satz dieses Absatzes). Einfügen des entsprechenden Zeichens mit der quotes-property von CSS2 ist dagegen nicht empfehlenswert, da Opera dann korrekterweise auch vor einem etwaig folgenden Satzzeichen bricht.
  • Und nochmals Zeilenumbruch bei Opera: Zwischen einem Element mit der Eigenschaft white-space: nowrap, wie hier zu sehen, und einem Satzzeichen erlaubt Opera leider Zeilenumbrüche. Dieser Satz zeigt, daß man das, wenn auch mühsam, mit DHTML beheben kann, indem man das Komma einfach in den Inhalt des Elementes verschiebt; klarerweise bedingt das gelegentlich inkonsistente Fontattribute für die Satzzeichen.
  • Opera zum dritten: Die erste Zeile von Absätzen wird falsch behandelt, wenn sie infolge eines rechts fließenden Bildes gebrochen werden muß. Opera vergißt dabei, den text-indent zu berücksichtigen, folglich ragt der Text maximal um die Länge des Absatzeinzuges in das Bild. Eine DHTML-Lösung dafür kann sich zunutze machen, daß das Mißverhalten wirklich nur an den Einzug gebundn ist: Setzt man den text-indent Null und placiert dagegen eine Box mit entsprechder Breite an den Absatzbeginn, erhält man ein optisch identisches Resultat ohne den Bug. Der Rest ist eine Übung in DHTML, margin-left und :first-letter. Glücklicherweise ist Opera schnell genug, daß man sich solche Fummeleien leisten kann.
  • Ich bin ziem­lich über­rascht, daß al­le Gecko-Ver­sionen vor 1.9 nicht mit dem soft hyphen um­gehen kön­nen und ihn ein­fach ig­no­rie­ren. Die­ses Zei­chen sol­lte eigen­tlich Punk­te zur Sil­ben­tren­nung mar­kie­ren und kommt bei mir se­lek­tiv an Stel­len zum Ein­satz, wo Bil­der eine ge­rin­ge Lauf­weite des Tex­tes be­din­gen. Die­se Ver­wen­dung steht in Ein­klang mit der HTML-4-Spe­zi­fi­ka­tion und dem Uni­code-Stan­dard, aller­dings hält ISO-8859 eine dazu in­kom­pa­ti­ble De­fi­ni­tion bereit. In dies­en Ab­satz wur­de zur Il­lustra­tion eine große An­zahl soft hyphens ein­ge­streut, Sie soll­ten da­her ei­ni­ge Sil­ben­tren­nun­gen be­obach­ten kön­nen. Arora trennt zwar, stellt aber kei­nen Trenn­strich dar.
  • Gecko versemmelt Silbentrennung in Tabellen: Wenn ein Wort länger als die Tabellenzelle ist, dann wird Silbentrennung manchmal ignoriert und stattdessen die Zelle aufgeweitet. Abhängig von Ihrer Fonteinstellung sehen Sie diesen Effekt vielleicht beim Bild der Wacholderbeeren.
  • Webkit und KHTML scheitern erbärmlich an einem soft hyphen als letztes Zeichen im Inhalt eines Tags, und Opera tut es ihnen seit Version 10.0 gleich. Diese Browser können beispielsweise im Wort Basilikum­blätter nicht an der Wortfuge trennen, perverser­weise führt diese Konstruktion bei Konqueror mitunter sogar zu halbleeren Zeilen und fehlenden Worten im Absatz. Mit etwas DHTML kriegt man aber sogar Rosen­büsche zum Blühen, indem man einfach ein no-break space an den Inhalt des Elements anfügt. Zumindest war das bis Version 7 so; ab Version 8 muß ich den soft hyphen aus dem Element rausholen und an den Beginn des nächsten Text-Knotens setzen.
  • Das proprietäre <NOBR>-Tag wurde von Netscape (these were the days…) eingeführt und erfreut sich beträchtlicher Beliebtheit, um Zeilenumbrüche in ausgewählten Textstellen zu verbieten. Seine Semantik entspricht der CSS-Stilregel white-space:nowrap, was gegen den Wortsinn auch Zeilenumbrüche an soft hyphens verhindert. Im Prinzip wird es von allen Browsern unterstützt, aber der Ärger liegt im Detail: Konqueror läßt einen solchermaßen geschützten Text in fließende Bilder (float:right) hineinragen, wenn das <NOBR> von einem Blank gefolgt wird; als Lösung kann das <NOBR> um ein Wort verküzern und das nachfolgende Blank hineinziehen (also das Folgewort direkt anschließen). Vernünftige Browser erlauben den nächsten Zeilenumbruch dann erst nach dem Folgewort (oder an einem entsprechenden Sonderzeichen innerhalb des Folgewortes), aber Opera bricht grundsätzlich am Ende des <NOBR>. Es ist nicht ganz einfach, beides unter einen Hut zu bringen (Lösung: &nbsp; verwenden oder intelligent schachteln). Und zuletzt hat auch WebKit eine Macke mit <NOBR> bzw. white-space:nowrap, und zwar innherhalb von <DT>: Der geschützte Bereich bricht zwar korrekterweise nicht um, aber er ragt inkorrekterweise in rechts fließende Bilder hinein.
  • Netscape erfand ein <WBR>-Tag als Gegenstück zu <NOBR>. Es erlaubt Zeilenumbrüche innerhalb von Worten und auch in durch <NOBR> eigentlich umbruchsgeschützten Bereichen. Allerdings sind verständlicherweise weder <NOBR> noch <WBR> in irgendeinem einschlägigem Standard enthalten, da sie nur der Präsentation dienen (ich habe sie aber in meiner custom-DTD).

    Das <WBR> wird nur von manchen IE-Versionen nach meiner Vorstellung perfekt umgesetzt (eine offizielle Spezifikation seiner Semantik existiert ja nicht). Ein möglicher Ausweg sind generierte Inhalte: Man fügt einfach ein brechbares Blank (sinnvollerweise ein zero-width space) ein. Eine geeignete Deklaration dazu wäre WBR:before {content: "\200B"; white-space: normal}. Leider ist Opera der einzige Browser, dem man dieses Tag auf diese simple Weise beibringen kann. Andere Browser benötigen mehr Hilfe in Form von DOM-Manipulationen per JavaScript (Details folgen in den nächten Punkten). Dieser Satz, der nur an den Kommata umbrochen werden kann, zeigt den Erfolg der vielen, langen Mühe.

    • Alte Versione von Internet Explorer (bis einschließlich 7) haben perverserweise die beste Unterstützung für <WBR>; IE50 ignoriert es außerhalb von <NOBR>, was jedoch ein relativ geringer Schaden ist, da dieser Browser ohnehin an den meisten Sonder/Spezial-Zeichen automatisch Umbrüche erlaubt.
    • Internet Explorer 8 ignoriert <WBR> vollständig und erlaubt auch keine Stilregeln dafür. Es wird aber korrekt als inhaltsloses Tag geparst und taucht als terminaler Knoten im DOM auf. Dort kann es per JavaScript durch etwas Sinnvolles ersetzt werden: Eigentlich sollte ein zero-width space (ZWSP) helfen, aber aus unerfindlichen Gründen will das nicht wirken; man muß ZWSP+Space nehmen. Man ersetzt also <WBR> durch so etwas wie <SPAN style="white-space: normal">ZWSP-SPACE</SPAN>.
    • Safari, Chrome und Co. bringen von Haus Unterstützung für <WBR> mit, allerdings mit dem Schönheitsfehler, daß ein auf das <WBR> folgendes Blank bei einem Zeilenumbruch erhalten bleibt und sinnloserweise am Anfang der Bildschirm-Folgezeile steht. Ich löse das ähnlich wie bei IE8, wobei jedoch zusätzlich das führende Blank im folgenden #text-Node gelöscht wird.
    • Bei Gecko-Browsern funktioniert <WBR> nur außerhalb von <NOBR>, und per Stylesheet läßt sich sein Verhalten auch nicht verändern. Das ist bizarr, weil Gecko an sich durchaus die Verwendung von Phantasie-Tagnamen in Stylesheets erlaubt, aber offenbar wird das proprietäre Tag intern anders abgearbeitet. Eine naheliegende Lösung ist es, jedes WBR-Element im DOM durch XBR zu ersetzen, und für dieses eine entsprechende Style-Regel anzubieten. Das funktioniert aber nur bei Gecko 1.9, denn bei niedrigeren Versionen erlaubt document.createElement keine beliebigen Element-Namen. Ein kompliziertere Hack wie bei IE8 würde grundsätzlich im DOM funktionieren, hilft aber beim Rendering nicht weiter, weil white-space:normal bis einschließlich Gecko 1.8 keine Wirkung zeigt, wenn das Parent-Element white-space:nowrap hat.
    • Konqueror gewinnt den Preis für die dümmste Implementation von <WBR>. Es wird als Container geparst und mit white-space:normal gestylt. Daher hat es außerhab von <NOBR> überhaupt keinen Effekt, und innerhalb erlaubt es Zeilenumbrüche an allen folgenden Whitespaces. Bei (erwartungsgemäßem) Fehlen des schließenden Tags erzeugt Konqueror weitere WBR-Elemente, die sich schlimmstenfalls bis zum Dokumentenende durchziehen. Das DOM muß gruselig aussehen! Als schnellen Fix stelle ich dem Inhalt des WBR ein ZWSP voran; damit funktioniert es wenigstens außerhalb von <NOBR> richtig, was wegen eines weiteren Konqueror-Bugs ein beträchtlicher Gewinn ist (folgender Punkt).
  • Die meisten Browser brechen Zeilen nicht nur an Leerzeichen, sondern auch an Binde-Strichen innerhalb von Worten (wie im Annex #14 des Unicode-Standards vorgegeben). Konqueror tut es jedoch nicht, und Gecko nur manchmal (ich konnte kein System dahinter erkennen). Man kann sich mit <WBR> helfen (natürlich erst, nachdem man den Browsern diesen Trick beigebracht hat, siehe oben), oder direkt ein zero-width space in den Code schreiben (womit man sich aber wieder IE bis Version 7 zum Feind machen würde). Sehen Sie selbst: Nacktes-Bindestrich-Beispiel, <WBR>-markiertes-Beispiel, zero-​width-​space-​Beispiel.
Bilderpositionierung
  • Am rechten Seitenrand fließende Bilder sind bei allen Browsern typographisch schlecht unterstützt. Die einzige Logik, die die Browser dabei verstehen, ist die folgende: Wenn ein Element des linken Fließtextes breiter ist als der verfügbare Platz, den das fließende Element übrigläßt, dann wird dieses Element hinreichend weit nach unten geschoben. Das ist zwar ein guter Anfang, aber wenn das zu breite Element ein besonders langes Wort innerhalb eines Absatzes ist, dann zerreißt der Browser den Absatz an diesem Wort. Es gibt leider keine Möglichkeit, den ganzen Absatz automatisch nach unten zu rücken.
  • Als Hilfestellung kann man den Absatz so schreiben, daß er mit dem längsten Wort beginnt und somit immer als ganzer verrückt wird. Das klingt jetzt schlimmer als es ist, denn es reicht, am Anfang einge Worte mit no-break spaces zu verbinden und im Absatzinneren durch Einstreuen von soft hyphens umbruchstechnisch kleinere EInnheiten zu schaffen. Letzteres versagt mit alten Gecko-Versionen, da die mit dem soft hyphen nichts anzufangen wissen.
  • Innerhalb des mit &nbsp; verleimten Absatzbeginns stören Binde-Striche, an denen der Browser natürlich trotzdem brechen könnte; man muß also auf einen no‑breaking hyphen ausweichen. Die naheliegende Lösung, statt des &nbsp; so etwas wie <NOBR> oder white-space:nowrap zu verwenden, scheitert an WebKit, der in einem solchen Fall den nicht brechbaren Block einfach in das fließende Bild hineinlaufen läßt.
  • Um zu verhindern, daß Überschriften (insbesondere bei definition lists) vom darauffolgenden Text getrennt werden, müssen letztere künstlich verbreitert werden, z. B. durch ein rechtes padding, das leider fontabhängig ist und nur mit Augenmaß abgeschätzt werden kann. Besteht die Überschrift aus mehreren Worten, dann fügt nur Gecko das padding rechts an die letzte Zeile an, die anderen Browser bizarrerweise an die erste.
  • Richtig schlimm wird es, wenn ein Bild mit clear:right von darvorstehenden Bildern nach unten geschoben wird, so daß seine linke obere Ecke nicht auf gleicher Höhe mit dem ersten Wort des im Quelltext folgenden Absatzes gerendert werden kann. Opera und Internet Explorer vermeiden das Problem, indem sie in einem solchen Fall immer vertikalen Leerraum im Fließtext einfügen, was selten schön, aber nie katastrophal wirkt. Die anderen Browser wollen es besser machen, und zerreißen dadurch mitunter Absätze auf äußerst unübersichtliche Weise. Ich habe dazu einen onResize event handler geschrieben, der rein heuristisch bis schwarzmagisch in Abhängigkeit von der Fenstergröße mit clear-Attributen (und manchmal Schlimmerem) herumjongliert, um das Allerschlimmste zu verhüten.
  • WebKit kann im Text als gewöhnliche Blockelemente enthalten Tabellen nicht vor dem Überlappen mit Fließelementen schützen. Diese Situation tritt auf meinen Seiten einige Male auf und wird ebenfalls durch ein explizites clear im onResize event handler gelöst. Das ist nicht schön (ja, ich habe an z-index:666 gedacht, aber das funktioniert auch nicht).
Zeichen und Fonts
  • Internet Explorer bis einschließlich Version 7 hat Schwierigkeiten beim Anzeigen mancher Sonderzeichen, z. B. bei altgriechischem Text oder unüblichen Diakritika auf lateinischen Buchstaben (Beispiel: Ἐν ἀρχῇ ἦν λόγος). Das Problem ist folgendes: Wenn IE ein Zeichen findet, für das im aktuellen Font kein Glyph existiert, dann streikt er. Als Autor kann ich aber nicht wissen, welche Fonts mit welchen Zeichen der Besucher installiert hat, daher ist es mir eigentlich nicht zuzumuten, dem Browser hier per Markup Hilfestellung zu leisten. Jeder andere Browser sieht einfach nach, welche installierten Fonts das entsprechende Zeichen enthalten, und nimmt das Zeichen eben notfalls aus irgendeinem Font – nur IE (in allen Versionen) ist dazu zu dumm oder zu faul. Als Workaround markiere ich im Markup alles, was potentiell gefährlich aussieht, und selektiere dann per CSS für diese Abschnitte Fonts, die erfahrungsgemäß auf vielen Windows-Systemen vorinstalliert sind und die einen recht breiten Zeichenbereich anbieten, etwa Arial Unicode MS oder Microsoft Sans Serif (Beispiel: Ἐν ἀρχῇ ἦν λόγος). Eine dumme Raterei mit einem optisch unbefriedigenden Resultat, aber was soll ich sonst machen?
  • 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 generell schwächere Unterstützung (mit einem modernen Konqueror oder dem brandaktuellen Firefox 3 geht es aber bereits ganz gut). Safari (Windows) versagt auf der ganzen Linie und kann (in der zuletzt von mir getesten Version) nicht einmal Arabisch.
  • Die rumänischen Sonderzeichen ț und ș werden z.T. auf vielen Systemen schlecht unterstützt. Ich betreibe beträchtliche Verrenkungen mit sed, JS und CSS, um Internet Explorer und Safari unter Windows NT/XP zu einem Fontwechsel zu veranlassen (ț,ș) und anderen Systemen (Konqueror, Windows vor Server 2003, Suchmaschinen) eine Surrogatschreibweise mit ţ und ş unterzuschieben.
  • Die Kopfzeilen des hebräischen und arabischen Index verwenden geschachtelten bi-directional override, um linksläufige Zeilen mit lateinischem Text zu kombinieren. Der BIDI-Support ist bei Konqueror und auch IE5/IE7 jedoch fehlerhaft, während IE6 und IE8 damit kein Problem haben (die Magie der geraden Zahlen?). Das folgende Beispiel zeigt den Effekt, wobei ich zur besseren Sichtbarkeit statt der tatsächlich verwendeten no-break spaces das Underline-Zeichen verwende (die beiden haben dieselben Direktionalitäts-Eigenschaften).
    1. <BDO dir=rtl> <BDO dir=ltr><SPAN>Anfang</SPAN></BDO>__
      &alef;__ &bet;__ &gimel;__ <BDO dir=ltr>Ende</BDO> </BDO>
    2. Anfang__ א__ ב__ ג__ Ende
    3. Anfang__ א__ ב__ ג__ Ende
    Die erste Zeile zeigt den im Prinzip korrekten Code, der von Konqueror 3.5 und IE5/IE7 jedoch inkorrekt verarbeitet wird: Statt die Zeile von rechts nach links mit dem Wort Anfang zu beginnen, schiebt er das Wort an des linke Ende, behält aber die zugehörigen (dunkelblauen) Underscores bzw. Blanks am rechten Rand (Zeile 2). Eine left-to-right mark unmittelbar nach dem grünen BDO löst das Problem (Zeile 3).
  • Konqueror hat weitere Schwierigkeiten mit mehrfach geschachteltem bi-directional override, wenn die BiDi-Eigenschaften auf tieferliegende Elemente vererbt werden müssen. Im Code-Beispiel steht wieder das Underscore für ein no-break space, und der Fix für den vorangehenden Bug ist bereits heimlich eingebaut.
    1. <BDO dir=rtl> <SPAN><BDO dir=ltr><SPAN>Anfang</SPAN></BDO>__</SPAN>
      &alef;__ &bet;__ &gimel;__ <BDO dir=ltr>Ende</BDO> </BDO>
    2. Anfang__ א__ ב__ ג__ Ende
    3. Anfang__ א__ ב__ ג__ Ende
    4. __Anfang א__ ב__ ג__ Ende
    Die erste Zeile zeigt den Code, wie er eigentlich funktionieren sollte; aber das Resultat in der zweiten Zeile ist für Konqueror falsch: Das Wort Anfang sollte am Anfang der Zeile, also rechts stehen, und Ende entsprechend links; Konqueror macht es genau umgekehrt, aber nur bei Anwesenheit der beiden hell- bzw. dunkelblau markieren Elemente. Stattet man das hellblaue SPAN mit einem dir=ltr aus, dann stimmt die Reihenfolge (Zeile 3), aber die Underlines/Blanks stehen dann natürlich auf der falschen Seite des Wortes Anfang; das kann man beheben, indem man sie unmittelbar vor das dunkelblaue SPAN schiebt (Zeile 4). Uff!
  • Eine BiDi-Bug in Webkit: Vokalisiertes Hebräisch oder Arabisch vermurkst unter bestimmten Bedingungen die Orientierung von Klammern. Will man z. B. das Wort gad vokalisiert und eingeklammert schreiben, so funktioniert das nicht, wenn das Markup die Direktionalität der Klammern mit dir=rtl explizit festlegt. Meiner Meinung nach ist dir=rtl aber exakt dafür da, die Direktionalität von Neutral- oder Klammerzeichen festzulegen. Beispiel: <SPAN dir=rtl lang="he">(גַד)</SPAN> ergibt (גַד). Wenn man die Klammer aus dem <SPAN> herausholt (גַד), das optionale dir=rtl wegläßt (גַד), ein weiteres <SPAN> hineinschachtelt (גַד) oder unvokalisiert schreibt (גד), dann funktioniert es plötzlich. Allerdings zeigen die alternativen Versionen leicht unterschiedliches Verhalten, wenn man sie mit der Maus selektiert. Der Bug wurde offenbar in Webkit 534 behoben, und daher ist Chrome ab Version 6 nicht mehr betroffen.
  • 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. Seit ich die Sonderzeichen aus den Anker-Namen verbannt habe, spielt dieser Bug keine Rolle mehr.
  • Noch bizarrer: Im Arabischen Index lassen sich sie Links zum Buchstaben alef nicht anclicken, wenn man Opera 9 auf Windows verwendet (mit 8 funktionierte es noch, und unter Linux klappt es manchmal). Hier sollten drei Hyperlinks stehen: أ أ أ.
  • Ein weiteres Arabisch-Problem: Opera verbindet arabische Buchsaben nicht mit dem Dehnungszeichen tatweel, zumindest nicht in meiner Linux-Version. So steht hier ـبـ der Buchstabe beh ب in der isolierten Form, obwohl eigentlich die mediale Form ـﺒـ richtig wäre. Durch diesen Bug wird die Zeichentabelle im Arabischen Index leider ziemlich nutzlos.
  • Noch ein Opera-Bug aus der Unicode-Ecke: Externe Links auf Anker, deren Ankername ein nicht-Ascii-Zeichen enthalten, funktionieren nicht, wenn der URL gleichzeitig noch Parameter enthält. Ich bin mir allerdings nicht ganz sicher, ob solche Ankernamen überhaupt erlaubt sind: In der DTD ist das name-Attribut als CDATA deklariert, andererseits murmelt das W3C in dieser Angelegenheit krauses Zeug: Der name-Attributwert darf entities enthalten, aber nicht-ASCII-Zeichen müssen UTF-8-artig umschrieben werden da sie in URIs nicht erlaubt sind. Hier einen Unterschied zwischen entities und codierten Zeichen zu machen erscheint mir reichlich hirnfrei. Das ist mir entschieden zu kompliziert, da benenne ich defensiverweise lieber meine Anker um (sorry für etwaige externe Links). Seither funktioniert auch Opera wieder richtig.
  • Konqueror verstarb reproduzierbar beim Öffnen des Tibetischen Index. Es stellte sich heraus, das jedes der Drei Juwelen, in diesem Fall die Vokalzeichen für RR, L und LL, den Browser aus dem Kreislauf von Öffnen und Schließen befreit und stattdessen ins Nirvana schickt. Nach heftiger Meditation war ich versucht, das Problem einfach zu ignorieren (was wahrscheinliche einen Konqueror-User pro Dekade getroffen hätte) oder aber ebenso einfach die drei kaum jemals verwendeten Buchstaben aus der Tabelle zu entfernen (was wahrscheinlich drei Schriftkundige pro Dekade bemerkt hätten); aber ich entschied mich für den Mittleren Weg, und und nun sind die entsprechenden drei Tabellenzeilen nur für Konqueror abgeschaltet. Mit einem Bodhi-Baum in der Nähe wäre ich vielleicht auf einen besseren Gedanken gekommen; in der Zwischenzeit hat aber der Herr, der auf die Welt herabblickt, das Problem in Version 4 ohnehin gelöst. ཨོཾ་མཎི་པདྨེ་ཧཱུ་
  • Eine prinzipielle Gecko-Schwäche: Gecko nutzt die Sprachinformation im HTML-Source für die Fontauswahl. Das ist oft kontraproduktiv, da z. B. transliteriertes Russisch mit demselben Font dargestellt wird wie Russisch in cyrillischen Buchstaben und in einem anderen Font als sonstiger lateinschriftlicher Text. Lateinische Buchstaben in chinesischen Fonts haben oft für Latein-Typographie völlig ungeeignete Breiten. Das Problem wäre weitgehend gelöst, wenn Gecko die Fontauswahl an der Schrift und nicht an der Sprache festbinden könnte, aber das tut er eben nicht.
  • Eine verschärfte Version des obigen Problems tritt bei komplexen Schriften auf: Das Wort 'manipuri' in Bengali-Schrift Sprachen, die Gecko nicht kennt, werden im Defaultfont dargestellt und müssen, wenn der Font in dieser Hinsicht schwächelt, ohne CTL auskommen. Zur Demonstration diene die Bezeichnung der Sprache Manipuri in nativer Schrift, einmal per Sprachauszeichnung als Manipuri ausgewiesen (মণিপুরি, ist wahrscheinlich falsch) und einmal als Bengali (মণিপুরি, ist wahrscheinlich richtig); ein Referenzrendering ist rechts angegeben. Zu den indischen Sprachen, bei denen Gecko in diesem Sinne versagt, gehören Konkani, Dogri, Newari (Nepalbhasa) und etwas überraschenderweise auch Bihari (Maithili), die alle in Devanagari geschrieben werden; außerdem sind auch die Transkriptionen von nicht-Devanagari-Sprachen nach Devanagari im indischen Index davon betroffen. In manchen Fällen hilft es bizarrerweise, ein Schriften-Subtag einzusetzen (also z. B. lang="bn-Deva" für Bengali in Devanagari-Schrift). Das funktioniert aber nicht immer, und ich befürchte, daß hier Fonteigenschaften eine Rolle spielen, die ich nicht durchschaue; mit Bengali-Schrift klappt es gleich überhaupt nicht (Test: মণিপুরি ist zumindest bei mir falsch), daher muß ich brutal werden und die korrekte Sprachauszeichnung im Source per JavaScript zu Hindi (Nepalbhasa) oder Bengali (Manipuri) etc. manipulieren. Dann funktioniert die Darstellung wieder, aber es ist mühsam zu machen, die Files sind länger und das Script braucht auch Zeit. Seufz.

    Dieses Problem scheint ab Gecko Version 1.9.1 (in Firefox 3.5) entschärft zu sein. Die Zeichen stammen zwar immer noch aus verschiedenen Fonts, werden aber wenigstens richtig gerendert. Ich verstehe nicht, wie das gemacht wird, bin aber zufrieden.

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 zerstö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 wirkt 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 mindere Probleme, die beide mit dem onLoad-Eventhandler zusammenhängen: Erstens wird der Event zu früh ausgelöst, so daß Scrolling nicht funktioniert. Als Folge positioniert der Browser das dokument nicht ganz richtig im Viewport, wenn er einem Link mit fragment identifier folgt. 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. IE8 zeigt denselben Fehler. Vielleicht mache ich ja auch etwas falsch…
  • Ein zweites Problem mit onLoad-Events bei IE7 und auch IE8: 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 sollte 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 (und auf Ihrer möglicherweise sogar keines).
  • Die überflüssigen onLoad-Events wirken sich besonders bei den Indices sehr übel aus, da in diesen Dokumenten für alle ausgehende Links onClick-Handler registriert werden – beim alphabetischen Index sind das immerhin 10000 Stück. Das schmerzt, zumal IE (in allen Versionen) ohnehin überdurchschnittlich langsam ist.
  • Großes Kino in IE8 RC2: Wenn man den Alphabetischen Index abwärts scrollt, dann erreicht man einen Punkt (bei mir rund um den Buchstaben R), an dem die positionsfixierten Elemente allmählich verschwinden und Leerraum hinterlassen. Benannte Anker funktionieren nicht jenseits dieses Punktes, und Links benehmen sich komisch. Ich war richtig perplex, daß ich diesen Bug in der endgütigen Version nicht mehr verifizieen konnte. Haben sie, mirabile dictu, ihn etwa behoben?
  • 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 Zeitverzö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 (z. B. Firefox 3) 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.
  • Alle WebKit-Browser (z. B. Safari, nicht jedoch Konqueror) leiden an folgendem Problem: Das Positionieren auf einen internen Anker funktioniert nicht zweimal hintereinander. Das hat mit meinen komplizierten Verrenkungen zu tun, mit denen ich den Zielanker nicht an die obere Fensterkante, sondern unter die Navigationsbox bringen will. Das Problem läßt sich beheben, indem man weniger komplizierte Verrenkungen durchführt, allerdings um den Preis, daß die Anzeige etwas flackert. Clicken Sie z. B. auf Galerie, scrollen Sie ein paar Zeilen mit Maus oder Keybord und clicken Sie nochmals auf Galerie: Eine Zehntelsekunde sieht es aus, als ob der Browser abstürzen wollte. Einfache Lösungsversuche mit JavaScript schlugen fehl, und so bleibt dieser Fehler fürs Erste bestehen.
  • Da Internet Explorer 6 das <LABEL>-Tag nicht kennt, müssen die Benutzer die Checkboxen in den diversen Sprachselektions-Angebote genau treffen. Das könnte man mit onClick-Handlern beheben, aber die Arbeit lohnt wohl nicht.
  • Arora, ein simpler Browser für verschiedene Plattformen, der auf WebKit aufbaut, verwendet in meiner Version 0.4 eine ziemlich alte WebKit-Version mit kaputtem Transparenz-Support: Alle Elemente mit gesetzter opacity sind unsichtbar (auch mit opacity:1). Auch einige modernere Browser wie Safari und Camino haben manchmal Probleme mit Transparenzen.
    Checkboxen mit Firefox 3.6.2 / Gecko 1.9
    Darstellung von Checkboxen mit Firefox 3.6.2 (aus dem kyrillischen Index): Links Defaultansicht unter Linux, Mitte dasselbe unter Windows (genauer gesagt wine) und recht Ansicht unter Linux mit verringerter Opazität inaktiver Checkboxen.
  • Kein Bug im engeren Sinn, aber ziemlich hirnfrei: Alle Browser der Gecko-Familie stellen Formular-Checkboxen mit disabled-Attribut fast genauso dar wie aktive Checkboxen (bei anderen Browsern sind die Darstellungsunterschiede nach meinem Geschmack oft zu gering, nur Internet Explorer ist hier einmal zu loben). Da CSS auf Checkboxen nicht wirkt, versuche ich, sie etwas auszugrauen, indem ich ihr parent-Element mit verringerter Opazität darstellen lasse.

    Zu meiner Überraschung scheint dieses Verhalten jedoch nur unter Linux aufzutreten. Die Screenshots rechts zeigen klar, daß ohne den Opazitäts-Trick inaktive von aktiven Checkboxen auf Linux fast nicht zu unterscheiden sind, während die Windows-Version desselben Browsers sich durchaus vernünftig verhält. Die Checkboxen in der zweite Zeile sind inaktiv, die der dritten Reihe aktiv aber nicht angewählt.

CSS Menüs
  • Dafür brauche ich eingeschaltetes Active Scripting in allen Versionen des Microsoft Internet Explorers bis 6.0. 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-Menüpunkte (IE7).
  • Ältere Gecko-Browser (z. B. Firefox 1.0.x mit Gecko 1.7) erzeugen manchmal unsinnige vertikale Linien, wenn man das Menü aktiviert. Bei neueren Gecko-Versionen (1.8) können immer noch kleine Verwerfungen in der Hauptbox auftreten, während man das hierarchische Menü aktiviert. Gecko 1.9 ist, wie meistens, fehlerfrei.
  • Ein erratisch auftretender Gecko-Bug (1.8) 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. Version 1.9 ist sauber.
  • 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. Ich versuche, das zu umgehen, indem ich den Gebrauch der scrollBy-Methode vermeide und direkt in den scrollTop schreibe, wenn es sicher erscheint.
  • Konqueror 4 konnte ich leider nicht testen.
  • Opera unter Linux vergißt gelegentlich, die Linkbeschreibungen (sollten beim Schweben über einem Link links unten in der Navigationsbox erscheinen) wieder zu löschen (das ist ein Probem des Graphik-Backends, von der DOM-Seite her sieht alles richtig aus). Dieses Problem konnte nur unter beträchtlichem Aufwand gelöst werden, wobei onMouseOut-Handler und zeitverzögerte Exekution eingesetzt werden, um eine leere Dummy-Box vorübergehend über die fragliche Stelle zu schieben und damit ein redraw zu erzwingen. Das hatte fast IE6-Niveau!
Hintergrundbilder
  • Microsoft Internet Explorer versagt in allen Versionen bis einschließlich 6.0. 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 PNG-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 PNG-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 6 schlecht lesbar, da ich nur die Textfarbe, aber nicht die Hintergrundfarbe, verändern kann. In anderen Browsern funktioniert dagegen ein automatischer Fallback, der fast dasselbe Layout wie der hintergrundbildfreie alternative Seitenstil liefert.
  • Ein extrem merkwürdiger Bug mit dem Apple-Browser Safari nervte mich für mehr als ein Jahr: Sobald man eine Style-Regel per DHTML umschreibt (z. B. bei Sprachauswahl in Indices oder Gewürzartikeln), verschwinden alle Hintergrundbilder. Da Safari auf meinem Rechner damals nicht lief und die Sache zweifellos eine längere, genauere Untersuchung erforderte, konnte ich das Problem lange nicht verstehen. Glücklicherweise ist nun ein Linux-Port von Googles Browser Chrome erschienen (der ebenfalls auf WebKit als Rendering Engine aufbaut). Mit den netten Developer-Tools von Chrome konnte ich das Mysterium schließlich lösen: Der hintergrundfreie alternative Seitenstil hatte sich selbstständig eingeschaltet. Es stellte sich heraus, daß die Eigenschaft disabled von LINK-Elementen, die zu alternativen Seitenstilen gehören, inkorrekterweise mit false initialisiert sind, obwohl diese Seitenstile ja per default inaktiv sind. Das scheint den Browser normalerweise nicht zu verwirren, sondern erst, wenn man mit DHTML Style-Regeln umschreibt – ein überdurchschnittlich komplexer Bug. Eine simple Initialisierung auf true löst das Problem.

Browser-Empfehlung

Glücklicherweise kann ich nun alle wichtigen und zahlreiche kleinere Browser auf meiner Maschine laufen lassen, mit der einzigen aber bitteren Ausnahme von Internet Explorer 8. Daher kann ich sie gut miteinander vergleichen, wobei man natürlich berücksichtigen muß, daß native Windows-Versionen oft besser laufen als hastige Ports (Opera, Chrome) oder Trickserein mit wine.

Screenshot mit verschiedenen Browser-Fenstern

Als Schlußfolgerung kann ich für meine Seite, aber auch ganz grundsätzlich fürs Web, vor allem die Gecko-Browser empfehlen; von diesen ist Mozilla Firefox der populärste, aber die anderen Mitglieder der Familie (Seamonkey, Galeon, Epiphany, Camino) hatten zumindest in der Vergangenheit im Wesentlichen denselben Funktionsumfang. Allerdings läuft die neue Gecko-Version 1.9 so extrem sauber und schnell, daß Firefox 3 alle anderen Gecko-Browser, die noch mit Gecko 1.8 arbeiten, zur Zeit aussticht. Die bekannte Gecko-Schwäche, daß komplexe Schriften mangelhaft oder gar nicht dargestellt werden, fällt bei Firefox 3 dank des neuen Cairo-Backends ebenfalls weg.

Auch Opera ist ein ausgezeichnetes Produkt und die ideale Wahl für alle, die einen schlanken, schnellen und vernünftig featurreichen Browser suchen (allerdings mit Abstrichen bei den komplexen Schriften, die unter Windows beschränkt und unter Linux gar nicht funktionieren) – auch bei Sicherheit und Stabilität kann er punkten. Opera ist sehr standardkonform und erlaubt es sogar (als einziger getesteter Browser!), CSS-Selektoren per JavaScript umzuschreiben (damit konnte ich ein nettes kleines Feature in den Ge‘ez-Index einbauen). Außerdem ist Opera 10 der klare Gewinner meiner Benchmark-Tests und verdient damit voll seine Bezeichnung als The fastest Browser on Earth.

Der KDE-Browser Konqueror läuft schnarchlangsam und schneidet beim JavaScript-Support eher schlecht ab, glänzt aber dafür bei den komplexen Schriften (die er bereits lange vor Firefox beherrschte), und manche lieben ihn auch, weil er sich in den KDE-Desktop perfekt einpaßt. Seine Engine, KHTML, wurde unter dem Namen WebKit von Apple wesentlich weiterentwickelt.

WebKit ist die Engine im von Apple entwickelten Safari-Bowser, der zuerst für MacOS und danach auch für Windows erschien (man kann ihn aber auch unter Linux zum Laufen bringen). Safari ist trotz seiner vielfachen Zicken ein empfehlenswerter Browser mit besonders herausragendem Schriftbild; angeblich hat die Mac-Version weniger Schwächen als die immer noch etwas von Kinderkrankheiten geplagte Version für Windows. Alle Rendering-Eigenheiten von Safari findet man auch bei Google Chrome, für das es sowohl einen wine-Port als auch eine immer noch frühe native Linux-Version gibt. Google Chrome ist ein ziemlich minimalistisches und auf Kernaufgaben konzentriertes Produkt mit einem superschlanken User-Interface und einer überdurchschnittlichen Performance. Die Linux-Version macht rasche Fortschritte und sieht bereits jetzt sehr vielversprechend aus; insbesondere scheinen komplexe Schriften recht ordentlich implementiert zu werden. Zuletzt gibt es noch den eher simplistischen Arora-Browser von Trolltech, der für verschiedene Betriebssysteme verfügbar ist. Leider verwendet meine Version 0.4 eine uralte WebKit-Engine mit zahlreichen fehlenden Features und dafür einigen komischen Bugs.

Mit Internet Explorer 8 hat Microsoft wirklich gute Arbeit abgeliefert: Die für mich wichtigen Webstandards sind soweit richtig implemtiert, daß dieser Browser nicht mehr Arbeit als die Konkurrenz macht. Allerdings läuft er ziemlich lahm, und es fehlen haufenweise moderne Features, die auf meiner Seite allerdings optional sind (CSS3) oder gar nicht gebraucht werden (XML und Konsorten); diese Standards neu, teilweise unvollständig oder experimentell und werden daher heute nur auf sehr wenigen Webseiten genutzt. Das Rendern komplexer Schriften erfolgt vorbildlich, und er rendert den Indischen Index besser als jeder andere Browser (gleichauf mit IE7); selbst die besonders tückischen Schriften von Malayalam und Oriya werden sauber dargestellt, allerdings fehlen die neuen Features von Unicode 5.1 fü Malayalam, zumindest unter Windows XP.

Internet Explorer 7 hat rundherum kleinere Defizite, aber er ist trotzdem ein passabler und einigermaßen moderner Browser, den man ohne schlechtes Gewissen empfehlen kann. Der unvollständige CSS2-Support (sehen Sie hier Anführungszeichen? Sie sollten!) und die erschreckend lahme Performance sind jedoch ernsthafte Kritikpunkte. Die ausgezeichnete Performance bei komplexen Schriften verdient positive Erwähnung. Die früheren Versionen des Internet Explorer, also in der Praxis vor allem Version 6, sind allerdings APITA und sollten, schon aus Mitleid mit gefrusteten Webseitenautoren, vermieden werden. Ich gebe mir zunehmend weniger Mühe, IE6-Bugs zu umgehen, und irgendwann einmal wird die Seite mit diesem selbst für das Museum zu schlechten Stück nur noch rudimentär funktionieren. Über noch ältere Versionen schweige ich.

Galerie: Hall of Fame und Hall of Shame

Die folgenden Screenshots dokumentieren, wie verschiedene Browser meine Seiten darstellen (November 2008). 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 funktionierender CSS2-Unterstützung: Konqueror, Safari, Chrome, Opera, Internet Explorer 7, Firefox und Mozilla. Für jeden Browser zeige ich die Darstellung ohne (links) und mit (rechts) JavaScript.

Konqueror 3.5 (KHTML)
Konqueror Screenshot (kein JavaScript) Konqueror Screenshot
Safari 3 β (WebKit)
Safari Screenshot (kein JavaScript) Safari Screenshot
Chrome β (WebKit)
Chrome Screenshot (kein JavaScript) Chrome Screenshot
Opera 9.52 (Presto)
Opera Screenshot (kein JavaScript) Opera Screenshot
Internet Explorer 7 (Trident)
Internet Explorer 7 Screenshot (kein JavaScript) Internet Explorer 7 Screenshot
Internet Explorer 8 (Trident)
Internet Explorer 8 Screenshot (kein JavaScript) Internet Explorer 8 Screenshot
Mozilla 1.7.13 (Gecko 1.7)
Mozilla Screenshot (kein JavaScript) Mozilla Screenshot
Firefox 3.0.4 (Gecko 1.9)
Firefox Screenshot (kein JavaScript) Firefox Screenshot

Diese Browser machen fast alles richtig, aber einige Probleme lassen sich trotzdem erkennen: Mozilla zeichnet störende horizontale oder vertikale Linien um die Menüs (auf dem rechten Bild gut zu sehen). Alle Gecko-Browser ziehen die Submenues vertikal zu sehr in die Länge; mit JavaScript kann ich gegensteuern. Die Verbindung zwischen den verschiedenen Ebenen des Menüs ist bei IE7 nicht transparent. Opera hat Probleme bei den Erläuterungen in der orangen Box links unten, die durch JavaScript (sehr aufwendig) korrigiert werden. 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) war lange der dominierende Webbrowser, und er hat heute noch einen enormen Marktanteil, nur übertroffen von seinem Nachfolger IE7 . 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).

Internet Explorer 6.0 (Trident)
Internet Explorer 6.0 Screenshot (kein JavaScript) Internet Explorer 6.0 Screenshot (JavaScript)
Internet Explorer 5.5 (Trident)
Internet Explorer 5.5 Screenshot (kein JavaScript) Internet Explorer 5.5 Screenshot (JavaScript)
Internet Explorer 5.0 (Trident)
Internet Explorer 5.0 Screenshot (kein JavaScript) Internet Explorer 5.0 Screenshot (JavaScript)

Simulierter Hintergrund mit halfscreen-PNG-Bilder in IE6 im Vergleicht zum gewünschten Effekt
Linker oberer Rand der Hauptseite, dargestellt mit Internet Explorer 6 (oben) und Seamonkey (unten)

Mit zwar nicht mehr aktuellen, aber weitverbreiteten 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. Die obere Navigationsleiste erstreckt sich nicht nicht über die ganze Seitenbreite. Das Photo der roten rocoto-Früchte wird teilweise unter den linken Navigationsbereich geschoben und erscheint daher abgeschnitten (es sollte eigentlich bei kleinen Fenstergrößen vertikal positioniert werden). Ein kleineres Ärgernis ist die Absatzformatierung (die erste Zeile des ersten Absatzes wird fälschlich eingerückt).

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 von IE 5.5 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. Sofern möglich, sollten Leser das Fenster vergrößern. IE 5.0 berechnet interessanterweise die Laufweite richtig, stellt die Navigationsleiste oben aber rechtsbündig dar (dieser Bug wird durch die Anwesenheit eines Bildes am rechten Boxrand ausgelöst) und placiert Bilder fast immer untereinander statt nebeneinander; deshalb kann man nur ein einziges Bild statt der geplanten Dreierreihe sehen.

Mit IE 4 konnte ich keine Screenshots erzeugen; das Programm stürzt permanent ab und erzeugt en masse JavaScript-Fehler (allerdings 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 Positionsfixierung per JavaScript versagt völlig.

… i cattivi

Netscape Navigator 4.8 Screenshot (JavaScript) Internet Explorer 3 Screenshot
Dillo 2.0 Screenshot Lynx 2.8.5 Screenshot

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 (da diese Brower auf meiner aktuellen Maschine nicht mehr laufen, verwende ich einen Screenshot vom Sommer 2006). Das Design erscheint stark vereinfacht und funktioniert nur zum kleinen Teil, aber die Texte sind problemlos lesbar. 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. Die Unterstützung für UTF-8 ist bei Netscape schlecht und bei Dillo bis Version 2.0 nicht vorhanden (aber selbst mit aktuellem Dillo sehe ich keine arabische, indische, chinesische oder andere nicht vom Griechischen abgeleitete Schrift).



Unicode Encoded Mit dem WDG validator validieren Mit dem Validome Validator validieren

Top    Validierung    Unicode    Style Sheets    JavaScript    Bilder    Browsers&Bugs    Galerie   (i buonii brutti  e  i cattivi)    Bottom