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

[Hugh Guiney]

On Fri, Aug 10, 2012 at 8:06 PM, Erik Reppen <erik.reppen at gmail.com> wrote:
> Sorry if this double-posted but I think I forgot to CC the list.
>
> 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.
>
> 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?
>
> 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.

There's nothing stopping you from writing XHTML5. This is what I do
for exactly the reasons you describe. If you write polyglot documents,
you can use application/xhtml+xml in development, serve text/html in
production and still sleep at night. Hell, these days you can even
serve application/xhtml+xml in production if IE < 9 isn't a
significant market segment for you.