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

[Ian Hickson]

On Fri, 10 Aug 2012, Erik Reppen wrote:
>
> 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

This is incorrect. The philosophy is to have strict rules about how to 
write content -- e.g. in the form of the strict content model 
descriptions, the "Writing HTML documents" syntax section, the obsoletion 
of many legacy parts of the language (like <font>), and other authoring 
conformance criteria -- and then to have equally strict rules for browsers 
and other user agents that defines what exactly should happen when the 
first set of rules are ignored and broken (usually to ignore the broken 
content and not try to fix the problem, but sometimes, usually for legacy 
reasons, to make an attempt at "do what I mean").


> 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.

Use a validator. :-) That should help catch syntax errors and content 
model errors, at least.


> 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?

I don't really understand how IE8 is relevant here. Can you elaborate? How 
does it help?


> 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?

Browsers are certainly allowed to report syntax errors in their consoles. 
Indeed I would encourage it.


> And if we were able to set such rules, wouldn't it be less work to parse?

You have to catch the error either way, whether it's to then abort, or to 
then ignore it. It's the same amount of work. For some errors, e.g. 
out-of-range errors or content model errors, it can actually be 
significantly _more_ work to detect the error than to ignore it.


> 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)?

It's not at all difficult. The spec allows it today. The question is 
really how hard would it be to convince browsers to implement it. :-)


On Fri, 10 Aug 2012, Erik Reppen wrote:
> 
> I think there's a legit need for a version or some kind of mode for 
> HTML5 that assumes you're a pro and breaks visibly or throws an error 
> when you've done something wrong.

If you're a pro, use a validator.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'