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

[Erik Reppen]

Thanks Hugh. I had mistakenly been thinking of XHTML5 as something that
never happened rather than merely HTML5 served as XML which hadn't really
occurred to me as being a viable option. I look forward to messing with
this. This is precisely what I wanted to be able to do.

On Fri, Aug 10, 2012 at 7:28 PM, Hugh Guiney <hugh.guiney at gmail.com> wrote:

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