In other news:

• Phlogiston “seemed like a good idea at the time”;
• Doubt cast on Ussher chronology;
• Cold Fusion - yeah, right.

Next, the Shipping Forecast.

Being an idiot, I didn’t do a backup first. When the system restarted, it got to the grey screen with the Apple logo and the spinning gear, where it remained… for over half an hour.

At this point I gave up and switched over to my PowerMac, where an intensive Google session commenced. There appear to be a number of people encountering this or similar problems, but various suggested solutions didn’t work.

I was able to mount the MacBook on the PowerMac in target disk mode (which somebody on this Apple Support Discussions thread wrongly claims is impossible) and followed some of the steps listed at MacFixIt’s “Startup fails (particularly after a system or security update); solving” tutorial, specifically, deleting assorted cached OS files.

However, the MacBook still wouldn’t start, not even in Safe Mode.

So I then downloaded the standalone installer for the update from Apple. Despite being an Intel update, this ran on the PowerMac, and detected that the FireWire drive was a bootable Intel OS X installation. It installed successfully, and having ejected the MacBook drive, I restarted, holding down the Shift key to reboot in Safe Mode.

Bingo! The MacBook booted up. I restarted again, and it booted normally.

Panic over, and time to do a backup.

Hopefully this solution will prove helpful to anybody in the same situation.

UPDATE: It’s wretchedly broken in IE6, and far from perfect in IE7. Why am I not surprised?

UPDATE: And, with a few hasLayout triggers, most of the IE issues are fixed. Just a few more to do.

UPDATE: Everything now seems to be OK in IE 6, 7 and 8. There’s a conditional stylesheet for 6 and 7, almost entirely devoted to hasLayout triggers.

One thing I know about is the empty “navigation” section at the top of archive pages when there are no “next” or “previous” pages. I’ll have to dig into the WordPress API to check out how to make that section appear only when appropriate.

Once the little niggles like that are done, it’ll be time to start work on some more extensive customisations, together with a plugin or two.

In the meantime, enjoy! - or, if it breaks horribly for you, leave a comment.

About the Picture

The photograph at the top was taken at around 4:15pm on the 11th December 2007 from the 6th floor of Yahoo! Europe’s offices on Shaftesbury Avenue in London. (I hadn’t broken in - I was contracting with them at the time.) The view looks over the rooftops of Seven Dials and Covent Garden towards Westminster; on the left is the Church of St Martin in the Fields near Trafalgar Square. Then, moving right, the light at the top of the clocktower commonly, if erroneously, called Big Ben shows that Parliament was in session at the time. A floodlit Westminster Abbey is next, contrasting sharply with the modern structure of Millbank Tower. Finally, I’m not absolutely certain, but I think the tower block at the right with the blue lights on top may be New Scotland Yard.

Still, leaving my obligatory whining aside, the number of versions and configurations patched makes it very clear that all users of Internet Explorer must install this one - and if your system isn’t supported, you really should upgrade.

What impresses me about this update is that it includes support for systems and versions so old that no web developer supports them anymore. This demonstrates that although we web devs may be able to pick and choose what we worry about through graded browser support (as do, for example, Yahoo! and the BBC), there are nonetheless software developers out there, grappling with old C or C++ code, who are doing the desperately difficult job of supporting users of older systems. The list of systems and versions they had to be sure to fix, and test, is available at Microsoft’s site: seventeen different combinations of operating system and browser version. Seventeen!

Think about fixing and testing that little lot next time you’re upset by the 3-pixel text jog ;-)

Here are the main parts (with some headers and the body omitted) of the response to a broken request for Raymond Chen’s blog - I deliberately misspelled “default” as “defult” to trigger a 404:

HTTP/1.1 302 Found
Date: Wed, 10 Dec 2008 17:46:51 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
CommunityServer: 2.1.61025.2
Location: /error-notfound.aspx?aspxerrorpath=/oldnewthing/defult.aspx
Content-Type: text/html; charset=utf-8
Content-Length: 176

So, a request for something that is not found returns 302 Found. Nice.

What happens when the browser follows the redirection to /error-notfound.aspx?aspxerrorpath=/oldnewthing/defult.aspx? This happens:

HTTP/1.1 404 Not Found
Date: Wed, 10 Dec 2008 17:46:52 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
CommunityServer: 2.1.61025.2
Content-Type: text/html; charset=utf-8
Content-Length: 11769

So, just to get this straight: when something is not found, ASP.NET returns a 302 Found response redirecting the client elsewhere. Then, when the redirect is followed, it returns a 404 Not Found response, despite the fact that this page clearly has been found, and it was the page that redirected us here that was not found.

Weird. Just plain weird.

