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.gui...@gmail.com> wrote: > On Fri, Aug 10, 2012 at 8:06 PM, Erik Reppen <erik.rep...@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. >
