Or are we to walk away from one of the founding principles of HTML5, that authors deliver confromant code to the browsers?

That is not one of the founding principles of HTMLn, at least for any n≤5.€

If wishes were horses, beggars would ride.

Your negativity produces zero results – be a man and provide some constructive option to further the discussion, rather than simply deriding me for wanting better than what we have today.

More generally, the idea that, if the web is to serve as an application platform, browsers should throw parse errors, just as a C-compiler would, with nonconforming input, is a complete non sequitur.

Stick with (as Mark paraphrased) “Screw the sighted people.” That, at least, bears some relation to your premise, and is not a complete non sequitur.

It also however solidifies my comment, that should draconian error handling be the norm, Word Pres would have caught the error themselves before releasing their tool, and the web would have that many more conformant websites because of it – which can only be a good thing, right?

The other thing Jacques is this: if not draconian error handling, then what? What price non-conformance? Plenty of people have taken me to task for daring to suggest such a radical stance, but not one single respondent has proposed an alternative. Remember, I am talking about a new element here: <canvas> which now insists via the specification that fallback content MUST exist. For accessibility considerations, this is critical. How do we then ensure that this requirement is fulfilled? I am very open to other suggestions, but to simply suggest that my idea is unworkable without suggesting an alternative is hardly productive to the discussion, and leaves you simply as a detractor on the sidelines without a valid contribution to make.

But again, thanks for being draconian enough to point out the XHTML errors in my blog – I guess code validation and conformance *IS* important…

Teh Funny!

Especially on an “XHTML” page that is neither well-formed, nor valid.

Your detractor’s viscosity, apparently, really did preclude a full appreciation of your point of view. Thanks for clarifying!

Now we’re in an entirely different world. The notion that HTML5 is to become “A vocabulary and associated APIs for HTML and XHTML” means that we’re moving far beyond a simple markup language and now into a platform for creating a much richer experience. It would appear that those who have reacted so sharply to your proposal are still looking at HTML5 as only a markup language.

Surprisingly, a number of those who’ve attacked you are developers who themselves would obviously be aware of the consequences for things as simple as an unescaped special character or missing semi-colon at the end of a line. I personally don’t see how your proposal that the document fail is any different than if a PHP script fail or if a Java program failed to compile due to such simple errors.

Is your proposal going to gain any legs? I doubt it. Browser manufacturers are unlikely to suddenly “fail” the poorly written documents of gazillions of websites out there. Either way, I already accept it as my responsibility to get it right anyway, so you won’t see me crying in my beer if this became reality.