No browser supports HTML5 yet. Part 2. Technology.

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.

Validation and doctype myths and (inconvenient) truths

People like me who support web standards often talk about validation and doctypes. Yet, even within our camp, there seem to be a lot of confusion. I will try to address a few misconceptions, especially a few new ones that has come out of the ongoing debate about HTML 5 and accessibility and RDFa.

Background: How a browser processes markup

Most people tend to think in two stages. There is markup and there is a rendered page on the screen. In reality this is a a more complex process.

First comes parsing. The purpose of this is to convert the markup into an representation inside the program that is so to speak "understandable" to the computer and usable for rendering on the screen as well as to assistive technologies, like a screen reader. This internal representation is accessible also to manipulation through the DOM API. Indeed it is often talked about as the internal DOM representation of the document. From now one I will simply call it the DOM. Just bear in mind that I refer to this internal functionality as a whole, and not to the API in the rest of this article.

Parsing in itself is a multi-step process. It involves the simple mapping of the HTML markup, but also the applying of CSS, handling events, etc.

The rendering (painting on the screen) is in turned made from the DOM. As is the exposure of the page to assistive technologies.

Personally I've found it helpful to think about this process in three stages:

1. The code (HTML, CSS, etc) arrives as a network stream.
2. The DOM, constructed by the parsing.
3. The perceivable results (on the screen, in the speakers, in the braille terminal, on paper from print, etc.)

With this knowledge we can formulate the purpose of validation:

• Validation provides a secure mapping between the markup and the DOM. You as a developer know what you are going to get.
• Validation provides easier development, including easier error detection and better maintainability through cleaner and consistent code.

Browsers have always had mechanisms to handle badly written HTML. Indeed they have reverse engineered each other in this regard so much that invalid, tag-soup, piece of shit code usually renders just fine. And the HTML 5 spec goes to great length to explain just how such code should be handled by a browser. If one has supreme knowledge about every little detail of how browsers work internally, one can therefore get predictable results even with code that does not validate at all.

Web developers should, however, not be required to have such in-depth knowledge. Validation is a tool that helps us stay within safe boundaries. Stepping outside them might work, but it will always lead to extra work in the end.

With this in mind we can formulate a few spin-off effects of validation, such as:

• Validation is an act of courtesy towards other people who one day might be charged with taking over your code base, or indeed only be asked to take a look on a mailing list or forum, to help you solve a problem.
• Validation is a mark of professionalism, a sign that you care about code quality.

But the main effect is that validation is a tool that helps you as a developer get to your desired results. I always tell my students to validate early and validate often. After every major change to the code, re-run the validator!

Or to put it differently. Valid code is not the end goal, it is a very good tool in order to reach the end goals of predictability, consistency, maintainability and effectiveness.

Myth: You must validate in order to be accessible

Wrong. Validation is advisable of course, but in a pure technical sense not a requirement. It is perfectly possible to write unsemantic code, without proper hooks for assistive technologies, that still validates. And it is perfectly possible to do the other way round, although validation — especially to a strict doctype — will be one help towards accessible web sites.

Validation can check for the presence of accessibility features, such as alt-attributes, table column headings, etc. It can never ensure that the contents within those attributes and elements have been written in a usable way. Valid code is a good starting point for accessibility, not a guarantee of accessibility.

This is especially true for the non-strict versions of HTML 4.01 and XHTML 1.0. These 4 (2 * 2) (X)HTML versions contain a lot of elements and attributes, that should not be used. The validator will complain that they are deprecated, but it will still give the page a green light. Anything but strict doctypes or conformant HTML 5 (see below) should have been verboten long ago for any professional web developer.

Myth: There is no penalty for not validating

There is one camp, primarily accessibility experts, who would like browsers not to render pages that contain markup errors, or at least give clear warnings that they do. Recently it has been advocated that e.g. the HTML 5 canvas element should not render anything to sighted users unless there is a fallback for the blind. They also have argued that any refusal to incorporate ARIA or RDFa into HTML 5 can simply be overridden because validation does not matter.

In this context it is true. As long as browsers and assistive technologies support ARIA and Google, Yahoo and other search providers will honour RDFa, it will work. User agent behaviour is always the bottom line, the true de facto standard in practice.

