[whatwg] Wasn't there going to be a strict spec?

Erik Reppen erik.reppen at gmail.com
Fri Aug 10 12:45:18 PDT 2012


My understanding of the general philosophy of HTML5 on the matter of
malformed HTML is that it's better to define specific rules concerning
breakage rather than overly strict rules about how to do it right in the
first place but this is really starting to create pain-points in
development.

Modern browsers are so good at hiding breakage in rendering now that I
sometimes run into things that are just nuking the DOM-node structure on
the JS-side of things while everything looks hunky-dorey in rendering and
no errors are being thrown.

It's like the HTML equivalent of wrapping every function in an empty
try/catch statement. For the last year or so I've started using IE8 as my
HTML canary when I run into weird problems and I'm not the only dev I've
heard of doing this. But what happens when we're no longer supporting IE8
and using tags that it doesn't recognize?

Why can't we set stricter rules that cause rendering to cease or at least a
non-interpreter-halting error to be thrown by browsers when the HTML is
broken from a nesting/XML-strict-tag-closing perspective if we want? Until
most of the vendors started lumping XHTML Strict 1.0 into a general
"standards" mode that basically worked the same for any declared doctype, I
thought it was an excellent feature from a development perspective to just
let bad XML syntax break the page.

And if we were able to set such rules, wouldn't it be less work to parse?
How difficult would it be to add some sort of opt-in strict mode for HTML5
that didn't require juggling of doctypes (since that seems to be what the
vendors want)?


More information about the whatwg mailing list