Archive for the 'HTML5' Category

Ten years of WHATWG

A little over ten years ago, on 4 June 2004, Opera employee Ian “Hixie” Hickson sent a mail titled WHAT open mailing list announcement announcing

a loose, unofficial, and open collaboration of Web browser manufacturers and interested parties. The group aims to develop specifications based on HTML and related technologies to ease the deployment of interoperable Web Applications

Ten years is a long time, especially so in software, but nevertheless, the achievements of WHATWG have been remarkable. Hixie wrote

The working group intends to ensure that all its specifications address backwards compatibility concerns, clearly provide reasonable transition strategies for authors, and specify error handling behavior to ensure interoperability even in the face of documents that do not comply to the letter of the specifications.

Core aspects of the web platform were never adequately specified. XMLHttpRequest, for example, was shipped in IE5 in March 1999, and reverse-engineered and shipped in Firefox, Opera, Safari and iCab, but never actually documented until Anne van Kesteren co-specified it in WHATWG in a Working Draft of 5 April 2006. Anne’s currently working on the Fetch Standard, which defines something as basic as “requests, responses, and the process that binds them” and the Encoding Standard:

While encodings have been defined to some extent, implementations have not always implemented them in the same way, have not always used the same labels, and often differ in dealing with undefined and former proprietary areas of encodings. This specification attempts to fill those gaps so that new implementations do not have to reverse engineer encoding implementations of the market leaders and existing implementations can converge.

Of course, the poster children of WHATWG are the slew of new APIs that “HTML5” brings us – Web Workers, Web Sockets, native video and audio etc etc. There have been mistakes along the way (of course there have, in a decade!). Last year, Hixie told me

My biggest mistake…there are so many to choose from! pushState() is my favourite mistake, for the sheer silliness of ending up with an API that has a useless argument and being forced to keep it because the feature was so desired that people used it on major sites before we were ready to call it done, preventing us from changing lest we break it. postMessage()‘s security model is so poorly designed that it’s had academic papers written about how dumb I was, so that’s a pretty big mistake. (It’s possible to use postMessage() safely. It’s just that the easiest thing to do is not the safe way, so people get it wrong all the time.) The appcache API is another big mistake. It’s the best example of not understanding the problem before designing a solution, and I’m still trying to fix that mess.

But to me, the biggest triumph of WHATWG has been error-handling and interoperability (actually, two sides of the same coin). We’ve moved from a vision of the future where everything was supposed to be XML and browsers were to stop parsing if they met malformed markup, to a present where every browser knows how to construct an identical DOM from the most mangled/tangled HTML. We’re moving to a world where interoperability is paramount, and where specifications are made in the open, in constant consultation with developers (for example, Service Workers, Web Components) based on real use-cases.

I think the existence and the work of WHATWG has secured the viability of the web platform. Happy 10th birthday. And thanks.

Should you use HTML5 header and footer?

Matt Wilcox asked “I still don’t bother with <header> <footer> etc. I assume all widely used browsers support them now. But, do they do anything more than div?”.

It’s a good question. The answer I gave is “yes”. These two elements (and <nav> and <main>) give value to users of some assistive technologies on some browsers.

In the HTML5 spec, HTML elements are mapped to ARIA information. Some of those may be over-ridden by authors, but if they aren’t, they have default implicit ARIA semantics. A <header> element that is not a descendant of an article or section element maps to ARIA role=banner, for example. You don’t need to add any ARIA information; it’s included, free, in the HTML element.

These aren’t necessarily implemented everywhere; Steve Faulkner’s excellent keeps tabs of implementation. As an example, <footer> causes Chrome to expose the element with a footer role in IA2, and Firefox to exposes as ARIA landmark role=”contentinfo” (when not a child of article or section elements).

These are useful to people, as we can see in WebAIM’s 5th annual screenreader users’s survey (which encouragingly tells us “For the first time in 5 years of surveys, respondents are more positive about web accessibility progress than in the previous survey”).

When asked “How often do you navigate by landmarks/regions in your screen reader?” (such as “contentinfo”, “banner”, “main”, “navigation”), 26% said “whenever they are present”.

20% thought 1-3 landmarks/regions per page is optimal; 29% thought 4-6 is the right number.

So my advice is: yes, use them – especially the main <header>, <footer>, <nav> and (once per page) <main>. On browsers/ ATs that don’t support them they do no harm. But don’t use billions.


Added 13 May to clear up confusion:

  • Use <header>, <footer> as often as your content requires – only the main header and footer carry implicit banner and contentinfo roles. At a minimum, use them once (assuming you have a page header and footer, that is).
  • Always use <nav> for the primary navigation.
  • Use <main>, but only once per page.