This takes us back to my main theme for this article. Things might work when using code that is not valid. But you can be much more confident that it will, if it validates. In my experience, the most common error that I catch using a validator is spelling errors in tag and attribute names. Such errors may wreck your page in many ways, maybe even in unseen ways because you have misspelled an ARIA attribute. And such errors are easier to spot if they are not hidden behind hundreds of other validation errors, that by themselves actually are benign.

Let me repeat that. Many validation errors are benign: An un-encoded &, an unnecessary closing tag, and, with HTML 4.01, forgetting to specify the type attribute for a script. In themselves these errors will not harm the execution of the parser, the construction of the DOM or the rendering of the page on the screen and exposure of its contents to assistive technologies.

Actually, one may find oneself in a position where it is beneficial not to be valid. This applies both to HTML and CSS. New features, often available only in their experimental first forms, can be quite useful and add to a page's usability, esthetics or accessibility.

However, the problem with benign errors is that they often obscure the malicious errors. A page that contain several hundred validation errors is much harder to debug, than one that only has a few. It is therefore imperative that one chooses the best possible validator for one's purpose. E.g. validators can be configured to ignore vendor specific CSS-rules or to include ARIA.

Actually, the main reason I use an HTML 5 doctype for all my new sites, and gradually change my own sites to do the same, is so that I can use a validator that supports these new technologies.

Myth: You can use JavaScript to cheat the validator

Technically this is not a myth. Yes you can. Most validators will work on the raw HTML and will not process any scripts. However, the purpose of validation is not validation. The purpose is predictability, consistency, maintainability and effectiveness. Inserting or altering markup through scripts, or to put it better making changes to the DOM, should be made in such a way as not to jeopardize the very reasons we wanted or code to be valid in the first place.

This is just like school. Cheating may get you the grade, but you won't get the benefit of the knowledge. Cheating the validator means that you render the validation practically useless.

There are tools available that will let you see the generated HTML, that is the HTML as the browser has understood it too be, post parsing and post scripts being run on the page. This is sort of like going back from step 2 above to the first step. That code should be equally valid, and not differ from the original input in any unexpected way.

Follow up question: Is it OK to use JavaScript instead of the target attribute?

One of the most common uses of JavaScript to cheat the validator is to replace this:

<a href="http://..." target="_blank">linktext</a>

With this:

<a href="http://...">linktext</a>
<script>
// JQuery code that attaches event to all presumed external links
$("a[href^=http").click(function() {
    window.open(this.href);
    return false;
});

I belive this is good practice. Not because we are cheating the validator, but because we are using DOM-scripting to handle behaviour. We are using the right tool for the right job.

Follow up question: Is it OK to use JavaScript to defeat browser bugs?

My first answer is, is that really necessary? For example, it is quite possible to have the object element work in all browsers, including Internet Explorer 6, to serve Flash or Java Applets. Most JavaScript techniques to include Flash on a page have been obtrusive and not degraded gracefully. And they have used outdated browser-sniffing, potentially making them unlikely to work as newer browser versions or alternate browsers like Chrome get released. Using unobtrusive DOM-script to enhance the plugin experience is of course OK.

There are however bugs and lacking support for modern standards in some browsers (yes, we all know I primarily talk about MSIE now) that can only be alleviated through scripting. Chose carefully what scripts to use, though! And remember that there are many users that might not get your scripts, perhaps since a corporate proxy has stripped out all content from your script elements.

Does the doctype matter?

Tied in to the question about validation is the choice of doctype. It serves two purposes:

1. It declares what vocabulary a developer intends to use.
2. It is the main way in which all sane browsers chose their rendering mode. I defer this topic to Henri Sivonen, while asking people to note that Internet Explorer 8 is not sane in any way...

As regards the first point the doctype is of value to other people with whom you co-operate, a social contract between all developers in the team. But its main value is helping the validator see what rules to validate against.

Except for rendering mode switching, the doctype does not in any really discernible way affect how the browser will treat the functionality of your markup. E.g. even if you declare a strict doctype, it will happily honour elements like <font>, attributes like target or even the marquee-element! To a (sane) browser, there is no such things as different versions of HTML. XHTML 1.0 strict or HTML 4.01 frameset or HTML 5 is all the same. Any content sent with the MIME declaration text/html is treated the same.

By dropping the DTD, HTML 5 makes explicit, what so far has been implicit. There are different editions of the HTML standard, but in practice (inside the UA) there is but one HTML.

