Browser Requirements

Every page at this site should present acceptably even with a dumb browser. However, navigational support and some other refinements come with some impositions.


It is surely uncontentious and perhaps not even worth mentioning, but the pages at this site simply assume support for Cascading Style Sheets (CSS) version 2.0, though avoiding features that were not yet supported by Internet Explorer before version 7.0. By “assume” I mean that I do not even try to defend against browsers that do not support CSS, nor even do I provide for graceful degradation if CSS support is deficient.


The dynamic table of contents (TOC) requires that your browser supports frames. Indeed, it requires that your browser allows JavaScript to build frames dynamically. I do not quite assume such support, but neither do I attend very much to guiding you around the lack of it. If the support is absent then ideally you will see the site as if scripts had not run and you should then be able to access a static TOC. If you do not at least get this fall-back behaviour, then please write to me about it and I will see what I can do to help.

The need for frames is avoided entirely if you disable client-side JavaScript.


Client-side scripting is essential to the interactive support for navigating the site through a TOC. Many refinements, such as tooltips to elaborate on why inline text is bold or italic, also work through scripts. I write this text and I lay it out with the expectation that scripts will run. It will read better for you if the scripts run as intended.

That said, I do anticipate that scripting may be disabled and I intend that what you see without scripting should still be usable. Though the navigational support will be greatly reduced (from a dynamic TOC in a frame to a static one in a separate window), you may be sure of seeing all of each page’s text or at least some notification of what you are missing.

This website is not one of those, which are much too frequently encountered all around the Internet, that give you a blank page because you had the temerity to browse with scripting disabled. Neither will this site dismiss you with notices such as “This site requires JavaScript to enable full functionality” when actually presenting you with no functionality. We should all be embarrassed that our world lets people get away with such euphemism. (That particular one is from Microsoft.) If you browse without scripting and feel insufficiently supported, then please write to me about it and I will do what I can to support you better for reading my work.

Internet Explorer

In practice, the scripts at this site may not run as intended unless your browser is Internet Explorer.

In supporting Internet Explorer, I set out from the beginning (in 2007) to avoid features that were marked in Microsoft’s documentation as requiring very recent versions of Internet Explorer. I have briefly checked, from time to time, that the scripts work with Internet Explorer versions as far back as 6.0 (from Windows XP). Please note however that I do not expect to check version 6.0 every time I edit the scripts. If you use old versions and suspect a problem, then please write to me about it and I will do what I can.

Support for Internet Explorer 5.0 was explicitly abandoned late in 2011.

Other Browsers

When first writing these scripts, very much as a novice, my reference material was Microsoft’s, both for the JScript language and for what Microsoft has made scriptable in its browser. I have eventually reviewed the scripts for at least theoretical conformance to the published JavaScript, HTML, DOM and CSS standards and I have paid some attention to compatibility with Mozilla Firefox (starting from version 3.0.10) in particular. Even more so than with Internet Explorer, I do not expect to keep checking different browsers in different versions every time I edit the scripts. If the scripts “don’t work” for some browser other than Internet Explorer, then please write to me about it but please also spell out the solution for me. Attending to browser issues can never be more than second to building the site’s content. I simply do not have the resources—or, frankly, the will—to test browser after browser after browser. Indeed, I don’t have the will even to possess multiple browsers, and I don’t understand why anyone would.

If you think that by dismissing other browsers I pander to Microsoft’s dominance, then I ask you to consider that I have done very much more than my fair share over many years to expose freely the sorts of programming details that are essential knowledge for any informed assessment of what Microsoft actually does in its software. Of nearly two thousand pages of content at this site, almost all report on Microsoft’s products, often with critical comment supported by a technical depth that you likely cannot find elsewhere.

Scripted Danger

Even to hope that you run scripts is already as much compromise as I care for. I myself do not have scripts enabled while browsing the Internet, except for sites that I have decided particularly to trust. Though Internet Explorer advises that “scripts are usually safe”, the fact is that even simple scripts can cause all sorts of trouble, including to leave the browser seem hung and to induce the browser (and thence Windows) into stress conditions.

For instance, click on the “Show Demonstration” button immediately below to reveal both a small script and a “Run Demonstration” button. Click the button to run the script, which is just a simple function that keeps reallocating memory for an ever-larger string. Because the size increases only by one character each time, this loop executes only very slowly. Depending on the browser, it can be quite some time (hours, even) before the browser’s defences against hung scripts get triggered. For Internet Explorer 7.0 on Windows Vista, the browser is meanwhile hung. It does not respond even to its close box or system menu. You will likely want to close it from the Task Manager rather than wait for either the browser or Windows to notice that anything is wrong.

