FlexCar, the beloved car sharing program, set up a nifty web-based reservation system several months ago. The site was pretty slick and worked great. One of the site's more important tables, a graph showing what times cars are available, didn't render quite right in some browsers, notably Mozilla and Safari. But the site was still usable in those browsers, and even if you couldn't see the table, the site still indicated when the car you're reserving isn't available for the time you're requesting. It's such a simple table that I just assumed they'd fix it within weeks of the site launch, and didn't think much of it.

Months later, FlexCar.com responded to complaints (I assume) of this table not rendering properly in some browsers by blocking all non-Internet Explorer browsers from the reservation system. I was surprised by this reaction considering the quality of the rest of the site implementation. Very 1999! So I wrote a letter to FlexCar, insisting that the problem is only with that one table/frame (as far as I could tell), is easy to fix, and does not warrant alienating up to 10% of their users to avoid fixing.

FlexCar recently responded to complaints like mine in their monthly newsletter, sent to all members:

Web Reservation System Requirements
We have received many questions about the support for browsers and operating systems. To clear up any confusion, below are the browsers and operating systems we support.

System requirements: IE 5.5 and 6.0 for Windows OS, and IE 5.2.3 for Mac OS X.

Initially our hope was that if we followed open Internet standards (promulgated by the World Wide Web Consortium, or W3C), we could expect the reservation system to work well under all major browsers. Therefore, we used open standards and avoided proprietary ones.

But we kept running into roadblocks. Unlike an informational Website that simply displays text and graphics, the reservation system is a Web-based software application that includes complex, interactive features (such as the time-selection grid) that require functionality that is not available in all browsers.

The fact is, there is still no browser that fully supports the W3C standards. There are browsers that are substantially "compliant" within the particular features they support, but each publisher picks and chooses which items (functions, events, CSS attributes, etc.) that its browser will support. And sometimes even supposedly "compliant" features behave differently among browsers (even between the Mac and Windows versions of Internet Explorer!). We found that in order to make the system work, we had to use W3C features that were not supported by all browsers, and in a couple of cases we had to use browser-specific features that are outside the W3C standards.

We are working on making the system compatible with more browsers, though we unfortunately can't provide specific dates yet. We will keep you up to date via FlexNotes.

I'm mostly just impressed that they felt it necessary to describe the web developer's plight in such detail in their newsletter. I still believe the problem is pretty easy to fix (though I admit I haven't had time to donate a fix of my own), and the exasperated blame-the-browsers tone of the article is disheartening. But I can imagine the resource constraints and political machinations that led to the browser blocking decision. I'm willing to take their word for it that they're working on fixing the few remaining design bugs and will eventually unblock browsers, considering that it's very much in line with their stated intentions toward designing for web standards and FlexCar's overall philosophy of accessibility and empowerment. But until the table is fixed and browsers are unblocked, it's a dark spot on an otherwise excellent web site.