Geoff Chappell - Software Analyst
Among the known problems are several that seem important enough to warn about, either because they’ve had a big influence on the design or because I suspect I’ll never deal with them properly.
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 this website 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 its presentation 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, older versions being known to have no support for the fixed positioning that’s needed for DIV to do the work of FRAME.
If the frame-like presentation with an interactive TOC gives you any trouble, or if you simply dislike it, then disable JavaScript for your browsing of this website. You’ll lose some refinements such as the tooltips that explain why text is bold or italic, but you will see all of each page’s content or at least a notice about what doesn’t show. For navigation, you can load a static TOC separately for a script-less user interface. If your browser does not support your disabling scripts for a specific site—amazingly, some make this difficult—then add “noviewer=true” to the URL search string and although the scripts will still run, they’ll do so no more than needed to disable the frame-like viewer each time you load a new page.
The move away from frames comes at a cost which the standards (and numerous commentators on best practice) seem curiously shy of admitting when declaring frames as obsolete. Frames may very well be deprecated. There may very well be something to make do with instead. But while replacing them comes at the cost of substantial work to make up for lost functionality, they are not honestly presented as obsolete.
Something that even the oldest of usable browsers give 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 of placement 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. And to do it with any sort of efficiency and robustness is certainly not trivial work!
I am doing what I can for TOC resizing simply because I miss the functionality, and of course if the work must be done, then it’s as well to seek some advantage from it. For instance, the resizing can come with options and with tooltips to explain them. These finer points of user-interface design will take time to settle. Some or all of this 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=30” (without the quotes, or “&tw=30” if there is already a URL search string) sets the TOC’s width to 30% of the viewport width. The default is 25%. The width specification is also accepted with CSS units such as “300px” for 300 pixels. You only have to edit the URL once: the scripts will preserve your choice as you move from page to page.
Even with this workaround, there is some continuing difficulty with the unit of measurement. Things to do about it are known. Implementing them is not presently high in priority.
An 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 with 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 may 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’s image within its marker box and of the marker box relative to the principal box. I can easily believe I have missed where this basic knowledge is standardised, but I can just as easily believe that this placement isn’t specified and that standards-compliant sight lines in lists truly aren’t possible—well, not without losing the semantic value of list items as LI elements with marker boxes.
I am more than slightly amused that commentators who disparage the use of tables for layout seem perfectly happy to play games with list-item backgrounds to simulate list-item markers to get, yes, the desired layout. And some even advocate using tables instead of lists! In fairness, many do get very presentable results—better than mine, even—but they are not semantically correct.
Until I ever sort out what best to do about sight lines, I set them to match my observations of Internet Explorer 8 and higher, and of Microsoft Edge as shipped initially with Windows 10 (the theme here being that these are, or were, the browsers that all Windows users have, even if not all care to use them). Even when this choice leaves the sight lines misaligned, as for Google Chrome, they still seem (to me) a lot better to have than not.
The best I have yet seen to improve on this is to have the scripts observe mouse movements that are to the left of the list item’s border box yet still trigger events on the list item. Move the mouse among the list-item images sufficiently slowly and a measurement may be made with reasonable confidence, give or take a pixel. The scripts then adjust the list-item margin so that the sight lines are better aligned, and then they carry the measurement to the next page that you navigate to. Beware, though, this heuristic work-around does sometimes go a little wrong!
What can I say about the mess that the CSS standard makes of table styling!
Eventually, I may have quite a lot to say. This site has many tables, many of which are not simple grids but instead have two or more cells merged vertically into one (though only rarely merged horizontally). More than a few of these tables have one or more columns whose content would better be right-aligned or would better not be broken at white space.
When this website was designed, the dominant browser of the day allowed a straightforward styling of table columns, at least for text alignment. Whether this was already non-standard or whether the standard-compliant browsers of the day interpreted the standard such that they did not support this styling, I do not know. It is explicitly non-standard now, even though the standard provides no substitute that is anything but obviously inadequate. Yet it’s not unusual to see work-arounds passed off as good, clean CSS!
Until I work out whether the things that can be done about this are worth the effort, I have taken the view that missing right-alignment where it might be desired is not nearly as bad as picking it up where it’s definitely not wanted, and I have therefore removed all table styling. It’s only slowly getting put back, depending on what’s needed for whichever pages I get round to editing for technical content.
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 TOC expansion and scrolling is not recovered. Neither is your scrolling of the document pane. 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 around the site by opening pages in new tabs. I am surprised that I neglected—for a decade!—to arrange that following a link from a context menu preserves the TOC state.
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.
Though I do still try to support browsing with Internet Explorer 7—this was the browser that shipped with Windows Vista and statistics at the web server show more hits from computers running Windows Vista, specifically, than all versions of Google Android taken together—there is only so much I can do.
As noted above, the site now needs that the browser supports fixed position (in contrast, for instance to, absolute and static). Internet Explorer 7 does support fixed position but only selectively. Pages that are still written for quirks mode show as if scripts haven’t run. There is nothing to be done about this except to edit all the pages and re-upload them. I have no plan.
Even for pages that do get fixed position from Internet Explorer 7, there are other problems. For instance, the root DIV in the TOC has no height or width when the TOC is newly loaded, but because it has the scrollbars, the TOC’s scrolling from before the navigation cannot be restored. The page that shows in the document panel is highlighted in the TOC but might not be scrolled into visibility. Since the scrollbars are on the DIV only to work around the scrollTop property breaks with body height 100% overflow auto problem in newer, supposedly superior browsers, there surely is something I can do about avoiding this side-effect for Internet Explorer 7. But it’s also just inevitable that my enthusiasm for making special cases for this old browser is fading.