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

[Tab Atkins Jr.]

On Fri, Aug 10, 2012 at 5:02 PM, Erik Reppen <erik.reppen at gmail.com> wrote:
> Browser vendor politics I can understand but if we're going to talk about
> what "history shows" about people like myself suggesting features we can't
> actually support I'd like to see some studies that contradict the
> experiences I've had as a web ui developer for the last five years.

I don't wish to spend the time to dig up the studies showing that 95%
or so of XML served as text/html is invalid XML, but others probably
have the links easily at hand.

> Everybody seems on board with providing a JavaScript strict mode. How is
> this any different? Do people blame the vendors when vars they try to define
> without a var keyword break their strict-mode code? Do we fret about all the
> js out there that's not written in strict mode?

JS is a substantially different story, because you virtually never
display a page which runs Javascript code from many arbitrary users of
the website.  As well, JS is commonly written only by the more
advanced maintainers of a given website.  Finally, JS errors are
localized to the scripts in which they are located.

This is substantially different from HTML, which is commonly composed
of lots of user comments which are barely, if at all, escaped for
security.  As well, HTML is commonly written by a number of users of
varying skill levels in a given site; in my previous experience as a
web dev, for example, people from the advertising department often
wrote snippets of HTML into pages, though their skills were far below
mine.  Finally, HTML doesn't have the same localizing barriers as JS
does with <script> - an error anywhere in the page would kill the
entire page, not just the segment that contains the error, because
there's no good way to determin what that segment *is*.

> And HTML5 has found the key to eliminating the political issue, I should
> think. Don't just worry about the rules for when the authors get it right.
> Explicitly spell out the rules for how to handle it when they get it wrong.
> How can you blame the browser for strict mode face plants when every modern
> browser including IE goes about face-planting in exactly the same way?
>
> Sure, I could integrate in-editor validation into my process, but why add to
> bloat to any number of tools I might be  using for any number of different
> stacks when we had something I know worked for a lot of developers who were
> all as confused as I was when people inexplicably started shouting about
> XHTML strict's "failure" from the rooftops.
>
> Is there some unspoken concern here? If there is, I'll shut up and try to
> find out what it is through other means but I really don't see the logic in
> not having some strict provision for authors who want it. How hard is it to
> plug in an XML validator and rip out the namespace bits if that's not
> something we want to deal with just yet and propose a set of behaviors for
> when your HTML5 isn't compliant with a stricter syntax?
>
> Because yes, these bugs can be kinda nasty when you don't think to check to
> make sure your HTML is well-formed and it's the kind of stuff that can
> easily slide into production as difficult-to-diagnose edge-cases. Believe
> me. Front-liner here. It's an issue. Markup is where presentation, behavior,
> content, client-side, and server-side meet. I'm comfortable with letting
> people embrace their own philosophies but I like my markup to be done right
> in the first place and visible breakage or at least browser console error
> messages is the easiest and most obvious way to discover that it isn't. And
> I developed that philosophy from my experience moving from less strict to
> strict markup, not just toeing some weird technorati political line or
> zeitgeist.

I attempted to explain it very plainly in my last email.  There is no
"conspiracy" or anything unobvious going on.  It's a very simple
equation: being strict is sometimes of minor benefit to authors, but
it's commonly very bad for users, and users most often blame the
*browsers* for not displaying the page rather than the authors for
writing invalid code.  Thus, it's simply not in the browsers' or the
users' best interests to be strict.  It *may* be in the authors' best
interests *sometimes*, but definitely not all of the time, and in any
case, the needs of the user trump those of the author.

Thus, we have lax parsing with error-recovery, and will likely always have it.

~TJ