RE: Comments on HTML WG face to face meetings in France Oct 08

> -----Original Message-----
> From: [] On
> Behalf Of Jonas Sicking
> Sent: Friday, November 14, 2008 9:52 PM
> To: Henry S. Thompson
> Cc:; Dean Edridge; public-html; www-
> Subject: Re: Comments on HTML WG face to face meetings in France Oct 08
> Several people has asked for a spec without error handling. I'm not
> sure why defining error handling is considered a bad thing. Is it
> because people are worried that by defining error handling people will
> rely on it, whereas people shouldn't rely on undefined behavior so if
> we don't define error handling then people won't rely on it? Or is
> there some other reason to leave out error handling from a
> specification?

I agree with the idea that defining error handling (especially one which
tries to Perl-ishly "do what you mean, not what you say") does encourage
"bad behavior". At the same time, differences in error handling amongst
browsers are a major source of the Web's issues. Why? Because, despite its
grammatical simplicity, HTML is apparently so difficult to produce that only
a small minority of HTML documents are valid. Therefore, in this case, I
believe that defining error handling so that broken pages break the same
across browsers is a better choice than having authors cranking out bad code
and then blaming a browser for being "non-compliant" just because their code
broke differently in it than their favorite browser. :(

> My experience is that a lot of people end up relying on undefined
> behavior, unintentionally or not. Additionally I think that extremely
> few people are going to check their documents against the spec, but
> rather against other documentation and other tools.

Exactly my stance as well!

> I think the HTML4 validator at has done
> worlds more than the HTML4 specification for increasing the quality of
> HTML documents on the web.

I'd agree with that as well.


Received on Saturday, 15 November 2008 04:20:07 UTC