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

[Tab Atkins Jr.]

On Fri, Aug 10, 2012 at 3:29 PM, Erik Reppen <erik.reppen at gmail.com> wrote:
> This confuses me. Why does it matter that other documents wouldn't work if
> you changed the parsing rules they were defined with to stricter versions?
> As far as backwards compatibility, if a strict-defined set of HTML would
> also work in a less strict context, what could it possibly matter? It's only
> the author's problem to maintain (or switch to a more forgiving mode) and
> backwards compatibility isn't broken if the same client 500 years from now
> uses the same general HTML mode for both.
>
> 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. Back in the day nobody ever forced authors who didn't
> know what they're doing to use doctypes they were too sloppy to handle. I
> wasn't aware of any plan to discontinue non-XHTML doctypes. How everybody
> started thinking of it as a battle for one doctype to rule them all makes no
> sense to me but I'm fine with one doctype. I just want something that works
> in regular HTML5 but that will break in some kind of a strict mode when
> XML-formatting rules aren't adhered to. You pick degrees of strictness based
> on what works for you. I don't really see a dealbreaking issue here. Why
> can't we all have it the way we want it?
>
> As somebody who deals with some pretty complex UI where the HTML and CSS are
> concerned it's a  problem when things in the rendering context give no
> indication of breakage, while in the DOM they are in fact getting tripped
> up. Sure, I can validate and swap out doctypes or just keep running stuff in
> IE8 to see if it breaks until I actually start using HTML5-only tags but
> this is kind of awkward and suggests something forward-thinking design could
> address don't you think?

As I said, years of evidence have provided strong evidence that a
large majority of authors cannot guarantee that their pages are valid
all of the time.  This covers both authoring-time validity and
validity after including user comments or the like.

If you want a mode that guarantees validity, that already exists -
it's called "put a validator into your workflow".  Many popular text
editors offer plugins that validate your markup as you go, as well.

The problem with breaking visibly is that it doesn't punish authors,
it punishes *users*, who overwhelmingly blame the browser rather than
the site author when the site won't display for whatever reason.
There's no *benefit* to a browser for doing this; it's much more in
their interest to continue doing error-recovery, because, again,
history suggests very strongly that most authors *who theoretically
want strict parsing* can't actually satisfy the constrains they ask
for.  It's simply better for users to always do soft error-recovery,
no matter what the author claims they want.

~TJ