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.

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.

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.

This post is now available in Belorussian provided by http://www.fatcow.com/ – many thanks for that!

It’s back! BarCamp London 2 will be hosted by BT on February 17th – 18th. Check out the BarCamp site (above) for signup details.

I’ve got my place, and now have to decide what subject to present about. One thing I’m certain of: I’m not going to leave it until the last minute this time. I missed a lot of good stuff at the last BCL because I was tucked away in a spare office, frantically hacking together a demo to illustrate my points about underused aspects of HTTP. This time, I’ll be ready.

Already up and running is the Backnetwork. This is the same system that Madgex developed for d.Construct 2006 (Glenn Jones of Madgex is giving a presentation on Microformats), and proved itself to be an excellent system for keeping track of contacts and following the general Flickr and blogging buzz around the event.

See you there, if my car has been healed by then. (I dread to think what the train would cost.) the car having been healed through the miracle of a few hundred pounds. (Broken trailing arm, whatever one of those is.)

javascript:alert(document.compatMode);

which will pop up a box stating either “BackCompat” for Quirks mode, or “CSS1Compat” for Strict mode.

If you’re using Firefox and have the Bookmarks toolbar visible, you can drag the following link on to it to create a handy little button you can use to check which rendering mode the browser is in on any page you visit. In Internet Explorer, right-click on the link and select “Add to Favorites…” to achieve the same thing. (You’ll get a warning that the link “may not be safe”; at that point you have to decide how much you trust me. Believe me, it’s safe.)
Rendering mode

I find this tremendously useful for doing checks on pages, particularly when editing pages by hand, where a simple typo might throw a page into Quirks mode, with resultant frustration as CSS which previously worked suddenly goes completely to pot.

(Note that the “CSS1Compat” actually means “CSS2Compat” in browsers with support for CSS 2.1.)

Oh, and it only works on XPSP2; bet you wish you hadn’t shelled out for Windows Server 2003 now.