Added 3 September 2015: The 6th Screenreader Survey tells us that 63% of screenreader users sometimes/ often/ always use landmarks/ regions. So definitely use them. Kiss.

Why does HTML footer take role=”contentinfo”?

A chum asked me “why use role=contentinfo instead of role=footer for <footer>?”

role attributes are from the Accessible Rich Internet Applications (WAI-ARIA) spec, and not part of HTML(5), although they’re allowed in pages. They’re developed by different groups, and for different reasons. ARIA is a bridging technlogy for any markup language – HTML4, SVG or HTML5 to “plugin” accessibility information that isn’t part of the host language:

WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page…

It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature.

contentinfo is defined as an ARIA landmark on a page. It’s primarily there so assistive technology can allow a user to navigate around. The ARIA spec describes contentinfo as

A large perceivable region that contains information about the parent document. Examples of information included in this region of the page are copyrights and links to privacy statements. Within any document or application, the author SHOULD mark no more than one element with the contentinfo role.

This is a good description of a page footer, but HTML5 allows as many <footer> elements as you want:

The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

The HTML5 <footer> does give “content info” but does so about its parent, which may be one of many <article>s or <section>s. Another element that gives information about the content it’s in is the <address> element, which may (but doesn’t have to) take an ARIA role of contentinfo.

So there’s not a 1-to-1 correspondence between <footer> and role="contentinfo". This is exactly the same as the correspondence as we see between <header> and role="banner". So it’s probably less confusing that the HTML5 element and the ARIA roles have different names.

It seems that the name <footer> was adopted as it was the most common class name found in a billion web pages analysed in 2005 by Ian Hickson, HTML5 editor. Arguably, contentinfo is a better “semantic” name (after all, information about content doesn’t have to be below the content it refers to, which is what “footer” implies), but “footer” is what people were already using. Anyway, the naming of the new HTML5 elements is done now. There’s no use in bikeshedding once the ship has sailed, as Captain MixedMetaphor says.

The HTML5 spec says that a “footer element that is not a descendant of an article or section element” (that is, the footer for the whole page) has a default implicit ARIA semantic of contentinfo. That is, assistive technologies are supposed to infer that role without the author specifying it. Good; that’s the way it should be.

However, until all do, you give a helping hand by explicitly adding that role on the page-wide footer.

Reading List

Apologies for the irregularity of the Reading List at the moment; September and October are autumn conference season and my schedule is bonkers.

Responsive Images

A meeting at Mozilla Paris on how to solve Responsive Images, organised and summarised by Marcos Caceres concluded

  • Browser vendors agree that srcset + DPR-switching is the right initial step forward (i.e., the 2x, 3x, etc. syntax).
  • Agreement to then consider srcset + viewport size after some implementation experience (possibly drop height syntax from srcset spec). If not implemented, Width/Height syntax to possibly be marked at risk in srcset spec.
  • Browser makers acknowledge the art-direction use case, but still think <picture> is not the right solution.
  • Adding new HTTP headers to the platform, as Client-Hints proposes to do, has had negative impact in the past – so Client Hints might need to be reworked at bit before it becomes more acceptable to browser verndors.

So initially, we’ll use something like

<img src="normal.png" 
srcset="retina.png 2x"
alt="otter vomiting">

Browsers that have “retina” displays will choose retina.png as they have 2 CSS pixels to one physical pixel. Browsers that aren’t retina, or don’t understand the new syntax, fall back to the good old src attribute.

WebKit and Blink have implemented (but not yet shipped) srcset, Mozilla is planning implemention now.

Meanwhile, an alternative “srcN” proposal has been put forward by Tab Atkins and John Mellor (excitingly, “John Mellor” was the real name of The Clash’s Joe Strummer). It claims to solve Resolution-based discrimination, Art-direction discrimination and Viewport-based discrimination usecases. Discussion here.

UK Government Web

The Cabinet Office’s Open Standards Board is recommending open standards technology. The first two to be approved are HTTP/1.1 and Unicode UTF-8. Francis Maude, the Minister, allegedly said “open standards will give us interoperable software, information and data in government and will reduce costs by encouraging competition, avoiding lock-in to suppliers or products and providing more efficient services”.

This may not be revelatory to those of us in the web world, but it’s a Good Thing for the nation.

