posted by Matt Ward on Aug 29, 2010.
In this article, I will be offering my own perspective on HTML5, my concerns about its openness in terms for formatting, and the benefits of XML syntax. All of this will bring us to the simple formulation of an (x)HTML5 methodology for readable, well written code as we move forward.
On Friday, I opened up my mailbox and was pretty stoked to find that my copy of HTML5 for Web Designers by Jeremy Keith had finally arrived, just over two weeks after having ordered it (pretty good coming from the U.S. to Canada). I immediately sat down and started reading it, and finished it up yesterday. There’s a lot of really great material packed into those few short pages and I’m not going to try to dissect it all here.
Instead, I want to consider just one important aspect of this new HTML5 technology: the form of the code.
Prior to HTML5, the evolution of markup for the web had started taking its lead from XML (extensible markup language), which, though it is infinitely extensible through user defined tags, is also extremely and rigidly structured. So, after HTML 4.01, we had XHTML 1.0 which was identical to HTML 4.01 in terms of the tags that it supported, but which instituted an XML syntax, attempting to remove some of the looseness that tended to permeate different documents across the web.
Now, for XHTML to be considered valid, the tags all had to be in lower case, all tags had to be closed (according to the order in which they were opened) and all attributes value had to be contained in proper quotation marks. From my perspective, the benefits of this were several:
- Better readability – When I first started to learn HTML, writing it all in uppercase was a popular coding trend—to the point where I actually thought that that was the way it had to be done. Once I learned the error of that assumption and started coding my HTML in lowercase, everything became so much easier to read.
- Better structure – A stricter XML structure infuses a certain, inherent logic into the document, especially when it comes to block level elements. Though it would likely never have been considered a good practice to close tags in anything other than the relative order in which they were opened, an XML structure makes this intrinsically necessary (at least in order to be considered valid).
- Better consistency – Before XHTML 1.0, tag attributes did not need to be contained in quotation marks. That is, of course, unless there were spaces in the attribute value itself, in which case, quotation marks were necessary for the sake of the interpreter. This meant that some attributes would be quoted while others wouldn’t. With XML syntax, however, attributes need to be quoted, which leads to a greater all around consistency, not only within a single document, but also between different documents. It also helps with readability, making the attribute and its value easily recognizable with a single glance.
From my perspective, these are the three main benefits that caused me to embrace the XHTML and its stricter syntax with open arms. It’s made our code cleaner, better structured and more consistent, and for me that’s definitely a good thing.
A Step Backward or An Open Road?
So, when I first started reading about HTML5 (before ever purchasing Keith’s excellent primer), I have to admit that I viewed it with some apprehension. The simple reason for this is best encapsulated in Keith’s own words:
With HTML5, anything goes. Uppercase, lowercase, quoted, unquoted, self-closing or not; it’s entirely up to you (16).
For someone like me, who embraced the XML-ness of XHTML, the very thought of opening everything back up at first seemed like a mammoth step backward. I mean, it was like undoing the very thing that I loved so much about XHTML 1.0 and that definitely rubbed me the wrong way.
However, since HTML5 seemed like such a big deal and so many people who are a lot smarter than I am were actually looking forward to it, I decided to withhold any final judgment until I had the chance to read more about it. I also decided that HTML5 for Web Designers would be the best place to start, so I held off as much as possible until I actually had that volume in my hands.
And now that I’ve read it? I still feel pretty much the same way, actually.
Because the HTML5 specification was created not just for web designers and developers, but also for the people actually making the browsers, I understand the reasoning a bit better now. The idea was not to create a new language based on theory, but to extend the current language based on the content already exists. It’s the concept of paving the cowpaths (Keith, 10), which essentially means: take what’s already there an make it better.
So, because there are still thousands of sites out there that still used non-XML formed HTML, the decision to make HTML5 so open ended makes sense in the light of backward compatibility. It’s what the browser makers are doing anyhow. All that “bad” coding out there still renders, and has been doing so long before the introduction of HTML5—which isn’t even fully supported yet anyhow.
And therein we begin to see the sometimes murky waters between the realms of pure theory and practical reality—but that’s a different discussion altogether.
Suffice it to say, however, that I’ve come to accept that HTML5 doesn’t so much take a giant step backward as it operates on an open road, allowing us to move forward without cutting off those who might still be lagging behind.
It’s Up to Me
Of course, I do realize that, when it comes to my own work, the openness of HTML5 doesn’t really matter. I believe in the benefits of XML syntax, and there is really nothing stopping me from continuing to use it (mostly) for any HTML5 coding that I do in the future. I can still write in lowercase, still produce well formed markup, and still quote all my attribute values.
Thus, I can still derive both the key benefits that I did from the syntax of XHTML 1.0 and all the new functionality of HTML5 (as it is supported, of course). I would encourage anyone else to do the same.
That’s why I am going to undertake an (x)HTML5 methodology for coding my own work. I’m certainly not arrogant enough to propose any sort of major revision to the HTML5 specification itself—I’m sure the people who devised it are a lot brighter than me, and I’m going to assume that they know what they’re doing. Instead, I think of this (x)HTML5 concept more as a methodology that can basically be boiled down to the decision to continue (or begin) using well formed XML syntax to deploy HTML5 documents.
If we embrace this concept, share it, teach it, evangelize it and otherwise support it, then doesn’t all the concern about the openness of the HTML5 syntax become something of a moot point? We won’t have lost any ground at all. As already noted, the browsers are already rendering non-XML HTML documents anyhow, so if people start writing non-XML HTML5, it’s not as though all that much will have really changed.
Methodology vs Technology, or Why Parentheses?
As already noted, I’m not looking to institute a new technology or specification, and there does already seem to be some work being done on the concept of a full XHTML5, which differs from my concept of (x)HTML5, in that the former is intended to actually be xml, while the later simply seeks to apply some of the syntactical benefits of XML to HTML5.
The WHATWG Wiki at least begins to explain the difference between HTML and XHTML (at least from their perspective), and notes that
There is a community who find it valuable to be able to serve HTML5 documents which are also valid XML documents. They may, for example, use XML tools to generate the document, and they and others may process the document using XML tools. These documents are served as text/html.
This could probably be useful to many people, but starts to get a bit beyond me in terms of relevance. The wiki article lists all kinds of differences between HTML5 and XHTML5 which seem to stretch beyond what is really relevant to my day to day work. I rarely work with actual XML tools, and am far more interested in the technology for the way in which it improves the structure and readability of my code.
That’s why I add the parentheses to my concept of (x)HTML5, since the idea is not necessarily to create pure XML documents (something that is probably not strictly necessary when working on the font-end code of a website). It is simply a matter of choosing to implement and enjoy the benefits of certain XML syntactical forms onto the open openness of HTML5.
To be quite honest, digging some of the more technical and schematic stuff too far starts to give me a headache sometimes, and I’m not sure that I would ever really find a concrete answer. That’s part of the reason I wanted HTML5 for Web Designers instead of digging into the actual HTML5 specification itself. Many of you out there probably know a whole lot more about the relationship between HTML5 and XHTML5 that I do, and I’m okay with that.
In this article, I have simply tried to encapsulate my own thoughts about HTML5, along with some of my initial concerns (and reasoning). I then tried to present the concept of an (x)HTML5 methodology as a means of deflecting my concerns in a positive fashion and continuing to derive what I perceive to be the primary benefits of the XML syntax in an HTML context.
I hope you found it interesting, and that it at least raised some interesting thoughts or questions.
Anyhow, now that I’m done throwing around acronym after acronym, it’s time to hear from you. What do you think about HTML5? Will you will still be using the XML syntax? Let’s hear your thoughts.Post A Comment
Also from Echo Enduring Media: