In the first post I questioned the perception that a particular browser supported HTML5, whereas other browsers do not, according to some misguided fan boys. I pointed out that browser vendors are quick to claim that a particular feature is supported, when in reality that support is half-baked and far from complete. And that is not a good thing!
History repeating itself
My main gripe with browser vendors not using solid shipping criteria for stable versions, but releasing flawed and incomplete implementations of HTML5,
is that it may lead to flawed and incomplete web sites. The message from Google,
Apple and numerous others is not, go forth and experiment
, but go forth and use
.
Today! Knowing very well that the HTML5 input range in Chrome or Safari is not
accessible, they still encourage actual real world usage. Knowing very well that Chrome exposed the JavaScript form validation
API only, and had no real constraints for invalid data, the implementation was shipped – and lo, it looked good in the support
charts!
So what happens when the spec changes? And what happens when real world usage will make needed spec changes not an option? Being responsible is way more important than being first. But once again, that does not look as cool on the support charts…
By putting half baked implementations into non-beta software Chrome and Safari actually do harm to the web. Why are we cursing Internet Explorer 6. It was not for lack of innovation and standards support when it first shipped. It is because that standards support was buggy and incomplete – that's right, it was half baked. And now we see Chrome and Safari releasing unfinished implementations as well.
In one way, we are at a better place right now. Chrome is aggressive in its updating of itself and Safari versions also have relatively short shelf life. But when real world web sites appear that lock in to today's versions and break when bugs are fixed, things will not look so rosy any more.
And please consider this. Back in the earlier 90's Netscape released new versions at an equally frantic pace.
The web year
was supposed to be five months and every web year should mean a major update to Netscape navigator.
So JavaScript shipped even long before the implementation was mature, and because of this we are still stuck with some really
bad api's and bugs, that could have been squashed given a few more months of time, can not be squashed, because sites soon depended
on them to work correctly. As long as Chrome was a niche browser it might not have mattered, but now that it has received a descent
and well earned market share, it will matter. (Not to mention the mobile space, where Webkit based browsers are ubiquitous.)
Exhibit A: Web forms
Web forms are really the starting point for all things HTML5. In spite of that fact, it is not until now that work has begun in earnest to implement all new cool form features. Except for Opera, of course, who implemented most of this a few years ago!
The work to get the HTML5 additions to web forms into Webkit is tracked in bug 19264. The work to get it into Gecko is tracked in bug 344614 and on a wiki planning page. The most important part being the shipping criteria. (I subscribe to these bugs to keep myself informed, but then perhaps I don't really have a life…)
I could go on and explain details about what is lacking in browser A, B or C, but I will not make this blog post any longer than necessary. Look at the tracking bugs and see for yourself. At the moment neither Webkit nor Gecko (nor Opera) is nowhere near having a complete HTML5 web forms support. They all lack some features and they all lack accessibility. (The Webkit bug is a bit deceptive, since it does not seem to list all features like the Mozilla bug does.)
Exhibit B: Sectioning elements
Some new HTML5 elements seem really easy to understand. They are not hooked into browser behavior, JavaScript API's or some other esoteric behind the scenes weirdness. They just seem to be turbo-charged divs, divs with real semantic meaning. Furthermore, they are a part of the HTML5 spec that is reasonably mature and thus ripe for implementation in browsers.
Yes, there is one talked about crux. It is not super duper easy to
differentiate
between article and section. Perhaps the spec will need some further explanations, or perhaps that will be taken care
of in the for dummies
version.
But there is one further matter, a point that seem to be universally missed. Even by browser makers! And that is the fact that sectioning elements affect document outline and that should in turn be exposed to seeing users through varying sizes on the headings and to non-sighted users through their assistive technologies. Headings are used when scanning a page – both by sighted and non-sighted users. Being able to tell at what level a heading is, is therefore a critical part of any implementation.
The real deal breaker is not if you can set display: block
on <article>. The real deal breaker is if you can easily set an <h1> within any sectioning element to
resemble <h2>, or setting it to resemble <h3> if it's one step further down in the document hierarchy. Etc.
Being able to style a sectioning element is actually a bullshit claim. HTML5 mandates that one should be able to style
any unknown element. That is, a browser vendor could claim that they support
the <foobar>, <my_cat> and <steve_jobs_is_god> elements, since according to HTML5, they should!
At least in the sense that they make those elements part of the DOM and therefore styleable through CSS.
-moz-any() to the rescue (somewhat)
The only browser to have any reasonable way of styling headers, depending on how deeply nested they are within sectioning content, is Firefox 4, currently in early beta only. This is done through the brilliant any() selector, being implemented, as it should, with a vendor prefix, until all details are agreed upon.
(The hardest part to figure out, before this can go CR, is how this selector should handle specificity. What happens if you mix type, class and id selectors inside one parenthesis?)
Nevertheless, try and write the following CSS selectors so that they work in any browser but Firefox 4:
h1 {}
h2, -moz-any(section, article, nav, aside) h1 {}
h3, -moz-any(section, article, nav, aside) \
-moz-any(section, article, nav, aside) h1 {}And so on. You will get tired of typing really quick.
Thus, only Firefox 4 can claim to support HTML5 sectioning elements in any usable fashion. The point of these elements is not that they should serve as styling hooks. We already have <div> for that. The point is that they should affect the styling of headers, and that's simply not doable in a generic fashion in any browser but Firefox – so far!
But Firefox also have a long way to go, since they've not begun on working on the accessibility side of this. Until support for the any selector is universal, these elements can only be used in experiments or with fallbacks, such as always using <h2> when one level down into sections, <h3> when two levels down, and so forth. Actually, this is current recommended best practice.
But by not using <h1> all the time, we are missing out on one of the main advantages of this new outline model, namely cut-and-paste-ability. We still have to re-calculate the heading level depending on what page a piece of content appears. E.g. a blog post might have its heading as <h1> on the dedicated page, but it should be <h2> on the home page of the blog. Sub-headings should be <h2> on the dedicated page and <h3> on the home page, etc.
Until there is universal and accessible support for headers within sections, support charts may say that the elements are implemented and marketing may make a big noise about their presence. But right now, the only way to use these elements is through scripted hacks.
And that, my friends (and all enemies I've made by posting these two posts) is a non negotiable fact.
Exhibit C: <hgroup> and <nav>
This is a no brainer. The point of <hgroup> is to hide the subtitle from the outlining algorithm.
Thus there care only two requirements to call this feature supported. Make it available in the DOM. As explained above,
that's the easy part. The hard part is the accessibility issue. When a blind user scans through a page by jumping between
headers, an <hgroup><h1 /><h2 /></hgroup> should be presented as exactly one heading,
not as two. And it is a reasonable expectation that the subtitle is read out along with the main heading. In a perfect world
even perhaps prefixed with the word subtitle
to indicate that relationship. At least, when jumping to the next heading
it should be skipped, since it really is not next
, but part of the main heading.
In the same way, the nav element should be presented to blind users in a way that will let them skip over navigation or jump to navigation. (Also a no brainer, really.)
There is no browser on the market that supports thees behaviors. Indeed, to my knowledge, no browser even has begun working in earnest on this. But my point is not that browser X is better than browser Y. My point is that it is premature to claim support for this feature, when indeed one is missing the whole point of that feature.
So, is there no value in using these HTML5 elements?
There might be. First of all, they do no harm. And on that day when browser support really has been properly implemented, you will automatically get added benefits over using a div. Furthermore, they might be picked up by other software than browsers, or browser extensions, like Readability (I love it) and Safari Reader (technically not an addon, but a feature). Presently, this kind of functionality must rely on educated guesswork – some kind of software algorithm that analyzes the page and looks for ids, classes or patterns that usually would indicate the main content of a page. With HTML5 markup that algorithm will be simpler and therefore execute faster.
So this is my point. Knowledgeable web developers can use any HTML5 feature they like today. With progressive enhancement and graceful degradation, perhaps through JavaScript libraries. If you've come this far and think that I am discouraging any use of recent additions to the web stack, you are wrong. Just take reasonable care in how you do it, and do not trust browser marketing! One example of such care is to use WAI-ARIA everywhere, to address the accessibility issues. Since no browser offers built in accessible implementations of HTML5, we must resort to bolt on accessibility.
Browser support for HTML5 is not boolean, and neither should your usage of this be today.
Thus can I use HTML5
is a stupid question. It is all about the how you
use HTML5 and more specifically, what parts of it you use.
I am not a foe of HTML5 usage – but I am a friend of caution. After all, I'm over 40 years of age!
P.S. Firefox 4 does not look like Chrome, it looks like Opera! And of course there are several reasons behind Chrome's growth in market share.
