To view parent comment, click here.
To read all comments associated with this story, please click here.
HTML5 actually creates specifications of things people were already doing. And HTML5 does it in a backwardcompatible way, with easy fallback to a JavaScript shim.
The churn is good, XHTML or an incompatible XHTML2 not so much. I would rather have HTML with the HTML5-parser specification as it is now. People will always create sloppy code or just mistakes in the syntax. It is good to specify how the browsers should all interpret those mistakes.
Pages should just be displayed. Unlike XML (XHTML) which found one problem and just trows it's hands up and says do it yourself.
The bad things are that HTML5 forms specifications and implementations are actually so disappointing: http://vimeo.com/33712504
It looked like it could have made life so much easier but they seemed to have messed it up. :-(
I know this.
No it isn't. Churn is never good.
There was nothing wrong with XHTML, CSS 3.0 and the New JS APIs were the improvement IMO. Having a few extra semantic elements, while nice tbh wasn't necessary.
Or they could just run their code through a validator? All it does is encourage sloppy code. Most complaints about IE is because it was actually doing things properly.
No the browser still displays it, it just renders it as tag soup unless you set the mime type as text/xml (I think).





Member since:
2009-08-18
The thing is a couple of years ago, we were in the position where we could build nice XHTML apps. Now because of HTML 5 and because everyone is chasing the new "Shiny Shiny", we are in another state of Churn yet again.
The only really positive thing to come out of this are the Geolocation APIs, but they seem to work differently on pretty much every browser (BTW the way IE9's impletation works is how I think it should work, Mozilla does a best guess based on IP).