XHTML 2 vs. HTML 5: Real World Matters
Some people like to say that choice is a good thing... It is when personal taste and preference are pre-dominant factors in that choice. When trying to maintain consistency and standards? Then, choice only leads to bifurcation, double the work, and a poor experience for all. When establishing a superset, what happens when a new feature or spec is released, backwards compatibility is preserved through keeping the previous feature set. You can use the new features, but your old pages that haven't been updated still work. It is why the web could, more or less easily, migrate from a "tabled" world of content and presentation to a "CSSed" world of separation between content and presentation. Because of intermingling a more or less functional web could be extended to all, across browsers and across versions. There is good in here even though it resulted in a confused jumble for a period of time. With the advent of time and an impetus for standards, people adopted the philosophies behind CSS. In turn, they gradually started to use XHTML, a superset of HTML 4, to re-enforce their beliefs that content and presentation should no longer be as one.
Then came the browser wars in implementation, a one-up-man-ship as each browser attempted to implement the CSS specification the quickest and beat the mythical beasts of the "Acid Test". Reminiscent of the megahertz battles at the end of the 20th century, browsers vied for the web development communities' favor in adopting the CSS, CSS 2 and later CSS 3 spec. the quickest. Through all of this, Internet Explorer, the browser with the largest market share, stood oblivious and distant. It had the share and, thanks to the benefits of backwards compatibility, its users rarely had to visit a "broken" web, thus keeping them entrenched in what they had and knew.
As the CSS specification went through rapid ratification and implementation, the HTML document, the markup of the web itself, stood stagnant. It worked, whether in XHTML or HTML 4 format, and there stood little reason to modify it. Then came the movement of HTML 5 and XHTML 2.0, both attempts to learn from the problems of XHTML/HTML and move the web's markup in particular directions. They both had different goals, ideals and backwards compatibility, respectively, and they both have different backers and neither have achieved ratification status. The problem is that if they both reach ratification status, and here we assume at the same time, both the web's users, its designers, and its implementers (our browser vendors) will have a large and exponentially insurmountable problem on their hands. As has been visible through the CSS debacle, implementing standards has never been a standard amongst browsers. There is a right and wrong in the rendering model, but there are also a number of vagaries. Compounding this inherent problem by adding two new specifications for the browsers will only result in a broken web. What will follow is a stagnation of real innovation and even a move towards conservatism ala the days of Internet Explorer 6 and the advent of "tableless" sites.
Without having to read the specific recommendations below what do I suggest? Merge the two competing standards and relent on ideals! In the reality of the web both the designer and the user have no place for ideals.
Too many moving parts
The new XHTML 2 standard is a singular beast that requires the new superset of HTML Forms, XForms, and XML Events to replace many of the current implementations for forms and on-click events. In this way not only is there a separation of content and presentation, there is a third separation brought in to the mix, that of programmability and content. A benefit of the new XML Events is the ability to have greater and better programmatic control over the user interaction. The problem however is that to apply a full and working XHTML 2 implementation, all of these parts are necessary. Implementing all of this requires a considerable amount of time and can only delay acceptance. Browsers can default to accepting an "onclick" variable for JavaScript, but that then breaks the XHTML 2 validator. In sticking closely to its ideal, XHTML 2 eschews compatibility, a fundamental building block of the web.
HTML 5 on the other hand implements its variety of moving parts through a whole host of new and content specific "DIVs". Gone are the general purpose "DIV" with a class or an id. This is a good thing, but keeping track of a whole host of new HTML tags and adding indiscriminately to the tag soup that is HTML is only an invitation for even more problems and an even less standardized web. The bigger question is do we really need even more sectioning and HTML to fragment the page? Who does the benefit? Certainly not the reader that will find all of this tag soup extricated through CSS. Screen readers will surely benefit to some degree... But is that much abstraction really a good thing for those who have to listen to a mechanical voice? Maybe instead of creating new tags, the HTML 5 group can usurp the idea of using "role". This moves sectioning away from being part of the tag soup, which I feel is unnecessary, and into the meta-data of the content, which it really is. To apply this to XHTML 2, I feel that the new "nl" tag is a waste as well.
Adding to the newly created HTML structure are predefined class names, an idea so bad that I feel it unnecessary to expound on its stupidity. First of all, we now are going to have to make a cheat sheet for every single predefined class name that the HTML 5 working group decides to push away into their DTD. Great... And how do I know if I just used a class name that I shouldn't have? Well there really is no error scheme in the browser, so I won't! But it can only get worse when you think about multiple class names. What does "site copyright text" and "link copyright text" mean? How do I interpret these as a browser or a user? Usurping names and variables in these regions is a particularly bad idea.
Does the past matter?
The other problem our two competing standards are facing is what to do with compatibility? HTML 5 takes an all-inclusive approach. Supporting the HTML 5 spec is as simple as changing the "DOCTYPE". XHTML 2, on the other hand, has loftier goals in its sights. In contrast, a number of HTML elements are no longer valid and a number of elements have been modified accordingly.
Let us start with what is no longer valid. XHTML 2 no longer supports the "font" tag. I want all of you to start clapping now.... But HTML 5 supports the "font" tag, you can still keep clapping... But HTML 5 only supports the "font" tag when you use a What You See Is What You Get (WYSIWYG) editor and the appropriate meta tag is provided. Okay, you can also stop clapping and start booing incessantly. First of all, support or don't support. The number of malformed documents on the Internet should demonstrate that such nebulous standards are only going to be abused and re-abused. Secondly, why exactly is there a separate meta-declaration for a WYSIWYG editor? The collective Internet jumped up in protest at Microsoft's decision to use rendering engine choices in the META tag with the release of IE8. How exactly can this be a good idea here? Why exactly is the browser expected to parse META tag text to jump through the DTD? In dynamic CMS generated pages where the user can freely paste code that includes the "font" tag... Does the designer have to always state that the page is WYSIWYG designed just anticipating for the worst? The "font" tag is a moving target that HTML 5 burdens on the developer and the designer. Doing away with it might just be the best solution.
On the other hand, XHTML 2's decision to rend the basic tags of "b", "i", "small", and numbered headings from the user is a potentially disastrous idea. This is especially true for the numbered headings which serve a valuable purpose for the novice user, a staple as a content editor in a CMS used by any organization. The new "sectioning" that XHTML 2 introduces, and that HTML 5 does as well to a smaller degree, is just another in a string of decisions that will result in markup overload on the content. Part of the overriding principles of both XHTML 2 and HTML 5 should be to move out of content's way and let it shine through, while the CSS allows the design to express itself. Burdening the content contributor and the browser by having to read through a long recursive list of "section" tags to figure out the "h" value is a bad decision. Linear numbered headings serve a valuable purpose. Not every document needs to be structured under descending headings. Sometimes the heading is used to denote importance. Most importantly, it is much easier for the user to understand how numbered headings work in the document, as its linearity breeds simplicity. Lastly, I don't think the XHTML 2 working group has thought about how a user with a WYSIWYG editor will be able to decipher and construct this new non-linear heading construct.
Time to reach beyond and adopt the new
One of the best ideas in XHTML 2 is to abstract away the redundant "a" tag. Now an "href" can be attached to any tag, as it should be. Removing extraneous markup and letting the content shine through should be the overriding goal of both working groups. Listen, I get that having an "href" on any element is potentially difficult to work around. You can have an "href" on that DIV, and then on the paragraph in that DIV. How does the browser interpret both? Maybe the choice is not to have it on such encompassing block level elements. Maybe there is a different way to work around this issue... Be that as it may, this is a real improvement that can substantially change and build upon the current structure of the web. Imagine no longer having to wrap text in list elements in an "a" tag. Now the "li" itself can get an "href" and with the smaller file size that comes through everyone can breathe a sigh of relief. XHTML 2 helps simplify some more by eliminating "pre" and "code" for the simpler "blockquote". I couldn't agree more. The removal of "img" with the ability to add "src" to any element makes me smile once again. To create a graphical navigation, a whole lot of content in the CSS can be abandoned through the judicious use of "href" and "src". On the other hand, I do wish that the XHTML 2 working group would keep the "img" tag working the way it does now. It might lead to less confusion.
In HTML 5 there are a lot less new elements and features to get excited about. In fact, HTML 5 could do a lot of good by adopting some of XHTML 2's new ideas. In particular, the "href" idea needs to be adopted wholesale. The addition of the "dialog" element is definitely good, as well as the "figure" and "m" (for highlighting) element. HTML 5's use of "rel" to specify the type of link will make things a lot easier for the SEO and for users with text-to-speech software. In all however, HTML 5 seems to have eschewed innovation for compatibility and the changes that it brings along are questionable in many respects.
Conclusion
The thing is that sequestered by themselves, both the XHTML 2 and HTML 5 working group are getting a lot less done and most of it at the expensive of the user. Yes, HTML 5 has gotten browser vendor support, but that doesn't mean a correct implementation is guaranteed. Moreover, I don't think the best development can come from browser vendors whose sights are less narrow than the those writing the specification. I don't distrust them, I just question their track record. The arrival of browser specific declarations in the CSS has only made things more complex and significantly less friendly. Moreover, the constant needs for backwards compatibility has lead to an outlook that is forcing the HTML 5 group to walk backwards into the future.
Then there is what both XHTML 2 and HTML 5 can learn. Content does not and should not be burdened by the markup. The markup is not content...
- Keep it simple
- Keep it clean
- Keep it accessible
- Keep it working
At any number of points both the working groups have tended to ignore or trample on all of these guidelines. What is being produced is questionably in the best interests of the future of the Internet's markup. The solution is working together and abandoning the dogma on both sides, whether it be a dedication to an ideal, or a dedication to the past. People need simplicity and markup needs to focus on working best with content and content contributors. If the latter can't work with that, there is always the old DOCTYPE, always the old DTD, for them to call upon in their hour of need.
