This site works better with JavaScript enabled!

Technical notes about this site

RankSpiceFraction
5coriander1.692%
6saffron1.624%
7cumin1.621%
8ajwain1.524%
10ginger1.442%
11basil1.438%
13nigella1.420%
14pepper1.362%
15sumac1.325%
16paprika1.245%
18thyme1.231%
19nutmeg1.229%
20vanilla1.225%
21fennel1.188%
22curry leaf1.182%
23fenugreek1.172%
24caraway1.167%
25cloves1.137%
26oregano1.129%
27cardamom1.120%
28sage1.081%
29anise1.032%
30chile1.004%
32sesame0.924%
33turmeric0.918%
34mint0.914%

I changed the lay­out of this site massively during the second half of 2005. Before 2006, my site used frames and mitigated the associated problems by a host of JavaScripts. Since 2006, a reloaded version of the spice pages is online. This new version is somewhat experimental as it uses advanced methods of web layout some of which might be poorly supported on older browsers. Starting with 3 March 2006, the new version is served by default, awaiting your feedback.

The new layout is flexible and fully resizeable. There is no optimization for a particular window size, although small windows (below 500 px) will become increasingly problematic. It also does not depend on particular font size or shape. There is little use of graphics apart from background images; most of what you see on the screen is just text (also the buttons on the right hand side). Moreover, there is no invalid code in the HTML nor in the CSS.

The disadvantages of the new design are its highly complex and complicated nature (my penalty, not yours) and consequently slow rendering on older computers. Also, file sizes have increased by about 5 kbytes compared to the older version; yet this disadvantage might be compensated by the smaller number of http accesses necessary. For a minority of readers having problems with the default layout, a solution with alternate style sheets was implemented (see below).

I am indebted to Jonas Fansa [يونس فنصه] for his numerous aids and counsels in matters of aesthetics and style. He also provided the background image, which shows the Chinese spice mixture 鹵水料 (see cassia for more).

Access Statistics Map
Accesses to the English Spice Pages during the first two weeks of July, 2006. The smallest marks represent 10 or more visitors. Click to enlarge.

analytics.google.com

On the right side, you see a table of the 25 most popular spice articles, averaged over the time from 2006 to 2012, and their fraction among the total page accesses. The least accessed spices were Mexican tarragon, paracress, gale, Vietnamese cinnamon, Tasmanian pepper and water pepper with 0.17 to 0.13%. The map showing the geographic distribution of my visitors is very old and rather outdated, but such pretty pictures can no longer be generated with Google Analytics. A more recent statistics would show that India has become much more important over the last half decade.

HTML-Validation

This site is written in a dialect of HTML 4.01 Transitional which contains a couple of non-standard elements, in particular, <NOBR>. The DOCTYPE declaration in the page header refers to a self-written DTD which defines that dialect in a formal way (custom DTD).

Validate using the WDG validator Using that homebrew DTD should allow for validation, which means checking the formal agreement between the syntax rules in the DTD and the actual code of an HTML document using an SGML validator. The two most popular validators are the W3C Validator and the WDG Validator. Unfortunately, the former (used as built-in validator for Opera) fails to validate documents with custom-DTDs. The latter, however, allows for validation of every single page of this site. To facilitate the process, every page contains a button at the page bottom which links directly to the WDG validation results.

Validate using the VALIDOME Validator Another product of validator type is Validome. That program checks not only for syntactical correctness according to the DTD, but performs numerous more tests that aim at properties that are part of the HTML standard, but cannot be expressed in the form of a DTD. Pages passing the WDG validator can still fail on these additional tests and will then be declared invalid by Validome. I feel that this somewhat overstretches the term validation, but for a web author, the fussy character of Validome is very helpful.

Validome is a very complex program and still under active development. Thus, pages that would validate fine in the past may become invalid in later versions of Validome, because new features and tests have been added in the meanwhile. Moreover, the rapid development of Validome quite often gives rise to bugs that will result in valid pages failing the validator. Fortunately, the Validome team will usually fix such bugs in short time after they get reported.

HTML or XHTML?

Several people have asked why I chose HTML and not the more modern XHTML for the writing of this page. The quick answer is that I see no reason for this; the arguments have been exchanged numerous times before, and Spartanicus gives a clear summary of them, and a longer discussion is found at David Hammond’s site.

So, here is a slightly longer explanation: XHTML does not work at all with the most common browsers (IE), and others (Gecko) have poorer support for XHTML than for HTML (incremental rendering of tables does not work). Thus, XHTML has to be served as HTML, or the content-type must be determined by content negotiation. Yet, despite all claims to the opposite, XHTML is not compatible to HTML and can be interpreted by HTML renderers only because of their traditionally robust error handling or even purposeful violation of the specification (a construct like <BR/> means something different in HTML than in XHTML). Moreover, JavaScripts are a pain to write if the content-type of the document is variable, since they work differently in XHTML and HTML (document.write is not allowed in XHTML, and the DOM is different in the two languages). Syntactical stringency is no issue for HTML if the page testing is done both by browser and by validator.

The true advantage of XHTML is its easy cooperation with other XML dialects like MathML or SVG. Unfortunately, browser coverage for these techniques is abysmal, which means that they cannot be used for any general-purpose web page, anyway.

Characters and Fonts

Unicode character model

Unicode Encoded Due to its multilingual nature, this site employs many different scripts, which are represented using the Unicode character model. Unicode is a highly sophisticated and complex international standard that allows arbitrary mixing of scripts on a singe web page; it is still work in progress. Creating multiscript web pages was not possible in pre-Unicode days.

Some of the features of the Unicode Standard are:

Some web authors still haven’t understood the power of Unicode, so let me stress the point: Any web page written in HTML has full access to the entire set of Unicode characters. This does not depend on the character encoding, often referred to as character set used by the authoring software and the operating system. There is absolutly no excuse for web pages that show incorrect characters and claim this is due to technical reasons. Old Persian sign Auramazdaa (U+103C8) While it is true that most commonly used character encodings (e. g., Latin-1) are limited to a tiny subset of the full Unicode range, the document can always access missing characters via numerical character references. For example, if you want to impress your readers with the Old Persian logograph for Ahura Mazda, 𐏈, you just have to insert the magical sequence &#x103C8;; the result should look similar to the graphic on the right margin. This will work whatever software and server configuration you use, provided the visitor has a suitable font installed and the browser can find it.

To learn more about representation of characters, you might want to read some tutorial, e. g., the excellent Character Set Issues page by the late A. J. Flavell (still available via archive.org).

The Spice Pages use UTF-8 transport encoding to reduce file sizes. The encoding is declared in the http header and also specified inside the files via the <META> tag to avoid problems with locally saved copies. Formerly I followed the Conservative recommendation and coded non-ASCII characters by mnemonic or numerical HTML character references, but I found that even the most archaic browsers (except Dillo) and also search engines handle UTF-8 multi-byte sequences reasonably well; so I come to think that this recommendation is now outdated.

Fonts

To render characters on your screen, your browsing software obviously needs access to appropriate fonts (the web page cannot contain the fonts). David McCreedy’s Unicode Font Gallery is a good starting point to search for fonts missing on your computer. Yet even if you have fonts installed, you cannot be sure that complex scripts are rendered correctly. Some scripts, particularly Indic scripts, are typeset using elaborate rules involving glyph reordering, handling of diacritics and formation of complex conjuncts. While recent versions of Microsoft Windows and Mac OSX perform very well in this respect, users of other operating systems might have to install special libraries and may need enhanced (CTL-enabled) builds of their browsers. To verify your system’s CTL capabilities, you can check out the Transcriptions of Unicode page.

I consider it a bad idea to prescribe fixed fonts by CSS; different rendering devices and reading habits legitimately lead to a variety of diffefrent preferences of the side of the readers. Thus, the Spice Pages honour the browser’s font preferences, responsibility for which lies with the reader, not the page author (there are exceptions to this where font declarations become necessary to circumvent browser inabilities, mainly for Internet Explorer).

After some time of trial and error, I finally concluded that for me broad running fonts whith short serifes give the best reading experience (this is in marked contrast to the common preference for sans serif fonts often vehemently expressed). My Default Font for Latin text is DejaVu Serif which has an extraordinary broad coverage of different characters, and which offers very good support for on-the-fly creation of compound characters using diacritical signs in Latin script (but the more complex Vietnamese vowel characters are missing); it also brings good coverage of other writing systems. Yet for some scripts, other fonts work better for me and my browsing environment, which is Firefox 3 on Linux. The only script I was barely unable to install is Aramaic.

