Geoff Chappell - Software Analyst
Among the known problems are several that seem important enough to warn about.
Web purists, relax! As of 2021, this website no longer uses FRAMESET or FRAME, though it does use IFRAME. Either way, be assured that no frame at this site loads anything from any other site—ever.
I’m biased, but I think the site is far more easily navigated and its content far more easily comprehended with the expandable table of contents (TOC) in the left panel. Like it or not, the TOC is in an IFRAME which is prepared dynamically by scripts. I don’t guarantee that the tricks involved in presenting it will work in all browsers and I don’t intend to try any old browsers other than Internet Explorer. Even there, I draw the line at Internet Explorer 7.
The move away from frames comes at a cost which the standards (and numerous commentators on best practice) seem curiously shy of admitting to when declaring frames as obsolete. Their use may very well be deprecated. There may very well be something to make do with instead. But they are not obsolete.
Something the browser gives for free with frames is resizing. When the table of contents (TOC) to the left and the document page on the right were each in frames, the divider between them could be moved just by dragging. The only work required of scripts was something that truly is extra: preserving your choice as you moved from page to page at the site. Without frames, this ease of adjustment by dragging is gone and has to be made up as extra work.
I have done what I can for TOC resizing simply because I miss the functionality, but it may not work entirely correctly for a while.
There is always the alternative of resizing the TOC by manually editing the URL. For instance, appending “?tw=300px” (without the quotes, or “&tw=300px” if there is already a URL 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.
Some browsers present a small problem with this manual resizing. What might be the ideal is that the divider’s position is specified as a percentage of the window’s width, as it is in the stylesheet. You can set the TOC width manually as a percentage, though you may have to “escape” it, as in “tw=30%25”. Internet Explorer keeps to this. Other browsers convert to pixels. This becomes a difference in practice if you resize the browser. I surely will do something about this too, again because it bugs me, but for this too I may not get to it for a while.
The expanded TOC has vertical lines to guide the eye about how deep into the tree are the list items. You might think this is a basic point of user-interface design. It certainly was once thought to be, as for the Windows Explorer’s presentation of a directory tree in its left pane. That it now looks old-fashioned, having been dropped from the Windows Explorer as long ago as Windows 7, is to my mind a good illustration of an industry’s enthusiasm for the new without regard for whether anything helpful is lost.
Some reason for the relative scarcity of sight lines in nested lists my be that arranging for them with HTML and CSS is curiously difficult. The sight lines ideally run through the centres of the list-item markers, but this alignment requires knowledge of the browser’s placement of the list-item image, marker box and principal box. I can easily believe I have missed where this basic knowledge is standardised. Against this is that I can as easily believe that this placement isn’t specified and that standards-compliant sight lines in unnumbered lists truly aren’t possible. Until I ever sort this out, I set the sight lines for Internet Explorer 8 and higher, and for Microsoft Edge as shipped initially with Windows 10.
That the scripts generate the frame-like presentation dynamically has an unwelcome side-effect. When you return to a page via Forward or Back navigation, your place in the TOC is not recovered. I suspect this just has to be lived with. Sorry. I myself tend to browse successive pages by opening each in a new tab.
On the plus side, I have improved the support for moving from page to page by opening each in a new tab. I am surprised that I neglected to have it that following a link from a context menu did not preserve the TOC state: this is fixed.
The problem with moving forward and back 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. Years ago, I imagined I would some day sort it out easily enough with Internet Explorer’s facility for script debugging. How those years have passed in practice is that I have barely ever given the problem a thought.
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.