Update: an online acquaintance (I don’t have a URL for him) has pointed me to a page on MSDN where the rationale for this behaviour is presented:

Redirect creates a new Context, Transfer does not. Redirect requires a round-trip to the browser, Transfer does not. As a result of this round-trip, Redirect rewrites the URL to reflect the location of the error page, Transfer does not.

If this seems to be an argument in favor of Transfer, it isn’t. The rationale of the ASP.NET development team is that Redirect accurately displays the URL of the custom error page…

However, at no point is it explained why displaying such an implementation detail to clients is preferable. Given that the article starts with the words:

The quality of a site should be measured not only by how well it works, but by how gracefully it fails.

it seems strange that it then recommends a technique which causes sites to fail in a singularly graceless manner.

My suggestion would be to modify your ASP.NET application configurations so that the customError capability uses the Transfer technique instead of Redirect. If that

…breaks a tenet of the design philosophy of ASP.NET…

then so be it.

But a redirect to the absolute URL of an error page? That’s just annoying. It means that I can’t try to reload the page to see if the server has recovered from whatever issues are affecting it - or, more accurately, I can try to reload, but as I’m now at the absolute URL of the error page, I just keep reloading that.

Unsurprisingly, the HTTP 1.1 standard has already provided for this kind of situation by means of the 503 Service Unavailable status code:

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay.

If the blogs.msdn.com people (who, by the way, Raymond is not responsible for) would use this status code to serve their error page for the post on Raymond’s blog, I could simply come back after a few minutes and try to reload the page, as my browser would still be at the same location.

It’s also possible that they do send this status code, but with a Location: header to cause the redirect. (The server seems to be back on its feet again now, so I can’t inspect the HTTP cycle to check.)

Either way, what they do is wrong and broken. Don’t send people somewhere else to explain a 5xx Server Error status; simply serve the explanation directly using the appropriate 5xx status code, leaving your visitors ready to try a reload when the server has recovered. Otherwise, you’ll serve a lot of 200 OK responses from your error page, most of them to people who haven’t noticed that their location bar now points there as they hit [Control | Command]-R in the hope of seeing what they originally came for.

Note: A more recent post examines this aspect of ASP.NET in greater depth, and suggests the use of a configuration option that resolves the problem.

The Council’s electoral registration form came through the door today, so I visited the web site to indicate that everything’s the same.

I now have the confirmation email.

Definition of “line” in the following examination of the content of said email: something delimited by an RFC 2822-compliant line-delimiter (see third paragraph of section 2.1), excluding empty lines (that is, lines preceded by, and containing only, such a delimiter).

Content relating to me personally: 3 lines.

Content that’s merely relating to my confirmation (including “Thank you” and such, and therefore reasonable to include): 3 lines.

Content after that stuffed with legal garbage: 15 lines.

I’m tempted to do a word count, but let’s just estimate that there are something like twenty or thirty times as many words in the legalese as there are in the actual content of the message.

And people wonder why the Internet feels slow today.

P.S. Bonus points for the fact that, if I leave the “default.aspx” off the first link, the server returns an empty page, and is apparently Tomcat, despite the fact that the actual application is running on ASP.NET.

Without default.aspx:

HTTP/1.1 200 OK
Date: Wed, 13 Aug 2008 02:22:32 GMT
Server: Apache Tomcat/4.1.12 (HTTP/1.1 Connector)
Cache-control: private
Content-Length: 0
Content-Type: text/html

With default.aspx:

HTTP/1.1 200 OK
Date: Wed, 13 Aug 2008 02:27:31 GMT
Server: WebSTAR/4.5(SSL)
Cache-Control: private
Content-Length: 71428
Content-Type: text/html; charset=utf-8

Ho hum.

The obvious question is: why was the server running a service which isn’t necessary (if it was necessary, how can they turn it off)? But this is a sidetrack question.

The important point is that the “solution” wasn’t a solution, it was a way of making the problem go away. This doesn’t work, and as a rule, the problem comes back in a much worse form.

Don’t make the mistake of thinking you’ve solved a problem by brushing it under the carpet. In the long run, it tends to ruin the carpet.

The solution is to provide a solution, not find a way of ignoring the problem.

Update 2, December 2008: It is now accepted that it is better to use top: -9999px;, as using left: would cause a scroll bar on a page with right-to-left text.

A recurring question on various mailing lists such as the Web Standards Group discussion list is “How can I hide content but still have it accessible?” This is usually asked in the context of image replacement techniques, where one might for example wish to display a heading in a fancy typeface, but still have the content accessible to users of assistive technologies such as screen reading software.