Armenian DejaVu Serif
Bengali Code2000
Chinese DejaVu Serif (offers language-dependent glyphs)
Cuneiform Akkadian
Cyrillic DejaVu Serif
Devanagari DejaVu Serif (no eyelash ra)
Ge‘ez Abyssinica SIL
Georgian DejaVu Serif
Greek DejaVu Serif
Gujarati Samyak (some conjuncts are corrupt)
Gurmukhi Code2000
Hebrew DejaVu Serif
Japanese DejaVu Serif
Kannada Kedage
Khmer Code2000
Korean DejaVu Serif
Linear B Aegean
Malayalam Samyak (no chillu forms in Unicode 4.0)
Oriya Samyak (many conjuncts are missing)
Sichuan Yi SIL Yi
Sinhala DejaVu Serif
Tamil Samyak
Telugu Pothana2000
Thaana ???
Thai DejaVu Serif
Tibetan Jomolhari

Some remarks on the way how Firefox choses fonts for different scripts are in order here. Unfortunately, Firefox determines the font for each character based on the document language, which in some cases leads to an almost comical dysfunctionality. Romanized Hindi, Russian or Korean will be typeset in the same font used for Devanagari, Cyrillic or Hangul, respectively, which will often be different from the default Latin font; as a consequence, the page may look like a patchwork of different fonts. This is unesthetic but not really harmful.

Yet things become worse if, for example, Dogri text is to be written. Dogri uses Devanagari alphabet, but this language is not known to Firefox as belonging to the Devanagari group. Thus, the font selection mechanism resorts to a kind of global default font used for all unknown languages. If that default fonts happen to be the same as the one scheduled for Devanagari, this will give the right result; otherwise, Dogri will be laid out in a different (and largely unpredictable) font which look funny enough if another Devanagari-based language like Hindi appears on the page. In the worst (and not unlikely) case, Firefox will stumble over a font that contains Devanagari characters but lacks the metric information for building the conjunct characters necessary in Devanagari typesetting. Then, the result will be illegible.

Moreover, some scripts (like Thaana, Cuneifom, Sichuan Yi) cannot be configured at all to point to a specific font by the font selection dialogue. In that case, you can only hope that the first font containing suitable glyphs Firefox encounters will have working kerning and ligature information, otherwise you have hardly any chance (except explicit CSS declarations) of seeing the text typeset correctly. Debugging is difficult because Firefox does not tell you which fonts it actually uses for a given portion of text. You might end up with a working font without knowing its name, and the next font installation may then change the picture to an non-working font (and still no clue).

The worst problem arises if a language is written in more than one script – for example Kashmiri (Devanagari and Arabic) or Konkani (Kannada, Devanagari and Latin). Font selection becomes a plain nightmare then, because no method (except throwing classes into the markup and writing some CSS around these) can bind texts in such a language to the preferred fonts for the respective writing systems.

So in the end, Firefox work painlessly only if you can use one and the same font for all writing systems, which is of course a quite unlikely option (I wonder whether one could paste together such a font from fragments of various fonts, for example according to the table given above).

Cascading Style Sheets

Valid CSS! This site uses CSS level 1 and 2 to achieve a complex layout with position-fixed navigation tools. Despite being finalized in 1998, the CSS level 2 is not supported by the most used web browser, Microsoft Internet Explorer 6. For the poor users of this highly outdated and incapable software, numerous fallback strategies have been implemented to simulate CSS 2 functionality.

CSS 2 offers sophisticated selection operators, new box attributes and pseudoclasses. While the selection operators allow typographical improvements and occasional eye candies whose omission is not crucial, the new box attributes are absolutely essential for the layout of the page. The new box position attribute fixed allows to keep navigational aids at a fixed place on the viewport without the disadvantages of frames that I had used before. These techniques were first demonstrated in 2000 by Stephanos Piperoglou in his excellent HTML with Style tutorial; since then, I was enchanted by the subtleties of the M.O.R.O.N.S. protocol and the world of transfirbulated web pages, but it took more than half a decade before I was able to implement the entire stuff.

The pseudoclass :hover is used for the dropdown menu in the navigational panel on the right hand side. This menu is purely CSS-driven and does not use any scripting language. The method is fully explained on Eric Meyer’s css/edge site (see the Pure CSS Menu Demo for details).

Since Microsoft Internet Explorer up to 6 (dumb as a brickstone) does not support any of these techniques, I was glad to find a piece of dynamic HTML by Arnoud Berendsen, Martin Reurings and Robert Hanson that enables the :hover pseudoclass for that incredibly inable software. Even more tricks are involved in the simulation of position fixed boxes. On MSIE 6, setting overflow-y: hidden on the HTML element does much of the trick, as is makes absolutely positioned boxes behave like fixed boxes (note that this works in standard rendering mode only). The downside of that method is that the scrollbar does no longer belong to the root element (i. e., the viewport) but to the BODY element which implies that it may be rendered outside of the viewport. This is bad enough, but due to a bug in the rendering engine, horizontal scrolling breaks the design completely. Thus, the vertical scrollbar becomes completely inaccessible.

Lower versions of IE do not support the BODY scrollbar trick, because in these earlier versions the viewport is wrongly associated with BODY instead of HTML. This could have been solved by enclosing all page content in an additional DIV and then proceed as in IE6 with BODY instead of HTML and DIV instead of BODY (confused? Welcome to the world of IE-madness!). Yet I will not blow up markup for the sake of a highly outdated browser; instead, an ugly solution employing JavaScript had to be programmed. The script undoes any scrolling by shifting the navigation panels back to their original position after scrolling events. This script solution can also work as a fallback in case something should trigger quirks mode in IE6 (quirks mode in IE7 is desastrous, though).

Already in CSS 1, the background-attachment property (valid for all box elements) could be set to fixed, which allows to combine different background images for different boxes in a seamless way, while retaining full resizeability. Nevertheless, Microsoft Internet Explorer 6 does not support this property value (except for the BODY tag). Since that browser is too stupid for partially transparent PNG images also, I simulate that functionality by halfscreen PNG images. This is far less aesthetic than the full version. Most of the techniques used here are well documented at the css/edge site (see the Complex Spiral Demo).

Image Positioning

Because the layout is flexible and adapts to any viewport size, the placement of plant images becomes somehow complicated. It would appear a good idea to leave the choice of image placement to the browser completely, but since this requires CSS level 2 simple fallback mechanisms for The Ignorant BrowserTM have become necessary.

The clear property allows images to shift downwards on a page without interrupting the normal flow of text; yet older browsers just support the HTML solution <BR clear=right>. I use the BR tag throughout, but disable it by CSS 2; thus, modern browsers can exploit the flexibility of CSS 2 while older ones still see a simple fallback mechanism. In many cases, however, the image placement is explicitly specified in the markup.

Moreover, I use CSS 2 selectors to decide between vertical and horizontal arrangement of images based on their appearance in the source. There is no fallback for this functionality (except blowing up the markup), so older browsers will sometimes choose to render images below each other when side-to-side placement would be more efficient. Sometimes, large gaps in the text will result from this mischoice.

In any case image, image placing via CSS cannot take in to account the viewport size or the script size, which limits the potential for optimization. Large window size and/or small text size may result in large gaps in the text caused by images occupying the right margin, while users with small window size will often have to deal with horizontal scroll bars or text being vertically interrupted by images. There is no obvious solution (dynamic HTML might work, but would become rather hairy).

JavaScript

Thanks to the power of CSS, there was very little need for JavaScript. I mainly use JavaScript to rewrite some CSS rules depending on browser peculiarities (e.g, the idiotic confusion of height and min-height found in You-Know-Which-Browser). As noted above, JavaScripts are also used to keep the navigation panels fixed on the viewport for Microsoft Internet Explorer Version 5 and 4. Turning off JavaScript on these browsers makes these elements scroll with the main text box, although some care is taken to give still somewhat reasonable layout.

There is an important exception, though: JavaScript is sorely needed for document-internal anchors. Note that the horizontal navigation panel covers the top line of the main box. When you move to some document-internal anchor, the browser scrolls such that the anchor text appears in the top line of the corresponding box (or viewport). At this position, however, the anchor text would not be visible due to the horizontal panel. This applies both to document-internal navigation and to external links pointing to a named anchor somewhere in the document.

To correct this, I originally used JavaScript event handlers and delayed execution for an additional downscroll of the main box. I have recently learned about a better method of achieving this goal, but this is in my case difficult to implement without JavaScript, and browser support is poor, anyway; see below for this.

The necessary amount of downscroll is identical to the height of the top navigation panel and is read from the DOM structure; if you happen to use a browser whose DOM is not covered by my code, there will still be sensible defaults. Because timing is important within event handlers, some browsers require delayed execution of the windows.scrollBy() method (old Konqueror, Safari), while in particular the Gecko browsers (Firefox, Mozilla, Galeon, Epiphany) and Opera allow instantaneous repositioning.

If JavaScript is disabled, document-internal navigation would break. To prevent this, I completely change the layout of the page and move the horizontal navigation panel to the bottom of the viewport. I think this looks significantly worse, but only in this configuration document-internal navigation will work independent of scripting. There are still some minor faults with Microsoft Internet Explorer because of (I think) erroneous handling of absolutely positioned boxes.

