In this blog post I'm going to explain what I dislike about HTML5 and why I believe it's heading web development down the wrong path, and then I'll go on to explain what I feel is a better solution.
HTML5 was kicked off by a small group of developers at Opera and then grew up via the Hypertext Application Technology Working Group (WHATWG). Having read the entirety of Introducing HTML5, one of the authors of which is one of the key HTML5 evangelists from the original group of developers from Opera, as well as many, many blog posts, articles and tutorials on the subject, I love some of the features added to HTML5, but equally so I think some of them are a bad idea, implemented for the wrong reasons.
Before we go any further I'll clarify what I mean by 'HTML5'. Many web developers are under the impression that HTML5 is a standard which encompasses several key developments... and it is that, but let's remove some of the additions which have been implemented in browsers around the same time as HTML5 and are therefore assumed to be part of this new standard:
- SVG (Scalable Vector Graphics)
This I think is a tremendously useful piece of web technology, slimming down webpages with intricate vector graphics and allowing client-side interplay. The confusion between this and the HTML5 standard is probably due to the
<canvas/>element being standardised as a new element in HTML5, even though SVG is an independent W3C spec whose development started in 1999 and became a W3C recommendation in 2001. To put this in context XHTML became a W3C recommendation in January 2000, whereas HTML5 is officially still under development.
- Web Sockets
This allows for full-duplex communications over a TCP socket, and offers server-side events to trigger events client-side. The Web Sockets API is currently under discussion within the W3C, whereas the Web Socket Protocol is currently under discussion within the Internet Engineering Task Force (IETF). No mention of the WHATWG here, folks.
- Web Storage
Admittedly this was a part of the HTML5 specification and has now been branhced off into its own specification, once again under the supervision of the busy W3C.
- Geolocation API
Once again, there's no mention of WHATWG here. Nope, unsurprisingly it's the W3C.
So putting those exciting new technologies aside - and I have absolutely no beef with any of the above - what is there to dislike about HTML5? Chiefly, it's the syntax that I think is regressive.
The W3C have published what they're trying to achieve with HTML5. These are broadly split into compatibility, utility, Interoperability, and universal access. Now, the current standard for browser-based markup is XHTML 1.1 which replaced HTML4 over 10 years ago. Among the problems of the HTML4 age were several browser-specific tags being used and poor standards of markup. The HTML4-tolerated practice of leaving markup errors to the browser to fix wasn't something which HTML was originally intended to take care of, but due to lots of sloppy writing and some clever markup parsing on the part of the browsers, it came to be relied upon. XHTML imposed XML syntax rules into the field of play, as well as three different doctypes to help people during this transition from sloppy markup to correct markup. And yet more than 10 years later we find ourselves in the situation where a new standard is being specified which goes back to tolerating sloppy markup. For the record, I don't think it's a good idea to allow
<b>a<i>b</b>c</i> back onto the web and pretend that nothing is wrong. (That HTML snippet is actually taken from the W3C's quoted design principle objectives.) I'm certain that all web developers have at some point written markup like this, refreshed the browser, noticed that something is wrong, found it and corrected it. What the HTML5 specification is now trying to do is let mistakes like that go unnoticed. Is this a good thing? I think not.
And how would poorly-written markup appear in older browsers? I'm not talking about IE6 but the likes of IE8, versions of Firefox pre-version 7 and so on? What about those browsers that were written for XHTML which doesn't allow poorly-formatted markup, but will now potentially be sent that snippet above?
In response to the W3C's stated design principle of compatibility there are two points I'd like to make: When XHTML was launched, older browsers had no problem with it due to its enforcement of correct syntax. Furthermore, the W3C claim as XHTML requires the markup to be perfectly-formed XML, and therefore when it comes across a part of the document which breaks the rules of XML, again just like our snippet above, the XML parser will go no further which, they conclude, will potentially result in pages with parts missing. Problem? Shouldn't a developer check that the page displays as expected before they publish it? If part of the page is missing why wouldn't the person putting the page together investigate? Are we now making allowances for half-hearted work? I would also point out that HTML such as the snippet above does not result in the XHTML parser going no further. Browsers are intelligent enough to put closing tags in when they believe one has been left out. Don't like this practise? Well that's what you're going to be asking of the browser when you throw that broken snippet at it and call it HTML5. The difference is that under XHTML the browser will usually add a closing tag for you (ok, it might not be where you intended that closing tag to be) whereas under HTML5 it will try to interpret what you wanted, and re-arrange your markup for you. Having said that, the HTML5 standard will dictate how broken markup should be re-arranged, so that broken markup will be the same in each browser rather than different browsers implementing different fixes for your sloppy work. I prefer the XHTML approach as this is more likely to highlight to the developer that something is not as expected; The design principles talk about a "consistent DOM" but I'd rather know when something is wrong rather than having the same cover-up treatment applied however I look at it.
I prefer the prevention-rather-than-cure approach.
As a point of note, about two-thirds of the HTML5 standard relates to how browsers should correct poorly-formatted markup.
Another facet of poor markup that HTML5 is accommodating of is broken HTML. When I say "broken HTML" I'm trying to distinguish it from "poorly-formed HTML" which I've already discussed. By "broken HTML" I mean markup with a missing closing tag (rather than a misplaced or wrongly-nested closing tag) or an attribute which has not been enclosed in quote marks, or where the attribute has been opened with a double quote mark but is missing the ending double quote mark. For example
According to the XHTML 1.1 standard
<p> This is a valid XHTML 1.1 paragraph element. </p>
According to the HTML5 standard
<p class="myClass> This is a valid HTML5 paragraph element.
<p class=myClass> This is a valid HTML5 paragraph element.
As with XHTML, shoudn't we be discouraging this malformed markup? Shouldn't the browser be pointing it out to the developer rather than tolerating and pretending that nothing is wrong?
XHTML excelled at separation-of-concerns: It removed the presentation components from the markup and left only a data structure in place. The presentation layer was then catered for by CSS. I can't see anyone arguing that this wasn't a great idea. So where HTML4 had, for example,
<center> and so on, XHTML required that this be rewritten in a more formal method using CSS. (For example, those would normally be written in the style of
<span style="font-weight:bold">.) In my opinion separation-of-concerns is a facet which is central to writing correctly for both backwards and future-compatibility, for different devices, for accessibility, and is simply best engineering practice. HTML5 serves to remove separation-of-concerns and re-introduces presentation tags.
The W3C's stated Design Principles address separation of concerns (section 3.4). Although they concede that "markup that expresses structure is usually preferred to purely presentational markup", they also claim that "[n]ames of elements and attributes in the markup may be pragmatic (for brevity, history, simplicity) rather than completely accurate". The stated Design Principles also claim "The b and i elements are widely used — it is better to give them good default rendering for various media including aural than to try to ban them." So if a small percentage of drivers started driving on the other side of the road, would we change the law so that you could drive on whichever side of the road you preferred? I just don't get why they're removing best practice and replacing it with a mechanism that encourages bad practice. Ok, the analogy might be a bit extreme, and I recognise that we probably do need some sort of default rendering for all used tags, but that doesn't require that the standard be written around these outdated presentational elements.
Another area which HTML5 seeks to cover is Search Engine Optimisation (SEO) and introduces tags for identifying the header section of a page, the navigation section of the page, if the page contains an article, and the footer section of a page (amongst others). The rationale behind this was because it has been observed that most webpages have these, and use some sort of common attribution of this section (i.e.
class="header"id="footer"), and someone therefore thought "why don't we just designate a tag that replaces that?" Once again, we see the terseness of an extensible markup standard replaced by semantically denoting each part of the page. I just don't see what advantage this has over XHTML. Rather than styling an ID or a class, developers will now style an element. Is that progress? There's nothing stopping a developer using
<nav> for the page header and
<header> for the page navigation - these elements carry no default presentation and no real semantice value. I believe the intention was for SEO purposes but as yet I don't believe that search engines are higher-ranking pages with
<header> over pages with
<div id="header">. In fact, search engines don't really care about the markup of your page, they're far more concerned with the content.
This article by Smashing Magazine carries a very good discussion on this topic.
So, to summarise thus far
- HTML5 is often mistakenly thought of as a suite of standards encompassing technologies such as SVG, Web Sockets, Web Storage and the Gelocation API. HTML5 is actually purely a markup standard and these other technlogies have their own standards.
- HTML5 re-introduces presentational elements back into standardised HTML. This contravenes the separation-of-concerns principle that best practice dictates should be present.
- A large proportion of the HTML5 standard dictates what should happen in the case of malformed markup so that the browser renders the page as if nothing is wrong. I see no benefit in this approach, but I can see a benefit in highlighting where things have gone wrong.
At times it seems as if the HTML5 standard has been written for people who develop in the dark, i.e. developers who don't check what they've just written.
- The HTML5 standard introduces new elements for denoting which part of a page the current section belongs to i.e.
<nav>, etc.. Currently the only real effect that I can discern from this is that your markup is now tightly coupled to the presentation.
I said at the start of this blog post that I had an alternative, and I have. Let's call it HTMLx.
The simplest description of HTMLx is that it's a markup format without named elements. Ok... it does have some named elements (I'll come onto those in due course) but importantly it's a format rather than a language.
Typically with XHTML or HTML5 you will add a new element, write its name (for example,
<div>) and then add styling with CSS. You could add an id or a class attribute (correctly-formatted, I would hope) and then target this id or class attribute. Alternatively you could write CSS that targets either all elements of this type, or your CSS could use a hierarchical selector (for example
#header h2 or
div p.myPara > span.myFirstSpan). Those who are au fait with CSS will know that a
<span> has its display CSS property set to inline whereas
<div> elements have the same property set to block. In fact, the differences between a
<span> element and a
<div> element are the display, padding and margin properties, all of which are CSS settings which developers will customise for each page or site.
What we currently have with the interplay between HTML and CSS is that inside one file we have the data structure, where the data is wrapped inside elements which have default presentation properties (and which can differ between browsers), and then we have a CSS file which contains the instructions for adding to or over-writing these default presentation properties.
Now, given that each element can be customised to the extent that it acts as a different element, why don't we just remove the element name? Why don't we just assume some basic properties for each element and encourage the developer to employ CSS rather than relying on default behaviour?
So instead of having something like
<div id="article"> <p class="myPara"> This is a paragraph of an article. </p> <p class="myPara"> This is another paragraph of the same article. </p> </div>
<id="article"> <class="myPara"> This is a paragraph of an article. </> <class="myPara"> This is another paragraph of the same article. </> </>
This would place an extra requirement on the developer to ensure that those fundamental properties which are currently already set for the likes of
<span> are now set explicity in their CSS.
The advantages of HTMLx would be:
- We now have complete separation-of-concerns and have removed the entire presentation responsibility to CSS.
- Removal of the assumption that developers place upon the default settings that each browser implements.
- Simplification of the associated standards.
- Simplification of learning how to build a webpage.
- Removal of cross-browser differences in implementing HTML.
- Easier re-skinning of websites.
HTMLx could also be fairly simple for browser vendors to implement: the rendering process would be identical with the exception that a default element behaviour would never be implemented. In fact, because default behaviours no longer have to be implemented, page rendering might actually speed up.
There are a few simple rules which I should explain:
- HTMLx keeps the
<input/>tags that have been standardised for HTML5.
- An element consists of an opening tag and a closing tag with or without content between the tags,
<>this is content</>.
There may be a case for self-closing elements but I haven't thought of any outside of the inclusion of
- An opening tag may or may not have attributes, and as this is my standard it's my choice that all attributes adhere to the rules for XML attributes.
<input/>elements, the only available attributes are id and class.
- An element may have one or both of the available attributes.
- Even though elements will not be named, elements will be addressable by CSS selecters without having an id or class attribute.
- The current pseudo-selecter behaviour for elements such as anchor tags (
<a>) are made available if an href attribute has been specified.
- The current
<body>tags will be maintained in HTMLx.
- All elements which are designed for the
<head/>section of an HTML document will be maintained. They're not perfect but I'm only suggesting an alternative for the rendered elements of the webpage.
As an alternative to the
<nav> elements in HTML5, just in case search engines decide to start paying attention to the naming of these elements (and they currently don't weight them with any importance over the rest of the page's content) there could be a pre-determined list of recognised id and class attributes which might carry the same significance.
This is by no means a fully thought-out standard, so I'd be surprised if it could be implemented using the above directions. There will almost certainly be oversights on my part so please don't be too negative and point out what wouldn't work because I most likely just didn't consider it yet. Nonetheless, I believe that the concept of effectively making each rendered element anonymous, and therefore not having a default behaviour and appearance for each rendered element, would have many benefits, and in those cases where I've overlooked some required behaviour I'm still sure that this minimalistic approach to separating the concerns could be employed.