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.
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. 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, 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 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 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, marker box and 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 unnumbered 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.
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 (the theme here being that these are 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.
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.