It should be possible to solve that problem without JavaScript. One possible solution is to have the main text area in a separate sized box that does not flow within the BODY; this, however, involves a couple of problem which I have no idea how to solve (initial focus, scrolling via keyboard, dynamical resizing).

A promising alternative is to equip anchors with an additional padding, which should degrade gracefully without JavaScript, making the two separate layouts obsolescent; a Q&D hack based on this method is currently used for Opera and Internet Explorer to give a smoother repositioning. Yet, to use this method throughout turnes to be quite impossible: First, the height of the navigation box is not predefined, which poses a couple of challenges; second, heavy markup changes would be needed (all anchors must be empty!); third, the method apparently does not work at all in Konqueror, fails subtly in IE7 and less subtly in IE6 (as expected, I have to add). Currently, I have no time for developing involved solutions for these problems.

This is how it should work: You cannot expand the padding in a block element, because then it eats space from the canvas; also the padding of inline elements is not safe to fiddle with, because, though it does not get laid out, it is still there and may overlay other elements and prevent mouse events reaching them. But you can set the padding of an empty inline element to any value without disturbing the document, for example in a construction like <H1><A name="ankername"></A>Section Title</H1> you may safely set the padding of the A element to 100px, possibly by some CSS2 like A[name] {padding-top:100px}. If you now go to that anchor, the text Section Title will appear 100px down of the upper viewport edge. That’s fine, and exactly what I want.

Yet in reality, this does not work well. First, all anchor elements on my page are non-empty (difficult to change), second the CSS2 won’t work with Internet Explorer (so it needs a class, phuu), third a fixed value like 100px won’t do as the height of the top navigation box is variable (so needs JavaScript, anyway), fourth IE6 ignores padding in empty elements (at least, saves me point two) and fifth, Konqueror ignores all padding when it comes to anchor positioning (what about Acid2?). There is also a subtle timing problem when external links with fragment identifier are concerned: The height of the top navigation box is known only when all the page has been rendered.

However, there is one thing one can really do (if JavaScript is available): The padding of a non-empty anchor element can be inflated to the height of the top box, the url positioned to that anchor, and then the padding be zeroed again. This looks much better then first positioning to the anchor and then scrolling up one top box height. And it works – well, whenever it works. Never with Konqueror (as mentioned above), and Internet Explorer before version 8 barfs if the anchor target is within an table. Also, Webkit browsers will ignore this whole repositioning procedure if the target anchor the one currently in location.href.hash. So currently I check the anchors more or less heuristically, and use that method if I expect no problems, but use window.scrollBy otherwise.

Dynamic HTML

Dynamic HTML (DHTML) refers to various techniques to manipulate the Document Tree by a script language, typically JavaScript (or a derivative). DHTML allows to change the content or visual appearance of a page without reloading it.

For Microsoft Internet Explorer, JavaScript DHTML is employed to simulate some CSS 2 functionality, namely the :hover pseudoclass. If JavaScript is disabled, the menu in the right navigation box is severely crippled.

There several experimental and fully optional features that require DHTML:

  1. Some of the native script indices have been equipped with an array of checkboxes which allow the user to show only particular languages. This does not work with ancient Internet Explorer and Opera prior to version 9.01 (and even then only if the browser identifies itself as Opera). The checkboxes should be visible only for supported browsers. There is a bug in Gecko 1.8 that will make the layout collapse (in the Chinese Index only) after several changes have been made. Reload helps, or better switch to Gecko 1.9 where the bug has been fixed.
  2. Also, the large alphabetical index has been extended with a powerful language selection tool. Since this slows down some browsers, it is off by default. To get a resonable rendering speed, a couple of non-obvious tricks has been used (amazingly, Opera and Gecko, usually rather fast browsers, showed extremely poor performance with straight-forward coding, resulting in waiting times of several minutes). Currently, I have tried find a compromise between quick rendering and excessive file size. A glance at the source may surprise you!
  3. The sometimes longish list of foreign names at the head of each spice article is by default reduced to the most important languages and can be displayed in full length by clicking a link. I hope that this will help visitors navigate, as most will skip over the table anyway. Visitors without JavaScript (and those using Opera prior to 9.01, which doesn’t like my script) will see the full list without any possibility to shorten it.
  4. If a spice article is reached from a foreign language index, then spice names in the language(s) corresponding to the clicked name will be promoted to important and are shown even in the default view.
  5. JavaScript is also used to display the search term in the search box on the search result page.
    A short and frustrated remark about the first two items. The task of modifying a CSS rule by a script should be simple. The first part is to retrieve the CSS rule object, which isn’t complicated: The n-th rule in the m-th sheet is called document.styleSheets[m].cssRules[n], but Internet Explorer insists on the deviating name document.styleSheets[m].rules[n].

    In my application, I want to enable or disable a table row using the display property. To switch between the two states, there are four syntax alternatives, of which IE6 and IE7 understand only one (but a different one). To enable the display, one must write

    1. document.styleSheets[m].rules[n].style.cssText="display:inline" for IE6 and IE8
    2. document.styleSheets[m].rules[n].style["display"]="inline" for IE7 and IE8
    3. document.styleSheets[m].cssRules[n].style.display="table-row" for Real Browsers
    4. document.styleSheets[m].cssRules[n].style.setProperty("display","table-row",null) for Real Browsers
    Internet Explorer 8 will also work with the third syntax if the incorrect Microsoft-only name rules is used; in contrast, Opera und Konqueror will also understand the first two, if the property is correctly named cssRules; Gecko, yet, works only with the final two. Internet Explorer up to version 7 accepts only display:inline, although CSS2 defines a separate table-row value for table rows; using the correct display:table-row will results in a JavaScript error, yet IE8 will accept that. Now the good news: Disabling a table row still requires all four alternatives, but the style attribute display:none works for all browsers. Wow.

Note that DHTML creates effects that are usually not adressable by an URL. However, if you wish to link to my site and want the initial display different from the default, there is an additional interface via url parameters available. Please follow the instructions in the Link section, and keep in mind that these extended links may open rather slowly on some browsers.

Alternative Style Sheets

HTML includes a mechanism which allows the user to select between several page styles provides by the page author. Since JavaScript is required for the style change anyway, the menu item Display on the navigation panel is visible only for JavaScript-enabled browsers. Enabling and disabling such alternate style sheets is fairly straightforward (though the syntax varies with the browser, as usual), but the complicated issue is to make the change stick to subsequent pages. The standard solution involves cookies, but I prefer a cookie-free method that just relies on DHTML.

The DHTML solution involves a script that tags all outgoing links with a parameter that tells the onLoad handler in the target document to switch to the alternate style. Therefore, different page styles become linkable (which is not true for the cookie based method). On the down side, the DHTML becomes very slow on large pages, especially if these contain large numbers of links (which can hardly be avoided for an index, unfortunately). A probably more serious disadvantage is that the DHTML mechanisms interacts badly with the Back button of the browser. Also, some browsers have problems changing the style of one and the same page repeatedly (can you guess what some browsers may mean here?).

The alternate style sheets themselves are simple, because they have no more to do that to disable or change parts of the default style. In the Flow style, there is no obvious choice for the initial height of the navigation panel; I try to adjust it to the viewport height, and fall back to a fixed estimate for browsers that won’t tell me the right number. On window resize, the navigation panel should adjust to the new height automatically.

JavaScript support disabled?

This site works better with JavaScript enabled!

Whenever JavaScript is disabled, a small box appears to remind people that the page works better with scripting turned on. With Internet Explorer 6, this box unfortunately stays fixed on the viewport and does not scroll away; this is a unintended side-effect of the way how the position-fixed layout is achieved (absolutely positioned boxes behave like fixed boxes). Clicking that box leads you to this text.

Browser List and Bugs

The webpage was tested with a variety of browsers available in 2005: Konqueror (3.3, 3.3.2, 3.5), Mozilla Firefox (2.0 and later) and other Gecko browsers (Seamonkey, Epiphany, Galeon), Opera (since version 8.51), Safari (regular tests since version 4.0, as it runs on Linux using wine) and its cousin Google Chrome. Due to careful hand-optimization, full and equivalent functionality is provided for all of these.

The case is significantly different for the various versions of Internet Explorer up to including 6.0. Since these are not so much real browsers than rather a heap of half-implemented und buggy features, web designers are generally faced with one of three options: Either, stick to the basics (compromizing design, accessibility and/or ease of maintanance). Or break the standards (punishing those browsers who do it right). Or implementing every feature multiply, for each IE version separately (making development complicated, error-prone and bloated). A nice summary of IE madness is No, Internet Explorer did not handle it properly by Mark Wilton-Jones on howtocreate.co.uk.

