Known Problems At This Website

Among the known problems are several that seem important enough to warn about.


All the main browsers other than Internet Explorer have trouble just with the basic presentation of frames.

Mozilla Firefox does not show the intended borders between the frames. The borders are present, as spacing between the frames, but they are white, even in a variety of configurations for such things as background colour. If you know how to get this particular browser to display flat coloured borders between frames, then please write to me with the solution. Opera is no better: it fills the space between frames with a different choice of colour (which experiment suggests is always the ButtonFace system colour). If only for now, I adjust other elements to match these browsers’ choice of colour.

Apple Safari and Google Chrome don’t even show space for the frame borders. Among the consequences is that no user-interface support is available for resizing the TOC. If you want to resize the TOC, you can do so by manually editing the URL. For instance, appending “?tw=300” (without the quotes, or &tw=300 if there is already a search string) sets the TOC’s width to 300 pixels. You only have to do this once: the scripts will maintain your width specification in the URL as you move from page to page.

Nothing is likely ever to be done about these problems with frames. Though it seems common to argue against using frames at all, I have found no alternative that is even nearly as functional. (And, no, using the XMLHttpRequest object to load content into a DIV is only superficially similar.) These frames actually are used as frames, with content drawn from files that are each written to be self-standing. If any HTML authors read this and believe that the functionality of frames can be replaced, then please write to me for my enlightenment and presumably for the benefit of other readers who should be spared from frames. Short of that happening, the site always will use frames unless you disable JavaScript.

If you don’t want the frames, then disable JavaScript. The trade-off is that you then won’t get the dynamic TOC for navigation and you’ll lose some refinements such as the tooltips that explain why text is bold or italic.

Forward And Back

A revision in 2011 has the scripts generate the frames dynamically. This has an unwelcome side-effect. When you return to a page via Forward or Back navigation, each frame is restored as if unscrolled. You lose your place. I suspect this may be fundamental to the dynamic generation of the frames, and it just has to be lived with. Sorry.


The problem is worse when bookmards are involved. In Internet Explorer, going backwards through the History when a URL along the way has a bookmark can insert a spurious page into the History. Since only very few pages here use bookmarks, I don’t plan to give this problem much priority but I expect I will some day sort it out easily enough with Internet Explorer’s facility for script debugging.

Just following a bookmark within a document page is a problem for Firefox. It shows the bookmark in the URL but does not move to the bookmark. Curiously, it then does move to the bookmark if the page is refreshed. Since I find script debugging to be markedly less well developed in Firefox than in Internet Explorer, any problem with scripts in Firefox is much less likely to get attended to any time soon.


Logs at the server show that some browsers make heavy work of the TOC by requesting over and over the same tiny image files that serve as list-item markers. Since some of the TOCs are large, the requests are repeated hundreds of times for what looks like no good reason. This seems to be only partly remediable through cache control from the page. In at least some of these cases the browser is caching nothing, which may be its user’s deliberate choice. If so, I can do nothing about it. In many other cases however, the logs show that scripts, stylesheets and HTML pages are cached, just not the images from the TOC. Where this happens with Internet Explorer, there is at least some possibility of reproducing the problem on my intranet and debugging it. Except for this, I think I can never do much about any problems that involve caching: I can’t justify client-side debugging for browsers other than Internet Explorer and I don’t even have the means to debug the live server.