Technical notes about this site

I changed the layout 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 resizable. 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. Another minor disadvantage is that the visitor may no longer request a “frame-free” version of the site (useful for small displays). I think this can be solved with scripts, alternative style sheets and either cookies or dynamic HTML, but currently, this is not a high-priority issue for me.

I am indebted to Jonas Fansa for his numerous aids and cousels in matters of aesthetics and style. He also provided the background image, which shows the Chinese spice mixture 鹵水料 (see cassia for more).

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

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

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 is the past be 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.

Characters and Fonts

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:

It defines Characters and assigns both a unique name and a unique numerical identifier (code points) to each character.
It maintains a list of properties for each character. These properties determine the behaviour of each single character: Whether it needs space, whether it combines with other characters, whether it can be decomposed into simpler characters, whether it runs left or right on the page, and much more.
It tries to cover every script ever used by mankind. Currently, the Standard contains all official scripts allover the world, and some historic ones as well. However, there are still many scripts missing, for example Balinese, which is still in use among certain communities, though it is no longer tought in Balinese schools.
Except for a few compatibility cases, the Unicode Standard does not encode variant glyphs. Generally, it does not prescribe the visual appearance of characters. This is left to designers of fonts.

To learn more about representation of characters, you might want to read some tutorial, e.g., the excellent Character Set Issues page by A. J. Flavell.

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 perform very well in this respect, users of other operating systems might have to install special libraries and may need enhanced builds of their browsers. To verify your system's ability to typeset complex scripts, you can check out the Transcriptions of “Unicode” page.

The page uses UTF8 transport encoding to reduce file sizes. The encoding is declared in the http header. Formerly I coded non-ASCII characters by numerical HTML character references, but I found out that even the most archaic browsers handle UTF8 multi-byte sequences reasonably well; still, in the preview phase of the new layout, the pages work with character references despite the UFT-8 declarations.

Cascading Style Sheets

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.

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 resizability. Nevertheless, Microsoft Internet Explorer 6 does not support this property value (except for the BODY tag). Since that browser is too stupid for transparent PNG images also, I simulate that functionality by halfscreen GIF 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 Browser^TM 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 used JavaScript event handlers and delayed execution for an additional downscroll of the main box. The necessary mount 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 (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) errorneous handling of absolutely positioned boxes.

For Microsoft Internet Explorer, JavaScript (in the form of Dynamic HTML) 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.

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 up to 1.5 and other Gecko browsers (Seamonkey, Epiphany, Galeon), Opera 8.51, and Safari (1.3.1 and 2.0.3; I have only sporadic access to these browsers). 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. The current version 6.0 works almost correctly; yet there are some limitations for the older versions: Versions 5 and 5.5 work acceptably, although 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 bizarrnesses 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 (downlevel-hidden conditional comment). 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).

With their new Internet Explorer 7 (available as public beta 2), Microsoft really surprised me in a positive way. IE7 now 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 can be solved easily by some additional CSS rules. Only JavaScript poses unresolved major problems, but I hope to fix that as time goes.

Some still open problems are listed below. Note that some are rather limitations due to the underlying technical mechanisms, and are probably impossible to fix. Others might be corrected in the future. Yet others are browser bugs that may vanish in future versions.

General appearance

Background images are still pretty large. Currently, CSS2-compatible browsers will be fed 85 kbytes of background images, while users of Internet Explorer up to version 6 will have to load only 41 kbytes because the browser cannot show the intended background effects anyway. For comparision: 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 29 kbytes of text plus 117 kbytes of inlined images.
Support for printing works imperfectly.
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.
Konqueror 3.3 shows a number of flaws in rendering: The search field does not scroll correctly, and reloading a 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.
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.
BIDI support is imperfect for Konqueror and Safari (visible in the Arabic index only).
A pretty funny bug: MSIE 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. Nevertheless, spice_arabic.html#init_ك and spice_arabic.html#init_ک point to an identical location in all versions of MSIE.
Gecko browsers 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).
Konqueror suffers from the same disease, yet has no cure.
Internet Explorer will often fail to retrieve characters not present in the standard font; this particularly applies to Old Greek text and some latin characters with unusual diacritics. I have implemented a mechanism that largely circumvents the problem. Unfortunately, this requires extra markup.
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 under Windows XP, and to serve surrogates ţ and ş to even less capable systems (Konqueror, MSIE on Windows before XP) and to search engines.
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 quite well, but unixoid operating systems have generally poor support. Gecko browsers usually cannot fully exploit OS support even if it is there.

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: 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 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.
Mozilla Seamonkey 1.5α (but not the stable 1.0 releases) does not keep position-fixed elements fixed during a scroll operation, but moves 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. According to Bugzilla, the problem is known and scheduled to be fixed in the next stable version. In the meantime, alpha version of other Gecko products might also become affected.
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 desaster.

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 menues cannot work on the search result page for said browsers. The reason is that the Dynamic HTML/JavaScript gets blocked by a security policy because the script and the HTML come from different servers.
Microsoft Internet Explorer only: Some inconsistencies in the the visual appearance of the menue. Opening a submenue 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).
Older Gecko browsers (e.g., Firefox 1.0.x) sometimes draw spurious lines when the submenues are activated. This does not appear in more recent Gecko versions; yet there might still be very slight distortions or other artifacts on the top line whenever menues open or close.
There is an erratic Gecko bug 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.
Opera sometimes forgets to erase the link descriptions which should appear when you hover the mouse cursor over links in the right panel. As a workaround, the area of the link descriptions has been increased.

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” GIF 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 GIFs 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 because there is no way to apply highlight to the background.

Gallery: Hall of Fame and Hall of Shame

The following screenshots document how various browsers render this site as of February 2006. 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 Konqueror 3.3, Opera 8.51, Internet Explorer 7, Firefox 1.5 and Mozilla 1.7.7. For each browsers, the screenshot was prepared either with JavaScript disabled (left) or enabled (right).

These browsers do almost everything right. Mozilla draws spurious vertical lines around the menus. In IE7, the connection of the popup menues is not transparent. Slight rendering flaws of the other browsers are not visible in the reduced size. Refer to the above table for redering misbehaviour details.

… i brutti …

Internet Explorer 6.0 (top row) is currently the dominant browser on the web. 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).

There are several faults with the most recent 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. Without JavaScript, the bottom navigation bar falls short of the page width.

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; I suspect that this confusion is triggered by the presence of extrawide 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.

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

Report problems and suggestions to