After an incredible lot of programming, this page now works almost right with the most common IE version, 6.0. Yet there are some limitations for the older versions: Versions 5 and 5.5 work acceptably, although they depend on JavaScript, and the display may be quite rugged; the layout is rather broken in version 4, but most of the functionality is still there. Very old browsers like Microsoft Internet Explorer 3, Netscape Navigator 4.x and some minority browsers with no CSS support give very poor rendering and broken functionality, although I implemented a minimum fallback mechanism. Internet Explorer for Mac was not tested.

A key factor for the successful implementation was the possibility to install several versions of Microsoft Internet Explorer in parallel. This allowed to study the bugs and bizarrenesses of each single version (3.0, 4.0, 5.0, 5.5, 6.0) and develop effective CSS rules to counteract. Thus, I make use of conditional comments, i. e., valid HTML comments that may get uncommented (i.e., executed) by MSIE only, depending on the version number. The HTML contained in these comments is, thus, invisible to every browser except the selected IE version. The syntax goes like <!--[if IE version]> This is IE version<![endif]-->, where version stands for the version number (usually 5, 5.0, 5.5000, 6 or 7). Comparison operators (lt, lte, gt, gte) are also possible. Tis type of conditional comment is called downlevel-hidden, because in Microsoft’s newspeak downlevel means anything that obeyes the standard.

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 also offers the complementary downlevel-revealed conditional comments which are, however, not valid and should not be used (though they don’t tell that on their web site). HTML enclosed in such a comment will be visible to a selected version of IE and all non-IE-browsers. A clean way of achieving the same results using the valid downlevel-hidden conditional comments is shown in the right hand side table (click to see the source). Using, e. g., the syntax <!--[if !IE version]> <!--> This is not IE version <!--><![endif]--> one gets a perfectly valid downlevel-revealed conditional comment whose content is visible for every browser except the selected version of IE. This works because brain-dead Internet Explorer interprets the > in the red sequences as end-of-comment markers, in blatant violation of the specification. If you see the word brain-dead in the previous sentence, then your browser shows this very bug.

Using the conditional comments is, in my opinion, much superior to the various CSS Hacks that rely on CSS parsing bugs; after the release of IE7, such techniques are likely to result in a renewed nightmare.

Since I develop the pages on a Linux system, it comes handy that IE can be installed using WINE. A collection of almost-ready binaries for IE5, IE5.5 and IE6 can be found of the IEs 4 Linux site (eats up 329 M on your hard disk); there is also an experimental IE7 port. This allows for some debugging without having to switch to another OS. However, this is limited; the true IE layout engines are used, but the font management and the actual screen drawing are still performed by the X Windows system. This means that fonts specific for MS Windows cannot be accessed, and CTL (a strong point of the Windows Operating System) is not available. Note that some consider it illegal to install this software if you have no MS Windows license.

With their new Internet Explorer 7 (tested since public beta 2), Microsoft really surprised me in a positive way. IE7 is far from perfect, but supports all those CSS2 elements which are essential for the layout of my site; selectors based on attribute values still don’t work, but this does not hamper my site critically. Thus, IE7 ends the surrogate madness which I had to introduce to support the earlier versions. There is still some work to do, but currently, IE7 should give largely the same rendering as any other modern browser. My unofficial standalone installation of IE7 shows a couple of minor bugs (and some deliberate compatibility bugs) which either result in harmless cosmetic issues, or could be solved easily by some additional CSS rules. Only JavaScript poses unresolved major problems, but I hope these are now fixed.

When Microsoft announced their upcoming IE8 will be Acid2-compliant, I was quite hopeful; yet after a painful suggestion about immortalizing obsolete rendering engines and requesting legacy bugs in the http header, and after two desastrous β versions (of Dillo functionality), my optimism had cooled down below absolute zero. Nevertheless, the first Release Candidate is really up to the promise and was able to run the Spice Page code without any modifications; even after very close inspection, only a handful of browser-specific declarations were needed, at about the level of other Real Browsers. It really seems Microsoft has produced a working, modern browser at last.

Browser Blackbook

This section ontains not only browser bugs, but also those disadvantages that are inherent to the chosen design and which I was unable to solve.

General appearance
  • Background images and style/script declarations are pretty large. Currently, CSS2-compatible browsers will be fed 59 kbytes of background images, while users of Internet Explorer up to version 6 will have to load only 23 kbytes because the browser cannot show the intended background effects anyway. Styles and scripts weight an additional 150 kbytes, plus a few more for the varions versions of Internet Explorer. For comparison: Background plus organisational overhead due to frames in the old version accounted for 24 kbytes, plus an additional http request for each click while surfing my site. The average size of a spice article is 36 kbytes of text plus 157 kbytes of inlined images. The longest single document is the alphabetic indec, with close to one megabyte (everything included).
  • Support for printing works imperfectly.
  • Gecko, WebKit and Opera already contain some support for the (maybe) upcoming Cascading Style Sheets level 3 standard, which is selectively turned on using JavaScript. While you cannot much blame MSIE and Konqueror for not implementing an unfinished standard, some small eye candies are not available for users of these browsers: Translucent highlighting (Gecko, Opera, WebKit), multicolums and rounded corners (Gecko, WebKit).
  • The buttons linking to validation results use alpha transparency; consequently, they are misrendered in Internet Explorer up to version 6.0. I use JavaScript to replace them by non-transparent versions that integrate less nicely.
  • Unexpected minor layout flaws in some versions of MSIE. I’ve lost overview on the many different and contradicting style sheets that are necessary to treat any individual bug in these browsers. IE8 behaves much more sane since RC1.
  • Konqueror 3.3 shows a number of flaws in rendering: The search field does not scroll correctly, and loading a new document erases the window contents until the page is rerendered. Repositioning to a named anchor will often miss its target by a few lines. Version 3.3.2 works somehow better albeit not perfect. Version 3.5 is fine, although I find it painfully slow, and the search field still gives special effects on scrolling.
  • Arora (and some older versions of other browsers) have the habit of blanking the canvas while a new document is loaded and parsed, meaning that the display flickers whenever you open a new page. This looks quite stupid (especially, since the postion-fixed elements reappear at the same position later), but as the author, I cannot fix that.
  • Mouseover highlight effects may not work well on the search result page (all browsers).
  • The page displays slowly on older computers because of the complex CSS declarations.
  • Gecko browsers up to version 1.8 generate a spurious blank area below right floating elements if these are followed by list items. The reduction of line width according to the space used up by the float is applied to the entire LI block, while the correct behaviour would be to shorten each line within that block separately till the lower edge of the float is reached. This bug is around in Bugzilla since 2002 and apparently is a deliberate choice by the developers. The proprietary style rule LI {-moz-float-edge: content-box} restores standard-compliant rendering, at the cost of fouling up all lists close to left floating material (which, fortunately, does not occur on my site). See also this full demostration of the problem. I add the mozilla-specific style rule via JavaScript to keep the stylesheet valid. You can see the (mis)behaviour in the borage article (clearly, to see the wrong rendering, you will have to switch off JavaScript). The error has been fixed in Gecko 1.9.
  • Konqueror suffers from the same disease, yet has no cure.
  • As a typographic nicety, I prefer to use a thin space between number and units, as in 8 cm as opposed to 8 cm. Opera can’t really handle this and will replace it by a normal-width blank character, which is of course acceptable. Internet Explorer up to version 7, however, uses a super-wide blank which completely spoils the intended effect.
  • Safari and other WebKit-based browsers have a surprising bug: Whenever you change the content of a style sheet via JavaScript, background images disappear. Unfortunately, this is the mechanism which I use to select languages in the multilingual indices, so the layout falls back to background colours instead of background images. After a long time, I realized that this is in fact a DOM bug related to the handling of alternate stylefiles.
  • Konqueror has two probably related problems with the spice name list on top of every spice article. The first is that it messes the table up if (a) the last language in the table is a multiline entry and (b) some lines of that multiline entry are to be supressed. This happens quite often with Vietnamese, which tends to be at the end of the table and where the default view for spices important in Vietnamese cuisine should show only the native, heavily accented writing and not the ASCII-only surrogate. Since it is hard to find out whether an entry is the last in the table, I resort to show Vietnamese surrogate writings in all cases for that browser. It’s not surprising than WebKit shows the same misbehaviour, but IE8 also does. Exactly. Hmmm.
  • Chrome is crazy: Starting with version 5, it does not allow to access the content of an external style file. Rather, it claims that the corresponding cssRules object is zero-sized. What’s up?
  • There is a similar yet subtly different problem: Konqueror misrenders the right table border if the following conditions are met: (a) The default view contains entries that span three or more lines (as happens with vocalized Arabic and Hiragana/Katakana transcribed Kanji in Japanese), and (b) the user clicks Show all languages. Note that in the default view, the middle lines should be suppressed if the language is shown at all. Yet, for Konqueror I have to show those lines in order to keep the table layout clean. This works well in WebKit and also in IE8.
  • All WebKit browsers (e. g., Safari, but not Konqueror) have a curious problem: Positioning to an intenal anchor does not work twice in a row. This has something to do with a couple of nasty tricks I use to have the target anchor visually positiones not at the upper window edge, but at the lower edge of the top navigation box. The bug can be circumvented by resorting to the window.scroll() method. This will but will work correctly, but gives a nasty flicker (Try clicking twice on any links in the top box and you will see).
  • Sinc MSE6 does not know about the <LABEL> tag, users have to hit the checkbox exactly in the various language selection panels. OnClick handlers could help, but frankly I don’t bother.
  • Arora, a leightweight WebKit-based cross-platform browser, uses a rather old WebKit version even in the most recent version 0.4. Support for transparency is severely broken: All elements with an opacity property are invisible, even with opacity:1! Even more modern browsers like Safari or Camino may have slight problems with transparency, which is then selectively turned off by JavaScript.
    Checkboxes rendered Firefox 3.6.2 / Gecko 1.9
    Rendering of Checkboxes using Firefox 3.6.2 (see Cyrillic index): Left default rendering under Linux, middle under Windows (more exactly, wine) and right Linux with opacity reduced to 50% for inactive boxes.
  • No true bug, but really devoid of brain: All Gecko browsers render checkboxes in forms in almost the same way whether they are disabled or not (in most other browsers, the differences are still too small for my taste; amazingly, Internet Explorer does best in this field). Since CSS does not affect checkboxes, I try to grey out checkboxes by reducing their parent’s opacity.

    I am amazed that this strange behaviour seems restricted to the Linux platform. The screenshots on the right side clearly show the missing contrast between enabled and disabled checkboxes on Linux (left) compared to Windows (center). The right part of the image shows the effect of reduced opacity. In any case, checkboxes in the second row are disabled, while those in the third are enabled yet unchecked.

  • Incredible yet true: The <Q> tag for short inline quotes is part of the HTML standard for more than 10 years, but it was ignored by Mircosoft in all IE versions prior to 8. The advantage of the Q element is that the browser can choose the correct shape of the quotation mark according to document language (Das Motto ist: Zum Teufel mit schlechten Browsern.) and nesting depth; moreover, German dictionaries use a different style of quotes for definition of headwords, e. g., englisch devil Teufel. Browsers without proper CSS2 support (WebKit browsers like Safari and Chrome) should at least draw default quotation marks, but IE up to version 7 does exactly nothing. On that, I just remark This means Bad luck! for IE5–7 users.
  • Those multilingual indices that allow language selection via DHTML fall prey to a Gecko bug: After some changes in the displayed items, Gecko may choose unreasonably small table cell widths, leading to unnecessary line breaks. It helps to select all languages and then reduce to any desired set.
  • The spice overview (and some other places) use a table-based five-column layout, which is reworked into a true CSS3-multicolumn layout with variable number of columns for supporting browsers (Webkit and Gecko, also Opera 11.10 and better). However, implementtions are different and somewhat erratic: Opera is OK, but neither WebKit nor Gecko recognize the break-inside attribute, which gives unlucky breaks within multi-lined spice names. In Gecko, this can be fixed by displaying the spice name as a table-cell, which seems to imply break-inside:avoid.
  • In Konqueror, the <WBR> tag is not stylable, but displays a very surprising (and stupid) behaviour: Any linebreak is allowed after the <WBR>, ignoring the surrounting <NOBR>. It seems the elements was incorrectly implemented as a container, and I shudder at thinking how the DOM may look like.