Even if you have used XHTML syntax and have an XHTML DTD, the markup still will be parsed as usual. To trigger XML parsing, one must change the MIME declaration, which of course will fail miserably with Internet Explorer and thus never happens except for niche web sites. It has also been conclusively proven that there is no benefit in switching modes depending on the UA. The speed difference between HTML and true XHTML is first of all negligible and it only really concerns the first step (parsing), which from a performance perspective is only a fraction of time, compared to whats going on in step 2 (the DOM) and step 3 (rendering). (There may be good reasons to use XHTML, but they are related to workflow, tools and data-exchange.)

Myth: HTML 5 re-introduces bad markup

OK this is not exactly a validation or doctype myth, but it is related. the short answer is of course that HTML 5 does not force bad markup down anyones throat. All good practices are still doable.

This myth started in the early days of HTML 5, when authors started to look at the spec and saw monstrosities like <font>, or even <marquee>! The dual purpose of writing a spec on how to handle bad markup, part of the browser requirements, together with a spec about how to produce good markup quickly turned into a communications debacle. The core team behind HTML 5 is perhaps not the ones with the best people skills in the world. Communication has broken down repeatedly. (On the other hand they are unlikely to change any bad behaviour, perceived or factual, through being bashed.)

In practice, though, HTML 5 has conformance requirements — which basically is a new term to describe validity — that are even more far reaching than the ones in HTML 4.01 strict or XHTML 1.0 strict. Being conformant should ensure that you are closer to adhering to best practice and accessibility principles. Validation thus is not less important, it is even more important than ever. Just remember that validation never really has been about anything else but getting a predictable DOM from your markup and encouraging best practices. The conformance criteria in HTML 5 are being written in such a way as to take your code even further towards these lofty goals.

This is one of the reasons there is no DTD for HTML 5. These new rules for validity are sometimes so precise or require such processing logic, that they can not be expressed through an DTD. As a side effect we get a doctype one actually can learn by heart:

<!DOCTYPE html>

That will make my students very glad!

Blogger and accessibility

Starting to edit my new blogger-blog, I see some glaring mistakes done by the developers. There is a ton of inline CSS for example. Even worse is the fact that they are hiding the skip-links from screen readers. It is a well known fact that "display: none" in your CSS will make all the block disappear not only from sighted users view, but also from what is being exposed to a screen reader. Thus, the following in my template is bad code:

  <span id="skiplinks" style="display: none;">
    <a href="...">skip to main </a> |
    <a href="...">skip to sidebar</a>
  </span>

I decided to improve upon that. Here is my agenda:

• Begin removing inline CSS.
• Make the skip-links accessible as they should be.
• Add ARIA-landmark roles.

Fixing the skip links and the CSS

Notice that the skip links are still part of the page tab order. In order to avoid confusion I want to make them reappear visually when they receive focus. And while we are at it, lets experiment with some new CSS-techniques as well:

#skiplinks {
    position: absolute;
    top: -100em;
    left: -100em;
}
#skiplinks a:focus {
    position: absolute;
    top: 103em;
    left: 100em;
    background: yellow;
    width: -moz-max-content;
    width: -webkit-max-content;
    width: -o-max-content;
    width: max-content;
}

Max-content is a planned addition for the CSS 3 box model. Currently it is only supported by Firefox and that through the preliminary -moz- prefix. I suppose Opera and Webkit will add support in a similar fashion, so I have anticipated that in my code.

ARIA Landmark roles

The breakfast on Saturday that concluded European Accessibility Forum I sat next to Peter Krantz and Steve Faulkner, as they discussed ARIA Landmark roles. Steve has written a nice wrap-up about them. In the future they will make skip-links redundant, as this is a much better solution. Look at the source code on this blog, and you'll see my contribution. Look for all "role" attributes. I have yet to add the role "navigation", but that seem to be impossible without using JavaScript. Since landmarks do not define dynamic content, I think static additions to the HTML is the preferred solution.

HTML 5 doctype

I have changed the doctype as well. Personally I am a fan of HTML 5, at least in comparison to many of my friends. The reason now however is that I intend to use Henri Sivonens conformance checker, that includes ARIA and RDFa support, instead of the W3C validator. Adding subheadings to my blog posts also really makes me wish that I could use HTML 5 sections in order to make them work even if the document structure changes drastically. Right now I am using h4, as that seems appropriate on the front-page, but will h4 be the correct choice also on other pages or in the future?

Update: Blogger keeps messing with the doctype. Aargh! Will leave it as is for now, but it does not help me stop thinking that Blogger's CMS is really annoying.