Many of us in the Web world are aware of the importance of standards. Those of us who follow technology may be aware of a standards war being waged worldwide by Microsoft and their XML file format (OOXML) against the OpenDocument format (ODF) used by Open Office and others. I don’t personally understand the difference, but essentially these two competing formats do almost exactly the same thing, politics aside.
Pick your winner:
- VHS versus Beta
- DVD vs. DIVX (not the one that’s around today)
- HDDVD versus BluRay
- XHTML versus HTML 5
HTML 5? No, that’s not a typo. The HTML format has been resurrected by the Web Hypertext Application Technology Working Group (predominantly players in the Web browser market, it seems to me) to accomplish the same sorts of things that we can accomplish in HTML 4 or XHTML today. I’m not sure what they hope to accomplish with canvas and article tags, ins and del tags, progress and meter tags, and more that we can’t accomplish today through reasonable means.
The section and nav tags seem to have some sense about them. Then again, I did read up on the XHTML 2 draft a while back, and sections and unnumbered headers (h tags) seemed to make a lot of sense in ways that numbered headers never did.
One direction that could have promise is the improvement of forms on the browser-side. However, the security side of me worries that this could open up a new class of Web vulnerabilities on the sever side of the equation, when we start to assume that the browser will be doing our error-checking for us and begin to trust it. How many of us want to do error checking twice, once in the display code and again in the application logic? Are we finally going to get an input type of date? I guess we’ll have to wait and see.
I think this new draft of HTML is a portent that we’re about to miss out on the real promise of XHTML. How many content management systems out there use XSLT to transfer data from some intermediary format to the XHTML pages those CMSes produce?
How much easier would portlet development be if we could submit a SQL query to pull XML data from a student out of our ERP system and specify an XSLT to convert it to HTML, instead of having to code every little step in Java? Perhaps this isn’t strictly going away.
In some ways, I think we’re fully expecting HTML to continue to be vaguely XML-y, so perhaps all hope is not lost. In other ways, I think we’re giving up – or at least the Web browser makers are giving up on us.
Some of the commentary I’ve seen is that HTML 5 is looking to handle bad markup in better ways that XHTML or HTML 4 did. I think this is the ultimate problem. How many of us actually check our conformance to Web standards every time we post a new page? Every time we write an application?
I fear that this divided future is the price we’re going to pay for our own inability to write conforming (X)HTML. I am reminded of an old browser evaluation that looked at different Web pages, and the Web page with the fewest problems across all browsers was the only one in the test that had valid HTML markup.
In some ways, I think standards are a losing battle. Standards will always be trumped by what works. In many ways, we’re in the marketing business. If our site is technically correct but doesn’t sell people on our respective colleges and universities, we run the real risk of going out of business. Unfortunately, we can’t always have that warm-n-fuzzy feeling we get when we do the right thing.
I am not afraid of progress. I think I’m tired of futile conflict. And I refuse to make investment in a technology until there is a clear victor for the future. (Pay no attention to the TiVo in my living room.)
Perhaps someone else should decide on the future of HTML, and not worry about it. Meanwhile, I’ve got a Web site to run. I wish I knew what Web language I would be planning to use tomorrow.
– Steve Lewis