Line breaking
  • Opera has a small problem with quotation marks: If the quotation (or similar material) is followed by a parenthesis, no line break will occur between closing quotation mark and opening parenthesis. The problem can be solved by adding a zero-width space: Thank you very much (the necessary character gets inserted by a little JavaScript running through the DOM and searching for quotes).
  • Another line break bug in Opera: A break may occur between any element with the property white-space: nowrap, as in this example, and any following text, including comma or other punctuation mark. While it would be possible to move the comma inside the tag content, I feel this is illogical markup, and I don’t want to spoil the source with that; instead, I do it with DHTML. Note that this simplistic solution sometimes gives unwanted font attributes for the punctuation marks. As this sentence demonstrates, the problem can be solved, albeit laboriously, employing DHTML.
  • A third Opera bug relating to line breaks: If the first line of a paragraph must be broken at the first break point within the paragraph, and if there is a float at the right margin, then Opera will forget about the text-indent, meaning that the first line runs into the right floating material by the maximum length of the paragraph indent (complicated? Yes!). Again, DHTML comes to help: The misbehaviour is really bound to text-indent, so anything that gives an identical appearance without being an actual indentation will solve the problem. The rest is left to the reader as a exercise in DHTML, margin-left and :first-letter. I’m happy Opera is so fast, with all the JavaScript running onLoad.
  • I am quite sur­prised that Gecko brow­sers in ver­sions up to 1.8 don’t rec­og­nize hy­phen­ation hints given via soft hy­phens, but rather ignore them. That char­ac­ter marks a pos­si­ble hy­phen­ation point ac­cord­ing the the Uni­code and HTML4 spec­i­fi­ca­tions, but note that ISO-8859 has an in­com­pati­ble def­i­ni­tion. This para­graph has some soft hy­phens scat­tered into it, and thus you should be able to see some hy­phen­ation oc­cur­ring. Arora breaks the line, but does not show a hy­phen.
  • Yet Gecko may fail to use hyphenation inside table cells if the word is longer than the table cell; instead, it overflows the cell width. Depending on your font preferences, you might see that bug in the German article on juniper, where the long word Wacholderbeeren (juniper berries) overflows the table cell and moves the image leftwards, causing some mayhem to text left of it.
  • Konqueror and Webkit fail miserably to break a word at a soft hyphen if the latter is the last character of a #text. This situation is rare in English, but pretty common in German where compounds like basil­leaves would be spelled in one word; yet the said browsers will not break it at the word boundary, despite the explicit soft hyphen. Interestingly, Opera joins the club with version 10 (former versions were free of that problem). Konqueror is particularly perverse as such constructions may lead to the rest of the screen line not rendered. A solution with dynamical HTML is possible, because a zero-width space after the soft hyphen will solve the issue, and then the rose­bushes will be full of flowers again.
  • The proprietary <NOBR> tag was introduced by Netscape (these were the days…), and it is quite popular in suppressing line breaks for a given chunk of text. Semanitically, it is equivalent to white-space:nowrap, which (despite the literal meaning of the words) also prevents breaks as soft hyphens. All browsers know about that tag, despite it’s not part of any HTML standard, yet there are subtle problems with it: Konquerer insists that there should be no blank immediately after the <NOBR>, otherwise Konqueror will overlap the protected text with any floating images; as a solution, the <NOBR> can be shortened by one word and the next blank be moved inside. Then, however, an Opera bug already noted above becomes manifest that it will allow line breaks at the end of the NOBR element, whatever follows; therefore, the browser behaves intuitively only if all <NOBR> tags are followed by breakable characters. It is difficult to reconcile both points (best use &nbsp; instead, or try clever nesting). Webkit also exhbibits clueless behaviour with <NOBR> or white-space:nowrap: If the content of a <DT> is break-protected, it will overlap any right floating material.
  • Netscape introduced a <WBR> tag as a companion to <NOBR>. It allows line breaks, even in otherwise break-protected sections, but does not enforce them. However, quite understandably both <NOBR> and <WBR> never made it to any standard, as they are purely presentational (I have them in my custom DTD, though).

    Only some older versions of Internet Explorer treat <WBR> exactly as I would have it (there is no officially published semantics for that tag, AFAIK). It should be possible to implement it by CSS2, where you can use generated content to insert a breakable space (best use a zero-width space, as this gives minimum likelihood of further complications). A possible definition is WBR:before {content: "\200B"; white-space: normal}, which should make any compliant browser aware of WBR. However, in practise, it is not that easy, and Opera is actually the only browsers that accepts this without further side-effects. The rest needs further support in the form of DOM manipulations by JavaScript, also known as DHTML, as detailled below. This sentence, which can be broken only at the commas, illustrates the success of the long, long effort.

    • Most surprisingly, Internet Explorer (including 7) have best support for <WBR>; the only exception is IE5.0, which ignores it outside of <NOBR> (this isn’t really problematic [even if there were some IE5 still around], because that browser can split hyphen-written compounds without further help).
    • Internet Explorer 8 ignores <WBR> and allows no styling. The tag, however, does get parsed correctly, and ends up in the DOM as a terminal node. There, it can be accessed by scripts, and can even be replaced by something the browser can really work with. A zero-width space (ZWSP) should help, but it does not; instead, it must be followed by a regular space. In short, replace <WBR> by <SPAN style="white-space: normal">ZWSP-SPACE</SPAN> at the DOM level.
    • Safari, Chrome and its relatives support <WBR> automatically, yet the joy is marred by a cosmetic bug: A possible blank following <WBR> persists and does not get removed in case of a line break. Thus, if a line is broken at the <WBR>, the next screen line starts with a bank. This can be fixed in a way similar to IE8, with the addition that after substituting the WBR node, a following #text is stripped of its trailing blanks.
    • Gecko browsers do support <WBR>, but only outside of <NOBR>, which is really difficult to defend. Moreover, it is immune to style sheets, although Gecko in principle has no problems with rules involving phantasy name elements; it appears the the proprietary tag has a special status (or a special bug). This suggests to write the style sheet rule for XBR instead, and to replace every WBR by XBR in the onLoad handler. Amazingly enough, that works — but only for Gecko 1.9. In earlier versions, document.createElement() doesn’t accept arbitrary element names; a more complicated hack as in IE8 would work, but would have no result on the rendering. It appears that in Gecko 1.7 and 1.8, a white-space:normal can never override a parent’s white-space:nowrap.
    • Konqueror is the winner — it wins the price for the most dain-bread implementation of <WBR>. The tag gets parsed as a container and is styled with white-space:normal. As a consequence, it does usually nothing outside of <NOBR>, and inside of the latter, it will enable line breaks at all following whitespaces (or soft hyphens, or whatever). Moreover, Konqueror expects a closing tag; in the regular case it is missing, Konqueror will correct by inserting it appropriately, and generating further WBR elements up to the end of the document, pretty much as if you wrote <I><B></I>. The DOM looks cruel! I was unable to fix it, but as a minimum help I insert a ZWSP at the beginning of the content of the WBR; this apparently makes it work correctly outside of <NOBR>. This is a significant imprevement because of the following bug.
  • Most browsers break lines not only on blanks, but also on word-medial hyphens (in accordance with the Annex #14 of the Unicode standard). Konqueror, however, never breaks on hyphens, and Gecko sometimes refuses, too (I did not see a system when in breaks and when not). The <WBR> tag can help (of course only after the hacks described above), and in principle one could also directly write a zero-width space into the source, but then IE displays a missing glyph box. See here: Plain-hyphen-example, <WBR>-tagged-example, zero-​width-​space-​example.
Characters and Fonts
  • Internet Explorer up to and including version 7 will often fail to retrieve glyphs for characters not present in the standard font; this particularly applies to Old Greek text and some Latin characters with unusual diacritics (see here: Ἐν ἀρχῇ ἦν λόγος). The problem is that IE (all versions) barfs if it encounters a character for which the current font holds no glyph, while all Real Browsers will just scan all installed fonts for the character and if possible will take a glyph from some other font. IE, being lazy and/or stupid, wants me to tell it exactly what font to use, although I, as the author, cannot even know what fonts are available on the visitor’s system (while IE clearly has access to that information). As a workaround, I have scattered extra markup in the source that will force IE to use a font that (by experience) is often preinstalled on Windows Systems, and that (at least in some versions) covers a large part of codespace, like Arial Unicode MS and Microsoft Sans Serif (see here: Ἐν ἀρχῇ ἦν λόγος). Pure guesswork, and quite a lot of extra typing for a bad-looking result, but what else can I do?
  • Rendering of complex scripts is an OS issue and far beyond my control as a web author. Recent versions of Microsoft Windows (with MSIE) and Mac OS (with Safari) perform very well, but unixoid operating systems have generally poor support (Konqueror does quite well under KDE 3.5, and the upcoming Firefox 3 is close to perfect). Gecko browsers before 1.9 usually cannot fully exploit OS support even if it is there.
  • The Romanian special characters ț and ș are poorly supported on many systems. I perform considerable acrobatics (involving sed, CSS and JavaScript) to switch the font (ț,ș) for MSIE and Safari under Windows NT/XP, and to serve surrogates ţ and ş to even less capable systems (Konqueror, MSIE on Windows before NT) and to search engines.
  • The page header lines in the Hebrew and Arabic Index use nested bi-directional override to imbed English text into right-to-left running lines. BIDI Support is incomplete or buggy in Konqueror and also IE5/IE7, while both IE6 and IE8 do it well (the magic of odd and even numbers?). The following example demonstates the effect; I have substituted the no-break space by an underline for better visibility, as the two have identical directionality properties.
    1. <BDO dir=rtl> <BDO dir=ltr><SPAN>Begin</SPAN></BDO>__
      &alef;__ &bet;__ &gimel;__ <BDO dir=ltr>End</BDO> </BDO>
    2. Begin__ א__ ב__ ג__ End
    3. Begin__ א__ ב__ ג__ End
    The first line shows correct code, which is incorrectly rendered by Konqueror 3.5 and IE5/IE7: Instead of beginning the line with the word Begin on the right side, the word is moved to the left end, while its associated spaces, shown in dark blue, surprisingly turn up on the right side (line 2). As shown in the third line, a single left-to-right mark inserted after the green BDO solves the problem.
  • Konqueror struggles even more with nested bi-directional override, if property inheritage to deeper elements comes into the play. The code example again used underscores instead of no-break spaces, and the fix for the previous bug is quietly applied.
    1. <BDO dir=rtl> <SPAN><BDO dir=ltr><SPAN>Begin</SPAN></BDO>__</SPAN>
      &alef;__ &bet;__ &gimel;__ <BDO dir=ltr>End</BDO> </BDO>
    2. Begin__ א__ ב__ ג__ End
    3. Begin__ א__ ב__ ג__ End
    4. __Begin א__ ב__ ג__ End
    The first line shows the code as per specification; yet the result in the second line is wrong for Konqueror: The word Begin should appear on the beginning of the line, meaning right, and correspondingly End should go left. Konqueror messes this up completely, but only if both the light blue and the dark blue elements are present. The fix starts with the observation that a dir=ltr applied to the light blue SPAN saves the rendering order (line 3), but then of course the associated spaces appear on the wrong side of Begin; this can be cured by moving them, in the source, in front of he dark blue SPAN. Phuu!
  • Konqueror (version 3.5) always died when trying to display the Tibetan Index, going into CPU-burning mode forever. It turned out that each of the Three Jewels, in that case the Tibetan letters for vocalic RR, L and LL, immediately releases the browser from the Cycles of Loading and Unloading, and sends it to Nirvana instead. Meditating on that matter, I was tempted to ignore the issue gravely (thus annoying the one Konquerer user per decade hitting that index), or to react boldly by removing the three almost-never-used characters from the table (thus annoying the three Wise per decade who would note the omission), but I in the end I chose the Middle Path, disabling the display of the three table lines for Konqueror users only. If there had been a Bodhi tree nearby, I might have found a better solution; yet, in the meantime, the Lord who Looks Down to the World has fixed the problem in version 4. ཨོཾ་མཎི་པདྨེ་ཧཱུ་
  • A BiDi bug in Webkit: Vocalized Hebrew or Arabic will, under some circumstances, mess up opening and closing parentheses. Writing the word gad in parentheses with vowel points will fail if the markup declares the directionality with dir=rtl explicitly; in my mind, however, this is exactly what the dir attribute is for. Example: <SPAN dir=rtl lang="he">(גַד)</SPAN> yields (גַד). This can be fixed by moving the parentheses out of the <SPAN> (גַד), by omitting the dir=rtl (גַד), by nesting another <SPAN> inside (גַד) or by removing the patah vowel sign (גד). Note that these alternatives will show different behaviour when you try to select them by mouse cursor. The bug was fixed in Webkit 534, so that Chrome 6 is no longer affected.
  • A pretty funny bug: MSIE/XP does not distinguish between kaf ك and keheh ک in anchor names (and who knows in which other places as well). As far as I can tell, these two letters cannot be considered equivalent in any Unicode-conforming sense. Since I changed the anchor names to ASCII-only, this is of no importance.
  • Even more bizarre: In the Arabic Index, the links leading to the letter alef cannot be clicked in Opera 9 (still worked in version 8). You should see three hyperlinks here: أ أ أ (move the mouse to see whether they are functional).
  • Probably unrelated: Opera doesn’t connect Arabic letters to a tatweel character. For example, here ـبـ the character beh ب is rendered in its isolated form, although it should be in its middle form ـﺒـ as shown here. This appears to be a Linux-only problem. This bug almost completely invalidates the table of Arabic character in the Arabic Index.
  • Another Opera bug relating to Unicode: External links referring to anchors whose anchor name contains non-Ascii characters will not work if URL parameters are present. Yet, I am not altogether sure whether such anchors are valid in the first place. While the DTD declares the name attribut as CDATA, the W3C gives contradictory or at least not very clear advice: The value of the name attribute may contain entities entities, but non-ASCII characters must be escaped in UTF-8 style because such are not allowed in URIs. This appears to indicate that entities are allowed but coded characters are not and sounds rather weird. I have decided that this is too complex for me, and thus I renamed all my anchors (sorry for external links). Since I did this, Opera has no further problems.
  • At last, a specific Gecko problem haunting all versions: The rendering engine uses HTML language markup for determining the font. This is often counter-productive, as, e. g., transliterated Russian is shown in the same font as Cyrillic Russian, and probably different from other Latin-script text. Latin characters in Chinese fonts have often large width unsuitable for Latin typography. This bug would be easily solved if Gecko used script and not language information for its font choice, but this simply does not happen.
  • The problem becomes more serious with complex scripts: The word 'manipuri' in Bengali script Languages unknown to Gecko are rendered in the default font, even if that font offers poor CTL. As a demonstration, have a look at the name of the language Manipuri written in its native Bengali script. It might be rendered wrong if markupped as Manipuri language (মণিপুরি) yet it is probably right if the browser is told that it is in Bengali language (মণিপুরি); see the reference rendering right. Most Indian languages unknown to Gecko have no appearance on my site, but currently, Konkani, Dogri, Bihari (Maithili) and Newari (Nepalbhasa) suffer from that problem (all are written in Devanagari), and the transliterations from native Indic alphabets to Devanagari are also affected (these appear only in the Indic index). Quite surprisingly, one can add a Script Subtag that, depending on selected default fonts, may save the rendering (e. g., lang="bn-Deva" for Bengali language in Devanagari script) at the cost of slightly longer file sizes. But this does not work always, and never with Bengali script, at least on my machine মণিপুরি is still wrong with Firefox 3; I fear that the behaviour depends on some font parameters that I don’t understand. Thus I use the brutal method and, by JavaScript, change the lang attribute to Hindi (Nepalbhasa) or Bengali (Manipuri), which keeps the source clean and gives fine rendering, but it was cumbersome to implement, slows down the first rendering, and increases file sizes. Sigh.

    The problem seems to be mitigated in Gecko version 1.9.1 (used in Firefox 3.5). Characters may still come from various fonts, but the rendering is correct. I don’t really understand why, but I am happy with it.

Position-fixed navigation panels
  • Without JavaScript, the horizontal navigation panel has to go to the bottom of the page instead of the top. I consider this unfortunate, but otherwise document-internal navigation won’t work properly.
  • Microsoft Internet Explorer up to version 5.5 need JavaScript for this effect. Display will be rugged unless your machine is very fast.
  • Microsoft Internet Explorer 6 works almost well. There is a problem with scrolling if the page contains images wider than the window size (likely to happen, e. g., on the basil page): The vertical scrollbar moves outside the viewport, as it is attached to the main box, not the viewport. Horizontal scrolling clears the contents of the navigation panels. This is a significant demerit, but I am unable to fix it. Scrolling via mouse wheel or cursor keys is not affected and works normally. Also, the reminder to switch on JavaScript does not scroll away, which is obnoxious.
  • Internet Explorer 7 should give full functionality. My version (beta 2 in a standalone installation) shows some irregularities concerning the onLoad event handler which I was able to fix only partially. One problem is that the onLoad event starts before the rendering is complete, which makes vertical scrolling unavailable within the event handler. As a workaround, I had to introduce a time delay based on the size of the current document. This is improbable to work reliably across machines with different processor speeds.
  • A related IE7 problem, shared also by IE8: Going back in the history triggers onLoad events. In that situation, however, the usual onLoad-scrolling correction is not wanted. I was not able to find out whether a onLoad event resulted from loading a new document or from using the browsers Back and Forward buttons. The problem can be demonstrated in the following way: Activate JavaScript and try this link. As a result, the word Etymology should appear visible on the upper edge of the main box. Follow any link on the page and press the Back button. The original view should be restored. On my system, only the first requirement is met.
  • The spurious onLoad events have particularly unpleasant consequences in the larger index files. These documents register onClick handler for every outgoing link – the Alphabetic Index has 10000 of them. This is all the more painful since IE (all versions) runs quite slow.
  • The horizontal navigation bar in bottom position does not grow to full viewport width in MSIE 6.
  • The search result page layout is broken with MSIE prior to 7 if JavaScript is disabled.
  • Only in IE8 RC2: Scrolling down the Alphabetic Index, one reaches a point (in my test, around the letter R) where the position-fixed elements gradually vanish, leaving empty space behind. Named anchors beyond that point are not referable by fragment identifiers, and links behave strangely. To my astonishment, I could not confirm the bug in the final version. Have they, mirabile dictu, actually fixed it?
  • Early α-Versions of various Mozilla browsers (e. g., Mozilla Seamonkey 1.5α) do not keep position-fixed elements fixed during a scroll operation, but move them to their old position after the scroll is finished. This looks pretty bad, almost as bad as my JavaScript hack for Internet Explorer 5.x. This was a temporary deficiency related to the upgrading of the Gecko engine (Bugzilla); if you have this problem, please upgrade, as the current versions of Gecko run extraordinarily beautiful.
  • The document-internal navigation (via named anchors) is still somewhat a game of dice. While all mainstream browser currently appear to behave correctly, there might still be problems with unusual browsers/versions/settings. Anyway, there should be enough fallback mechanisms to keep everything away from disaster. Things are particularly error-prone in links employing fragment identifiers.
CSS Menus
  • This needs Active Scripting enabled in all versions of Microsoft Internet Explorer prior to 7.0. Otherwise, there are no menus, and you will have to go through a sequence of HTML files for navigation.
  • As a consequence, the menus cannot work on the search result page for said browsers. The reason is that the Dynamic HTML/JavaScript gets blocked because the script and the HTML come from different servers. This is not a bug but an important security feature to prevent cross-site scripting attacks.
  • Microsoft Internet Explorer only: Some inconsistencies in the the visual appearance of the menue. Opening a submenue in MSIE6 will clear the highlight of the parent element unless this parent element is on level one (this is, part of the navigation panel). I’m not sure whether that can be fixed, but it’s a mess. Things are better in IE7 since the visual focus is removed consistently when a submenu pops up.
  • Some of the menue items resize whenever the mouse cursor touches them. Examples include the dark area surrounding the search box (IE6 only) or the menue items in the dropdown list (IE7 only).
  • Ancient Gecko browsers (e. g., Firefox 1.0.x with Gecko 1.7) sometimes draw spurious lines when the submenus are activated. This does not appear in version 1.8; yet there might still be very slight distortions or other artifacts on the top line whenever menus open or close. The issue was completely fixed in version 1.9.
  • There is an erratic Gecko bug (up to 1.8) affecting the lines in tables. Occasionally, these lines are not drawn in parts of the table. Reload helps.
  • Konqueror is pretty bad with scrolling correction when document-internal anchors are selected. Often, it works only on the second try. The problem is obfuscated by the fact that early Konqueror versions (3.3) throw an onload event whenever you switch to a different named anchor in the same document, while more recent versions (3.5) don’t. I wonder what 3.4 does…
  • Moreover, Konqueror 3.5 scrolls in ridiculously low speed when you jump to another section in the document. I do some tricks for avoiding the scrollBy method and use scrollTop directly whenever it is safe.
  • Opera sometimes forgets to erase the link descriptions which should appear when you hover the mouse cursor over menue items in the right panel (the problem seems restricted to the Linux version of Opera). The DOM looks perfectly right, the problem appears to be located in the graphic backend. To fix this, an amazingly complicated kludge involving onMouseOut event handlers, DOM manipulations, time delayed execution and moving around an empty dummy element proved necessary to force a redraw. This had almost IE6 level!
Background Images
  • Microsoft Internet Explorer completely fails in all versions except 7. I had to compromise the layout in order to keep it somehow palatable for that browser. By a creative combination of hairy techniques, it almost appears to work even with old IE versions.
  • The halfscreen PNG images are ugly, but necessary to create buttons and mouseover effects since neither fixed background images nor PNG transparency is supported in a reasonable way by all versions of MSIE prior to 7. Halfscreen images are just simple PNGs with a chessboard-like array of transparent and opaque pixels that are used to simulate 50% transparency in a crude way.
  • If loading of background images is disabled, the navigation panel becomes difficult to access for Internet Explorer 6 because there is no way to apply highlight to the background. Other browsers, in contrast, will automaticaly yield a layout very similar to the no background images alternate page style.
  • An extremely curious bug with Apple’s Safari bugged me for more than a year: If any DHTML changed any stylesheet properties (e. g., language selection in indices oder spice articles), then the background images would vanish. As I could not run Safari on my machine at that time, and this clearly was no easy thing to understand, it had to remain open for quite some time. After a wine port of Goggle’s Chrome browser (which uses the same rendering engine, WebKit) became available, I was finally able to understand the problem: The background-less alternate style file became somehow activated. It turned out that the disabled property of the LINK elements relating to alternate stylefiles takes the (incorrect) initial value false, although the style file is disabled. This inconsistency does not confuse the browser unless a JavaScript changes style file rules – a rather complex bug. A simple initialisation of the disabled property for all alternate style files solves the problem.

Browser recommendation

Fortunately, I am now able to run all major and many minor browsers on my Linux box, with the sole but bitter exception of Internet Explorer 8. Thus, I can compare them on equal foot, taking into account that native Windows versions often may run better than hasty ports (Opera, Chrome) or wine kludges (Safari, Internet Explorer).

Screenshot showing different browser windows

As a conclusion, I recommend the use of Gecko browsers for my page, but the same holds for the majority of the Web. Of these, Mozilla Firefox is most popular, but the other members of the family (Galeon, Epiphany, Camino, Seamonkey) had largely the same features in the past. Now, with Firefox 3 being ready, Firefox beats its cousins by its new, greatly enhanced layout engine Gecko 1.9 which gives very clean layout and is also tremendously fast. Those browsers that still use Gecko 1.8 will also render complex scripts unreliably (or reliably false), while Firefox 3 with its new Cairo backend has good to excellent performance here.

Opera is an excellent product and can be recommended for all users that prefer a slim, fast but reasonably-featured web browser (yet complex scripts are still problematic, with limited functionality under Windows and no support under Linux). It has very good standard support and even allows to change CSS selectors by JavaScript (something that does not work with any other browser), which allows me to add a small benefit to the Ge‘ez Index. Moreover, Opera 10 is the clear winner of my benchmark tests and thus proves its nickname The fastest Browser on Earth.

Konqueror, the native KDE web browser, is terribly slow and has a couple of deficits in the field of JavaScript, but it is very good in CTL (which it mastered long before Firefox did) and fits well into the KDE Desktop. Its rendering engine, KHTML, has been much developed by Apple; this improved version is referred to as WebKit.

WebKit first appeared as the backend of Apple’s Safari browser. Safari shows a couple of quirks, but it has excellent typographic quality; allegedly, the original Mac version runs more stable than the still somewhat experimental port to Windows (which can be made to do its job under Linux as well). Safari rendering peculiarities are usually well reproduced on Google Chrome, for which both a wine based Linux port and an early native Linux version are available. Chrome is rather minimalistic, offering a super-slim yet powerful user interface and a good and rather fast rendering engine. The upcoming Linux version of Chrome (currently available as alpha) looks quite promising, and even now performs well in some suble CTL-related topics, like Hangul Jamo and Indic text. Trolltech’s multiplatform Arora browser also has a WebKit engine, yet it is rather simplistic and my version 0.4 uses an ancient WebKit incarnation.

With Internet Explorer 8, Microsoft has delivered good work. Though still somewhat strange and rather slow in its JavaScript implementation, it boasts a full CSS 2.1 implemetation on equal level with the ones in Gecko, WebKit and Opera, and it beats the latter when it comes to CTL: IE8 (and also IE7) render my Indic Spice Index better than the rest of the pack, because even the complicated scripts of Malayalam and Oriya are well supported (yet Unicode 5.1 extensions for Malayalam are missing, at least on Windows XP). Note that IE8 does not support a range of rather new (in part incomplete or experimental) standards like CSS3 or XML and friends, but these are in any case rarely found in today’s world wide web.

Internet Explorer 7 suffers from numerous small deficits, but it still is an acceptable and close-to-modern browser which can safely be recommended. Main points for critique include its ideosyncratic JavaScript-oid scripting language, its mediocre speed and the still incomplete support of CSS2 (do you see quotation marks here? You should!). Yet earlier versions of Internet Explorer, particularly the still much-used version 6 (15% of visitors in fall 2009), classify as APITA and should be avoided, if only for pity with frustrated web authors. I increasingly lose interest to spend time solving the countless small or medium problems this web browser has with my pages, and at some time not too far in the future, the Spice Pages will give only basic functionality with this ill-begotten thing that even museums should refuse to host. I will say naught about still earlier versions, except that those using them are either sadists or victims of sadists.

Gallery: Hall of Fame and Hall of Shame

The following screenshots document how various browsers render this site as of November 2008. The url displayed is always the same, and a small viewport size is chosen to keep file sizes moderate. The images are reduced by a factor of two.

I buoni…

The following pictures are screenshots of some common browsers with full (or at least significant) CSS2 support: Konqueror, Safari, Chrome, Opera, Internet Explorer 7, Firefox and Mozilla. For each browsers, the screenshot was prepared either with JavaScript disabled (left) or enabled (right).

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

These browsers do almost everything right. Nevertheless, a few problems are visible: Mozilla (and other browsers based on Gecko 1.8) draws spurious vertical white lines around the menus. The vertical spacing of the submenues for all Gecko browsers is too large for my eyes; thus, I decrease it by JavaScript. In IE7, the connection of the popup menus is not transparent. Opera has problems with the menu item description (lower left corner) which are solved by JavaScript. Slight rendering flaws of the other browsers are not visible in the reduced size. Refer to the above table for rendering misbehaviour details.

… i brutti …

Internet Explorer 6.0 (top row) was the dominating browser on the web, and it still has an enormous share in the overall market second only to its successor IE7. Thus, much care is spent to make the design work (or almost work) for that browser. Internet Explorer 5.5 in the bottom row works much less perfectly (5.01 is very similar). As before, each browser was tested with (right picture) and without (left picture) JavaScript (Active Scripting as it is called by Microsoft).

Internet Explorer 6.0 (Trident)
Internet Explorer 6.0 Screenshot (no JavaScript) Internet Explorer 6.0 Screenshot
Internet Explorer 5.5 (Trident)
Internet Explorer 5.5 Screenshot (no JavaScript) Internet Explorer 5.5 Screenshot
Internet Explorer 5.0 (Trident)
Internet Explorer 5.0 Screenshot (no JavaScript) Internet Explorer 5.0 Screenshot (JavaScript)
Simulation of fixed background images by halfscreen PNG image in IE6 as compared to The Real Thing
Top left corner of main page, rendered with Internet Explorer 6 (top) and Seamonkey (bottom)

There are several faults with the still very common version of Internet Explorer, 6.0. Without JavaScript, the dropdown menus cannot work; the transparency effects need a lot of care and can be simulated only imperfectly (in the reduced size, they look actually better than in the real thing). The menus cannot appear transparent, and the highlighting is applied inconsistently. Also, note that the message suggesting to enable JavaScript may hide some page content. A minor flaw is that the first paragraph in the subsection gets indented, which it should not. The top navigation bar falls short of the page width. Also, some images are moved below the left navigation box and thus appear truncated (they should be placed vertically for small window sizes).

Things get far worse when we switch to the older 5.5 version (and 5.01 likewise). Fixing the navigation panels requires JavaScript, and works poorly even in JavaScript is turned on. There is a spurious border in the menu items that does not highlight correctly. Moreover, the width of the main box is computed incorrectly in IE 5.5; I suspect that this confusion is caused by the presence of extra-wide images somewhere on the page. This bug affects only few pages, but can be very annoying as reading the text required horizontal scrolling. Readers may be able to workaround by increasing the viewport size. Quite interestingly, the text running width is correct in IE 5.0, but the top navigation box is messed up (it’s right aligned instead of centered; this bug is triggered by the presence of the right-aligned image), and generally images are almost never aligned horizontally, which is why you can see only one image of the intended row of three.

I was not able to produce screenshots for IE4 — the program crashes often and produces JavaScript errors en masse without uttering helpful diagnostics. I guess that a native IE4 installation (as opposed to my hacked parallel installation of different versions) would behave better. It appears that styling the navigation panel works very imperfectly, and JavaScript-based tricks to keep the panel position-fixed don’t work.

… i cattivi

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

Netscape Navigator 4.8 (top left) and Internet Explorer 3 (top right) both support some parts of JavaScript and CSS1, but far less to be fully functional. What remains is a basic, somehow broken but still somewhat legible page layout. For both browsers, the lengthy introduction (which converts to the navigation panel by CSS) can be skipped by means of JavaScript, improving legibility. However, IE3 produces some (non-informative) JavaScript error messages and generally behaves very unstable on my box, crashing reproducibly with some documents.

The browsers in the bottom row (left Dillo, right Lynx) are intentionally basic and support nothing except pure HTML. They cannot (as the previous) be considered broken, but minimalistic to the extreme, which makes them useful for only a small minority of users. UTF-8 support is poor in Netscape, and non-existent in Dillo prior to version 2.0 (and outright bad for later versions, where I still see no support for Arabic, Indic, Chinese and other writing systems not derived from Greek).



Unicode Encoded Validate using the WDG validator Validate using the VALIDOME validator

Top    Validation    Unicode    Style Sheets    JavaScript    Browsers&Bugs    Gallery      (i buonii brutti  e  i cattivi)    Bottom