- From: Hugh Guiney <hugh.guiney@gmail.com>
- Date: Fri, 10 Aug 2012 20:28:48 -0400
- To: Erik Reppen <erik.reppen@gmail.com>
- Cc: whatwg@lists.whatwg.org, "Tab Atkins Jr." <jackalmage@gmail.com>
On Fri, Aug 10, 2012 at 8:06 PM, Erik Reppen <erik.reppen@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.
Received on Saturday, 11 August 2012 00:29:39 UTC