I had the pleasure of hearing Paul Arnett (now of Twitter, previously of talking about the initiative at From The Front conference a few days ago, and thought it was a sign of schizophrenia that the same government that can allow subject experts make a world-leading governmental portal is the same government that disregards experts and its own consultation in wanting to censor the web.

I realise now that it’s the old Tory DNA: the belief in encouraging competition by economic liberalism, reducing bureaucracy, while remaining socially authoritarian and reeling from one moral panic to the other. So no change there.

Standardsy Stuff


Reading List

Here’s your bank holiday reading list!

On citing quotations. Again.

Every so often, the conversation about how to cite quotations in HTML comes up again.

I’ve experimented throughout the years. In the heady XHTML days, I did

<blockquote cite=””>
Blah blah
<cite><a href=””>Your mum</a></cite>

but it annoyed me that I was repeating a URL, and the cite attribute was invisible, anyway, so dropped it for

Blah blah
<cite><a href=””>Your mum</a></cite>

Then, HTML5 came about and changed the definition of the <cite> element to explicitly disallow citing the name of people. This was a mistake: HTML4 allowed it, so it broke backwards compatibility. Millions of WordPress websites used <cite> to mark up the names of commenters, so it made a very common use case suddently non-conforming. Anyway, no validator could possibly know whether <cite>Jane Eyre</cite> was citing the book or the person.

But, anyway, as part of learning HTML5 I was determined to “do it right” so I switched to using

Blah blah
<footer><a href=””>Your mum</a></footer>

because <footer> is explictly allowed inside a blockquote, and the spec says “A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.”, which seemed highly appropriate.

However, Hixie nixed this idea; apparently, this was for quoting a footer rather than attributing a quotation. (What about quoting a header?). Also, the metadata about the blockquote isn’t actually part of the blockquote.

As my fellow HTML5 Doctor, Oli Studholme has showed, people seldom quote exactly – so sacrosanctity of the quoted text isn’t a useful ideal – and in print etc, citations almost always appear as part of the quotation – it’s highly conventional.

Some have suggested

Blah blah
<figcaption><a href=””>Your mum</a></figcaption>

and that’s fine, but requires more markup, and potentially more complex CSS.

The advantage of cite-inside-blockquote is that it’s obvious what refers to what, because the citation is nested inside the quotation. Without CSS, browsers tend to italicise the citation, so it’s visually obvious that it’s not part of the quotation, but it is indented with the quotation as is very common with print. Also, crucially, it’s a very common markup pattern used by authors, as Steve Faulker has showed.

Once again, I propose that the definition of <cite> be reverted to include the real-world use for marking up names of those cited, and that the spec note that cite-inside-blockquote is one way (although not the only way) to link a quotation with the work or the person being quoted.

Also see

Reading List

Responsive images

WebKit has (partially) implemented a new attribute to our ancient chum <img> called srcset that allows authors to send a high-res image only to browsers that have high-resolution displays. It looks like this:

<img alt=… src="normal-image.jpg" srcset="better-image.jpg 2x">

That “2x” thing after the file name means that if a browser has 2 or more physical pixels per CSS pixel (eg, high resolution), it is sent better-image.jpg. If it’s not high-res, or if it’s a browser that doesn’t support srcset, it gets normal-image.jpg. There’s no JavaScript required, and it doesn’t interfere with browsers’ pre-fetch algorithms because it’s right there in the markup.

You can extend it further if you want to:

<img alt=… src=… srcset="better-image.jpg 2x, super-image.jpg 3x">

This implementation doesn’t have the horrible “pretend Media Queries” syntax that sources close to Tim Berners-Lee* called “like, a total barfmare, man”, but this is potentially a great leap forward; it saves bandwidth for the servers, stops people downloading gigantic images that they don’t need, is easy to understand and has graceful fallback.

Let’s hope it turns up in Blink, Trident and Gecko soon.

* “sources close to” is UK newspaper code for “we just made it up”.

Graceful degradation of SVG images in unsupporting browsers

Very very clever: SVG and <image> tag tricks. (Yes, <image> which the HTML5 parser aliases to <img>.)

Microdata / RDFa / “semweb” shizzle/ SEO

In The Downward Spiral of Microdata, nice Mr Manu Sporny predicts the death of “HTML5” Microdata and the triumph of RDFa Lite now that both WebKit and Blink have dropped support for the Microdata API (which allowed JS access to Microdata).

Co-incidentally, Mr Sporny is an inventor of RDFa Lite. Personally, I don’t care which triumphs – now only Opera Presto supports the Microdata API, there is no technical reason to prefer one to the other (in fact, as Facebook supports RDFa and not microdata, so you could argue it has greater utility).

Farewell, hgroup

The <hgroup> elements is removed from HTML 5.1. It was defined as “typically used to group a set of one or more h1-h6 elements — to group, for example, a section title and an accompanying subtitle.”

I shan’t be sad to see it go; in November 2010, I argued that it was too hard to grasp; if you want to indicate that something is a subtitle or tagline, you want to indicate that on the tagline itself, rather than on an element that groups a tagline and non-taglines.

More recently, Alex Russell and I had a conversation in which he argued that elements without a UI are likely to fail (more of that from him, later). I think he’s right in this case; <hgroup> is used solely to preserve the outlining algorithm which itself is esoteric.

So how do you now mark up taglines and subheaders? Simply: as you always have. The spec now discusses this in the Common idioms without dedicated elements section.

Three methods are suggested. The simplest is simply with punctuation:

<h1>The Lord of the Rings: The Two Towers</h1>

The second is by using a <span> inside a heading element that allows you to style the secondary part, for example with h1 span {display:block; font-style:italic;}:

<h1>The Mothers 
   <span>Fillmore East - June 1971</span> 

The third (and the one I use, because a tagline doesn’t feel like a heading to me, but does belong with one in the <header>):

<h1>The Mothers</h1>
<p>Fillmore East - June 1971</p>

Expect HTML5 Editor Steve Faulkner to blog about this for HTML5 Doctor when the jet-setting roister-doister returns back to Blighty next week.

What does the web platform need next?

The web platform has advanced out of all recognition, and continues to evolve at a frankly bewildering pace (I’m paid to keep track of all this stuff, and if I take a fortnight’s holiday I scramble to get back on top of it).

Four years ago, if you wanted to access your device’s GPS information, you pretty much had to use a native app; now, the W3C Geolocation API is available in all browsers, on most classes of devices.

The advancement of what marketing and the press like to call “HTML5” (but mostly isn’t just HTML5) is closing the gap between the capabilities of native and web. But it isn’t there yet.

In 2011, Joe Hewitt (original Firebug developer and Facebook person) wrote a great blog post called Web Technologies Need an Owner, which I quote here but is worth reading in its entirety:

The arrogance of Web evangelists is staggering. They take for granted that the Web will always be popular regardless of whether it is technologically competitive with other platforms. They place ideology above relevance. Haven’t they noticed that the world of software is ablaze with new ideas and a growing number of those ideas are flat out impossible to build on the Web? I can easily see a world in which Web usage falls to insignificant levels compared to Android, iOS, and Windows, and becomes a footnote in history. That thing we used to use in the early days of the Internet.

My prediction is that, unless the leadership vacuum is filled, the Web is going to retreat back to its origins as a network of hyperlinked documents. The Web will be just another app that you use when you want to find some information, like Wikipedia, but it will no longer be your primary window. The Web will no longer be the place for social networks, games, forums, photo sharing, music players, video players, word processors, calendaring, or anything interactive. Newspapers and blogs will be replaced by Facebook and Twitter and you will access them only through native apps. HTTP will live on as the data backbone used by native applications, but it will no longer serve those applications through HTML. Freedom of information may be restricted to whatever our information overlords see fit to feature on their App Market Stores.

I disagree with Hewitt’s suggested remedy – that there should be one rendering engine with “competent, sympathetic, benevolent leaders” and therefore no standardisation forum – but I share his worry. I want web to win.

I’ve been musing on what’s still missing from the web platform to make it more attractive to developers, and asked for people’s reasons why they chose native app development which I recorded in a gist.

Many of their “missing pieces” are actively being worked on in W3C and other standards bodies. DRM is controversially being worked on, specified by Google, Micrsoft and Netflix. I argue that “DRM” a necessary evil to prevent the web platform becoming irrelevant to a company like Netflix (which by itself constitutes a third of American peak-time internet traffic), but I mistrust its plugin architecture (without having the wit to suggest something better).

Hardware access is being looked at by the W3C sysapps group, which is working on things like Bluetooth API, Calendar API, Device Capabilities API, Network Interface API, System Settings API.

Camera access (and microphone) is handled by WebRTC, implemented in Chrome and Firefox. Presto-based Opera allows access to the camera with the getUserMedia API (a subset of WebRTC).

A Notifications API exists, but it’s not implemented anywhere as it’s incomplete I’m a liar; Web Notifications is supported by Chrome. (Correction courtesy of @simevidas) However, the spec only allows native-style notifications to show while the user has the relevant page open.

Offline working is very important – we see that in developing countries, web sites offering Java apps are very popular because of games that can be played offline. Although the current Application Cache is good enough for simple offlinerification, it isn’t powerful enough for industrial use. Jonas Sicking of Mozilla has a proposal to improve appcache.

One spec that also needs a mention here is the badly-named Indie UI spec. I assumed it was about User Interface and was therefore bound to fail (who would take seriously an attempt to standardise UI?) but it’s actually about User Interface Independence, abstracting away the “how” a user attempts to scroll (scrollwheel? swipe? pen? joystick? keyboard down-arrow?) from their intention. It’s like W3C Pointer Events taken further:

Independent User Interface (IndieUI) is a way for user actions to be communicated to web applications… IndieUI will allow web application developers to get these events from different devices without having to recognize how the user performed the action. With IndieUI, AT will have a simple set of events to control web applications, and web application developers will have a uniform way to design applications that work for multiple devices and contexts.

The adequacy of the Web platform depends on what kind of apps you’re making. The UK Government Digital Service recently cheered my cold, cynical heart by saying

Our position is that native apps are rarely justified … Stand-alone mobile apps will only be considered once the core web service works well on mobile devices, and if specifically agreed with the Cabinet Office … For government services, we believe the benefits of developing and maintaining apps will very rarely justify their costs.

When it comes to mobile, we’re backing open web standards (HTML5). We’re confident that for government services, the mobile web is a winner, both from a user and a cost perspective.

Apps may be transforming gaming and social media, but for utility public services, the ‘making your website adapt really effectively to a range of devices’ approach is currently the better strategy. It allows you to iterate your services much more quickly, minimises any market impact and is far cheaper to support.

This is about informational or transactional apps, rather than super high-performance games or heavily media-centric apps. But the latter aren’t the majority, even if they are higher-profile – according to yesterday’s HTML5 vs. Native vs. Hybrid. Global developer survey 2013. (Beware reading too much into this survey, as it’s commissioned by a Microsoft-centric company, so the respondants may have different perspectives than other app developers.)

Games developers benefit from the huge performance increases in JIT JavaScript engines, WebGL and Mozilla’s asm.js project looks very interesting. Whether this is enough, I don’t know; I neither write games or even play them. (Disclosure: Opera has a game engine product called Sphinx that I’ll talk about soon.)

Monetisation feels like a big deal to me. The Mozilla guys have an API called navigator.mozPay() but as far as I can tell this is only for Firefox OS and not the open web, so not relevant to this discussion at the moment. Hopefully, it will feed into the W3C Headlights project, which has identified Web Payments, HTML5 Performance and “Closing the Gap with Native” as areas for urgent study.

It seems to me that if reach is your goal, the Web Platform is your better choice – it works in lots of places. If getting paid for your app is your goal then currently native or hybrid development is your better strategy. We need to stop looking queasy when people want to get paid, too; free stuff isn’t an inalienable human right.

What can you do if you want the web to win? Use it, and nurture it. If you’re prepared to spend hours debating whether rebase or squash is considered harmful (and you should, because using tools well is the mark of a professional), then be prepared to spend 41 minutes considering whether your markup makes sense – the code that the browser runs is your product. As Confucius would undoubtedly have said, “Don’t just be on the web, be of the web”.

Hassle me, and other representatives of browser companies to get new standards agreed, and implemented. Vendor co-operation, clueful devs, Device APIs, open Operating Systems that don’t lock users into one browser, and (crucially) auto-updating browsers are the cornerstones of an open web.

(Added Friday 12 April: .net magazine interviewed me after reading this, where I reiterate and elaborate some of my points.)

HTML5 app manifests – are we emulating failure?

There’s a good article by groovecoder called Packaged HTML5 Apps: Are we emulating failure? which argues that “URLs delivered a better experience than native desktop apps; they can do the same for mobile apps”. groovecoder shows the shortcomings of app stores and installation processes, and suggests that a manifest/ packaging format for HTML apps would be a better experience.

And it would, except we’re currently emulating failure here too. Instead of getting together and agreeing on one standard that works across browsers, there are numerous different packaging formats which force developers to choose their platforms and thus stymies interoperability.

Here we are again. Best viewed in Netscape 4 or IE4? Here’s your multimedia, ma’am; would you like it Flash, Real Audio or Windows Media?

If only there were some kind of consortium of vendors, that strove to protect and strengthen the World Wide Web to ensure it can compete against native apps and locked-down platforms. It could serve as a mechanism for agreeing interoperable standards.

This potential “Consortium for the World Wide Web” (or “CW3” for short) could even have a middle-aged, slightly bewildered-looking Englishman as its director. I’d volunteer.