Two techniques, both reliant on CSS, tend to come up in these discussions: hiding the text by the use of display: none or visibility: hidden, and positioning the text off-screen, using absolute positioning and left: -9999px, or margin-left: -9999px.

Access Matters determined back in June 2005 that the display and visibility techniques appeared to be inaccessible to screen readers, whereas the offscreen positioning method was accessible. The full results go into more detail.

One thing that nobody seemed to have bothered to explain was just why this was the case. Inspired by yet another thread on the subject, I finally decided to do some digging; if I don’t know why I’m doing something, I can’t be sure that I should be doing it, which leads to the risk of Cargo Cult coding.

Ask the people who know

To my astonishment, a search of the Microsoft Developer Network Library quickly brought me to the explanation I sought. (I was astonished because the MSDN library search is notorious for returning swathes of irrelevant results for even the simplest search; I have heard anecdotal evidence that Microsoft’s own developers search the library using Google with the site:msdn.microsoft.com specifier.)

The library’s section on accessibility support in Internet Explorer is extensive, but the information about invisible objects told me all I needed to know. To quote:

With Internet Explorer 6 and later, the pvarState parameter of the IAccessible::get_accState property receives STATE_SYSTEM_OFFSCREEN when the object is invisible because of scrolling and receives STATE_SYSTEM_INVISIBLE when the object is invisible because its IHTMLStyle::visibility property is set to hidden, or its IHTMLStyle::display property is set to none.

Again, in English?

A screen reader doesn’t load an HTML page: the browser (usually Internet Explorer) does that. What the screen reader does is to ask IE about the content, using an API called Microsoft Active Accessibility (MSAA). MSAA allows the screen reader to interrogate the browser as to the contents of a page; the dialog, insofar as I understand it, would go something like:

Internet Explorer:

Hey, I’ve just loaded a page.

Screen reader:

Cool, what’s it got on it?

Internet Explorer:

There’s a heading, then some links, then a few paragraphs.

Screen reader:

OK; give us the heading.

Internet Explorer:

It says “Welcome to HyperGlobalMegaCorp”.

Screen reader:

Right, hang on a moment. (Speaks the given text to the user.)

… and so on; you get the general idea.

The key is that IE doesn’t just return content to be spoken in some way; it also returns information about that content. This includes information that goes by the snappy name of pvarState, and one of the aspects of this information is that it can tell the screen reader whether or not the content of the thing it’s asking about (for example, the heading in the above dialogue) is actually displayed on the screen - that is, whether it’s visible or invisible. (Note that these terms aren’t being used here in exactly the same way as they are in CSS.)

There are three ways that IE comes to regard something as being invisible:

1. It has the CSS property display set to the value none;
2. It has the CSS property visibility set to the value hidden;
3. It is in a position where the window would need to be scrolled for it to become visible.

IE further distinguishes these three forms of invisibility by dividing them into two kinds. The first two forms of invisibility are denoted by the pvarState value STATE_SYSTEM_INVISIBLE, and the final form is denoted by the value STATE_SYSTEM_OFFSCREEN.

So finally it all becomes clear: screen readers will treat content with the state STATE_SYSTEM_OFFSCREEN as being content that it should read, because it’s only invisible by virtue of not being within the visible region of the window: after all, a screen reader that required the user to scroll the window to read all of the content would be of very little value to anybody. The only reason that the content can’t actually be scrolled into view when using the off-left or off-top positioning technique is that Internet Explorer itself doesn’t support the concept of scrolling the window by a negative amount, although I believe this isn’t a limitation of the Windows scrolling mechanism per se.

If, however, the screen reader finds that the state of the content is STATE_SYSTEM_INVISIBLE it apparently concludes that it must have been concealed for a reason, and doesn’t speak it.

So there you go: use one of the offscreen methods and the screen reader will treat your content as being there; use the display or visibility method and the screen reader will discard it, meaning that this is a reliable way of concealing content from both a normal user and a screen reader user, should you have a reason to do so. But armed with the information above, you’ll at least know why you’re using whichever method you apply.

A designer?

Originally uploaded by writerus drivelus.

Last Saturday I went to the WebDD conference at Microsoft Campus, Reading. Following my standard conference procedure, I checked in, obtained coffee, and fired up my MacBook.

At this point one of the official photographers (only authorised individuals may take photos at MS) rushed over to me and asked, “Is it all right if I take a photograph of you?”

“Yeah, fine,” I replied. As he raised his camera, I asked, “Is it the Mac?” “Yes,” he said.

I’d only been at Microsoft five minutes, but the Reality Distortion Field had already cast me into a Bateman cartoon: “The Man Who Used a Macintosh on Microsoft Campus.”

(And no, I’m not a designer.)