There is a demonstration here. To see it, please enable scripting and then refresh this page.

function Test_LookHung ()
    var s = 'a';
    for (;;) {
        s += 'a';

The second demonstration is similar, but places the browser under more stress more quickly and may trigger the browser’s defences much sooner. In this script, the string is doubled in size on each loop. Before very long, the browser is seeking such large amounts of memory for this string that all its requests are failed. Yet if your browser is Internet Explorer, the script is not aborted. Each loop continues to execute, unsuccessfully of course, but relatively fast. The tally of executed statements quickly reaches a configurable (though apparently undocumented) limit, so that the browser finally alerts you and offers to stop running the script. You should accept this offer.

There is a demonstration here. To see it, please enable scripting and then refresh this page.

function Test_LowMemory ()
    var s = 'a';
    for (;;) {
        s += s;

Note that scripts can get run in all sorts of ways that may not be obvious to you while you read a page. Clicking here will run the first of the preceding demonstrations. Just passing the mouse over here will run the second.

The preceding two demonstrations cause trouble just by doing on a large scale things that are entirely reasonable on a small scale. Moreover, they are relatively harmless bits of play. Scripts can, however be devised specifically to exploit a known defect in a browser. Then, their mischief can be undeniably serious. The script in the next demonstration targets a long-standing defect in Internet Explorer. It gained some notoriety in January 2010 as having allegedly been used in cyber attacks on Google and others. The code is deliberately erroneous. An HTML element is created, inserted into the document and made the source of an event. The event handler saves a clone of the event object and removes the source element from the document. The defect is that the source element is freed from memory while the clone retains a pointer to it. By using this pointer after the event, the script typically triggers an access violation. Do not proceed with this demonstration unless you are prepared for Internet Explorer (if not fixed) to crash:

There is a demonstration here. To see it, please enable scripting and then refresh this page.

function Test_DeletedSourceElement ()
    var element = document.createElement ("div");
    document.body.appendChild (element);
    var savedevent = null;
    element.onclick = function () {
        savedevent = document.createEventObject (window.event);
        document.body.removeChild (event.srcElement);
    element.fireEvent ("onclick");
    var rubbish = savedevent.srcElement;
    alert ("Congratulations. The script did not cause a problem.");

As with the other demonstrations, this could easily be made to work without any user activity. Just visiting a page would bring down an unfixed Internet Explorer. And that’s the good outcome: a program’s use of freed memory can sometimes be exploited so that the program doesn’t crash but is instead diverted according to the exploiter’s wishes.

So, although scripts are usually safe, they do have their dangers. Everyone who writes a web page ought to regard you as completely reasonable for preferring to browse with scripts disabled. Instead, if they don’t ignore you entirely, they tend to dismiss you as a crank, even while they assure you of their own commitment to Internet security.


If you browse this site with caching disabled, then please also disable scripts.

Without caching, your experience will be very much poorer. I imagine it would be poorer just from repeated requests for scripts and style sheets as you move from one document to another, but you will be hit especially hard by asking over and over for tiny image files in the TOC even if you’re here just for one document. Rightly or wrongly, each TOC is designed with the expectation that the whole thing is downloaded once and cached.

Revision in 2011 made it even more important that you do not disable caching if you run the scripts. Without caching, every document you view will be downloaded twice, first to run the scripts and then when the scripts reload the document into a frameset with a banner and TOC. It offends me to do it this way, given that the browser already has all the content of the document by the time the frames are prepared, but I can see no way to get this content correctly into the frame except by reloading the frame’s window object.

Not Required, Not Wanted

Nothing at this site accesses any other site, except through a link which you can choose to follow or not. Trust is not transitive. Your trust in me, if I earn it, would be misplaced if I then presumed it for connecting you to other sites, even just to fetch images.

Nothing at this site cares about your settings even for relatively benign things like cookies and Java applets, let alone for the outright danger of ActiveX controls and other sorts of plug-ins. I try never to let these things loose on my computer when I browse the web, even at sites that I otherwise do trust, and I grumble at the many sites that misbehave, even embarrassingly badly, when these things are disabled. I therefore will not push them onto anyone else.

If you find anything at this site that causes you any concern for your privacy or for your computer’s security, and which isn’t clearly marked as a demonstration, then please believe that I did not intend it and please write to me about it so that I can know to correct it.