At the site Rebuilding the Web there is plenty of content questioning the current process and chaos around HTML5 and related specs. A piece that drew my attention echoes the dust-ups I have had over HTML5 (and XHTML2) and whether it's a good idea to push it so hard when it isn't even an approved spec. Check out Is it irresponsible to advocate using HTML5 before it is ready? to see some interesting examples. If you are new to the developments in HTML5, read my post The Latest on HTML5 from last week.
Given how few people actually code HTML by hand, and given how so many web sites are powered by some sort of CMS, WYSIWYG editors have become a de facto truth for how most web page content is marked up (except this one, of course). As a result, HTML Tidy (originally a W3C project, the same standards body working on HTML5) has been incorporated into many editors to help remove and clean terrible, invalid markup.
The problem is HTML5 is so lax in its requirements, as compared to previous versions of HTML, that HTMLTidy can be more of a hindrance. For example, the HTML5 doctype is so truncated that HTMLTidy sees it as an error and sets it to HTML3.2. It is now legal to wrap block level elements in anchors, something that a WYSIWYG editor (like CKEditor or TinyMCE) would immediately try to re-nest, resulting in a potentially broken hyperlink and extra elements to satisfy the nesting.
With the examples in the article, I certainly cannot foist an HTML5 site on my clients. It would render their WYSIWYG editor potentially dangerous to their page content. And for those clients who can access and manage the templates used by the CMS, we run the risk of making their existing editors, or even HTML knowledge, useless.
It is far too soon to advocate HTML5 for client projects or real-world applications. We need a final spec that is free of infighting among its authors, we need browsers to support the core elements, and we need WYSIWYG editors that can understand this new syntax without the need to retrain our users.