[thelist] What is wrong with this site?

Simon Willison cs1spw at bath.ac.uk
Mon Aug 18 18:27:31 CDT 2003


James Aylard wrote:
>     Why should the average user see a blank window simply because a
> server-side script failed to write a closing table tag? Why should the
> average user see a stream of unintelligible html code simply because the
> server isn't set to generate the correct content-type header? Why should the
> user be confronted with a confusing "404 Error" page, having no clue what it
> means? Microsoft's answer is: they shouldn't. And IE is a product of that
> assumption.

See my reply to Bill Haenel, where I back-pedalled considerably. In the 
heat of the moment I had completely failed to acknowledge IE's position 
as a tool for the user first, a development tool second. I was wrong. I 
still think that fixing dumb developer errors can be taken too far, and 
when it is it becomes anti-competitive (deliberate or not).

>     So, we're back to developer laziness. There are numerous tools out there
> in which to test a site and to verify the validity of its code. But since
> many developers, according to your own argument, never bother to rigorously
> test their sites, Microsoft has decided that the hapless end user should not
> be the one to shoulder the burden of some of the more common careless coding
> errors.

Here's the catch-22: if browsers had never started auto-fixing things, 
they wouldn't have to compensate for careless coding errors as lazy 
developers would have spotted them (nothing makes you fix your page 
faster than it not loading when you go to check it out in your browser). 
As I've already pointed out though, the damage is already done and 
there's no way of going back.

>     Meaningless. It is the complexity of complying with web standards that
> makes the production of a modern browser so incredibly daunting, not
> "reverse-engineering" IE's so-called fixes.

I completely disagree here. Implementing W3C standards is daunting, but 
replicating IE's undocumented fixes verges on the impossible. You would 
be right to blame this on developer laziness, but you would also be 
right to blame it on browser vendors for allowing that laziness to go 
unpunished. At least propretary "improvements" to existing standards as 
fosited by Netscape and Microsoft during the browser wars were logically 
specified and well documented - new browsers could choose to implement 
them or ignore them at will, and would at least have documentation to 
work from. There's no documentation for what IE does when it encounters 
garbage markup, so if you want your new browser to render that garbage 
the way the author intended you haven't even a fighting chance.

I'm going to back away from this discussion before it turns in to one of 
those threads that goes on for days (talk about a can of worms!), but 
I'm happy to concede that my original rant missed some important points. 
I do think though that this issue highlights an interesting problem that 
arises when the development tool and the end user tool are one and the same.

Cheers,

Simon Willison



More information about the thelist mailing list