Journal tags: w3c

Many people are—quite rightly, in my opinion—upset about the prospect of DRM landing in the W3C HTML specification at the behest of media companies like Netflix and the MPAA.

This would mean that a web browser would have to include support for the plugin-like architecture of Encrypted Media Extensions if they want to claim standards compliance.

A common rebuttal to any concerns about this is that any such concerns are hypocritical. After all, we’re quite happy to use other technologies—Apple TV, Silverlight, etc.—that have DRM baked in.

I think that this rebuttal is a crock of shit.

It is precisely because other technologies are locked down that it’s important to keep the web open.

I own an Apple TV. I use it to watch Netflix. So I’m using DRM-encumbered technologies all the time. But I will fight tooth and nail to keep DRM out of web browsers. That’s not hypocrisy. That’s a quarantine measure.

Stuart summarises the current situation nicely:

From what I’ve seen, this is a discussion of pragmatism: given that DRM exists and movies use it and people want movies, is it a good idea to integrate DRM movie playback more tightly with the web?

His conclusion perfectly encapsulates why I watch Netflix on my Apple TV and I don’t want DRM on the web:

The argument has been made that if the web doesn’t embrace this stuff, people won’t stop watching videos: they’ll just go somewhere other than the web to get them, and that is a correct argument. But what is the point in bringing people to the web to watch their videos, if in order to do so the web becomes platform-specific and unopen and balkanised?

As an addendum, I heard a similar “you’re being a hypocrite” argument when I raised security concerns about EME at the last TAG meetup in London:

I tried to steer things away from the ethical questions and back to the technical side of things by voicing my concerns with the security model of EME. Reading the excellent description by Henri, sentences like this should give you the heebie-jeebies:

Neither the browser nor the JavaScript program understand the bytes.

Alex told me that my phone already runs code that I cannot inspect and does things that I have no control over. So hey, what does it matter if my web browser does the same thing, right?

I’m reminded of something that Anne wrote four years ago when a vulnerability was discovered that affected Flash, Java, and web browsers:

We have higher standards for browsers.

I was up in London yesterday to spend the day with the web developers of a Clearleft client, talking front-end architecture and strategies for implementing responsive design. ‘Twas a good day, although London always tires me out quite a bit.

On this occasion, I didn’t head straight back to Brighton. Instead I braved the subterranean challenges of the Tube to make my way across london to Google Campus, where a panel discussion was taking place. This was Meet The TAG.

TAG is the Technical Architecture Group at the W3C. It doesn’t work on any one particular spec. Instead, it’s a sort of meta-group to steer how standards get specified.

Gathered onstage yesterday evening were TAG members Anne van Kesteren, Tim Berners-Lee, Alex Russell, Yehuda Katz, and Daniel Appelquist (Henry Thompson and Sergey Konstantinov were also there, in the audience). Once we had all grabbed a (free!) beer and settled into our seats, Bruce kicked things off with an excellent question: in the intros, multiple TAG members mentioned their work as guiding emerging standards to make sure they matched the principles of the TAG …but what are those principles?

It seemed like a fairly straightforward question, but it prompted the first rabbit hole of the evening as Alex and Yehuda focussed in on the principle of “layering”—stacking technologies in a sensible way that provides the most power to web developers. It’s an important principle for sure, but it didn’t really answer Bruce’s question. I was tempted to raise my hand and reformulate Bruce’s question into three parts:

1. Does the Technical Architecture Group have design principles?
2. If so, what are there?
3. And are they written down somewhere?

There’s a charter and that contains a mission statement, but that’s not the same as documenting design principles. There is an extensible web manifesto—that does document design principles—which contains the signatures of many (but not all) TAG members …so does that represent the views of the TAG? I’d like to get some clarification on that.

The extensible web manifesto does a good job of explaining the thinking behind projects like web components. It’s all about approaching the design of new browser APIs in a sensible (and extensible) way.

I mentioned that the TAG were a kind of meta-standards body, and in a way, what the extensible web manifesto—and examples like web components—are proposing is a meta-approach to how browsers implement new features. Instead of browser makers (in collaboration with standards bodies) creating new elements, UI widgets and APIs, developers will create new elements and UI widgets.

When Yehuda was describing this process, he compared it with the current situation. Currently, developers have to petition standards bodies begging them to implement some new kind of widget and eventually, if you’re lucky, browsers might implement it. At this point I interrupted to ask—somewhat tongue-in-cheek—”So if we get web components, what do we need standards bodies for?” Alex had an immediate response for that: standards bodies can look at what developers are creating, find the most common patterns, and implement them as new elements and widgets.

“I see,” I said. “So browsers and standards bodies will have a kind of ‘rough consensus’ based on …running code?”

“Yes!”, said Alex, laughing. “Jeremy Keith, ladies and gentlemen!”

So the idea with web components (and more broadly, the extensible web) is that developers will be able to create new elements with associated JavaScript functionality. Currently developers are creating new widgets using nothing but JavaScript. Ideally, web components will result in more declarative solutions and reduce our current reliance on JavaScript to do everything. I’m all for that.

But one thing slightly puzzled me. The idea of everyone creating whatever new elements they want isn’t a new one. That’s the whole idea behind XML (and by extension, XHTML) and yet the very same people who hated the idea of that kind of extensibility are the ones who are most eager about web components.

Playing devil’s advocate, I asked “How come the same people who hated RDF love web components?” (although what I really meant was RDFa—a means of extending HTML).

I got two answers. The first one was from Alex. Crucially, he said, a web component comes bundled with instructions on how it works. So it’s useful. That’s a big, big difference to the Tower of Babel scenario where everyone could just make up their own names for elements, but browsers have no idea what those names mean so effectively they’re meaningless.

That was the serious answer. The other answer I got was from Tim Berners-Lee. With a twinkle in his eye and an elbow in Alex’s ribs he said, “Well, these youngsters who weren’t around when we doing things with XML all want to do things with JSON now, which is a much cooler format because you can store number types in it. So that’s why they want to do everything in JavaScript.” Cheeky trickster!

Anyway, there was plenty of food for thought in the discussion of web components. This really is a radically new and different way of adding features to browsers. In theory, it shifts the balance of power much more to developers (who currently have to hack together everything using JavaScript). If it works, it will be A Good Thing and result in expanding HTML’s vocabulary with genuinely useful features. I fear there may be a rocky transition to this new way of thinking, and I worry about backwards compatibility, but I can’t help but admire the audacity of the plan.

The evening inevitably included a digression into the black hole of DRM. As always, the discussion got quite heated and I don’t think anybody was going to change their minds. I tried to steer things away from the ethical questions and back to the technical side of things by voicing my concerns with the security model of EME. Reading the excellent description by Henri, sentences like this should give you the heebie-jeebies:

Neither the browser nor the JavaScript program understand the bytes.

But the whole DRM discussion was, fortunately, curtailed by Anne who was ostensibly moderating the panel. Before it was though, Sir Tim made one final point. Because of the heat of the discussion, people were calling for us to separate the societal questions (around intellectual property and payment) from the technical ones (around encryption). But, Sir Tim pointed out, that separation isn’t really possible. Even something as simple as the hyperlink has political assumptions built in about the kind of society that would value being able to link resources together and share them around.

That’s an important point, well worth remembering: all software is political. That’s one of the reasons why I’d really appreciate an explicit documentation of design principles from the Technical Architecture Group.

Still, it was a very valuable event. Bruce has also written down his description of the evening. Many thanks to Dan and the rest of the TAG team for putting it together. I’m very glad I went along. As well as the panel discussion, it was really nice to chat to Paul and have the chance to congratulate Jeni in person on her appearance on her OBE.

Alas, I couldn’t stick around too long—I had to start making the long journey back to Brighton—so I said my goodbyes and exited. I didn’t have the opportunity to speak to Tim Berners-Lee directly, which is probably just as well: I’m sure I would’ve embarrassed myself by being a complete fanboy.

There’s been quite a brouhaha over the past couple of days around the subject of standardising responsive images. There are two different matters here: the process and the technical details. I’d like to address both of them.

Ill communication

First of all, there’s a number of very smart developers who feel that they’ve been sidelined by the WHATWG. Tim has put together a timeline of what happened:

1. Developers got involved in trying to standardize a solution to a common and important problem.
2. The WHATWG told them to move the discussion to a community group.
3. The discussion was moved (back in February), a general consenus (not unanimous, but a majority) was reached about the picture element.
4. Another (partial) solution was proposed directly on the WHATWG list by an Apple employee.
5. A discussion ensued regarding the two methods, where they overlapped, and how the general opinions of each. The majority of developers favored the picture element and the majority of implementors favored the srcset attribute.
6. While the discussion was still taking place, and only 5 days after it was originally proposed, the srcset attribute (but not the picture element) was added to the draft.

A few points in that timeline have since been clarified. That second step—“The WHATWG told them to move the discussion to a community group”—turns out to be untrue. Some random person on the WHATWG mailing list (which is open to everyone) suggested forming a Community Group at the W3C. Alas, nobody else on the WHATWG mailing list corrected that suggestion.

Then there’s apparent causality between step 4 and 6. Initially, I also assumed that this was what happened: that Tess had proposed the srcset solution without even being aware of the picture solution that the Community Group had independently come up with it. It turns out that’s not the case. Tess had another email about the picture proposal but she never ended up sending it. In fact, her email about srcset had been sitting in draft for quite a while and she only sent it out when she saw that Hixie was finally collating feedback on responsive images.

So from the outside it looked like there was preferential treatment being given to Tess’s proposal because it came from within the WHATWG. That’s not the case, but it must be said: the fact that srcset was so quickly added to the spec (albeit in a different form) doesn’t look good. It’s easy to understand why the smart folks in the Responsive Images Community Group felt miffed.

But let’s be clear: this is exactly how the WHATWG is supposed to work. Use-cases are evaluated and whatever Hixie thinks is best solution gets put in the spec, regardless of how popular or unpopular it is.

Now, if that sounds abhorrent to you, I completely understand. A dictatorship should cause us to recoil.

That’s where the W3C come in. Their model is completely different. Everything is done by committee there.

Steve Faulkner chimed in on Tim’s post with his take on the two groups:

It seems like the development of HTML has turned full circle, the WHATWG was formed to overthrow the hegemony of the W3C, now the W3C acts as a counter to the hegemony of the WHATWG.

I think he’s right. The W3C keeps the rapid, sometimes anarchic approach of the WHATWG in check. But the opposite is also true. Without the impetus provided by the WHATWG, I’m not sure that the W3C HTML Working Group would ever get anything done. There’s a balance that actually works quite well in practice.

Back to the situation with responsive images…

Unfortunately, it appears to people within the Responsive Images Community Group that all their effort was wasted because their proposed solution was summarily rejected. In actuality all the use-cases they gathered were immensely valuable. But it’s certainly true that the WHATWG didn’t make it clearer how and where developers could best contribute.

Community Groups are a W3C creation. They don’t have anything to do with the WHATWG, who do all their work on their own mailing list, their own wiki and their own IRC channel.

I do think that the W3C Community Groups offer a good place to go bike-shedding on problems. That’s a term that’s usually used derisively but sometimes it’s good to have a good ol’ bike-shedding without clogging up the mailing list for everyone. But it needs to be clear that there’s a big difference between a Community Group and a Working Group.

I wish the WHATWG had done a better job of communicating to newcomers how best to contribute. It would have avoided a lot of the frustrations articulated by Wilto:

Unfortunately, we were laboring under the impression that Community Groups shared a deeper inherent connection with the standards bodies than it actually does.

But in any case, as Doctor Bruce writes at least now there’s a proposed solution for responsive images in HTML: The Living Standard:

I don’t really care which syntax makes the spec, as long as it addresses the majority of use cases and it is usable by authors. I’m just glad we’re discussing the adaptive image problem at all.

So let’s take a look at the technical details.

src code

The Responsive Images Community Group came up with a proposal based off the idea of minting a new element, called say picture, that mimics the behaviour of video

<picture alt="image description">
  <source src="/path/to/image.png" media="(min-width: 600px)">
  <source src="/path/to/otherimage.png" media="(min-width: 800px)">
  <img src="/path/to/image.png" alt="image description">
</picture>

One of the reasons why a new element was chosen rather than extending the existing img element was due to a misunderstanding. The WHATWG had explained that the parsing of img couldn’t be easily altered. That means that img must remain a self-closing element—any solution that requires a closing /img tag wouldn’t work. Alas, that was taken to mean that extending the img element in any way was off the cards.

The picture proposal has a number of things going for it. Its syntax is easily understandable for authors: if you know media queries, then you know how to use picture. It also has a good fallback for older browsers : a regular img element. This fallback mechanism (and the idea of multiple source elements with media queries) is exactly how the video element is specced.

Unfortunately using media queries on the sources of videos has proven to be very tricky for implementors, so they don’t want to see that pattern repeated.

Another issue with multiple source elements is that parsers must wait until the closing /picture tag before they can even begin to evaluate which image to show. That’s not good for performance.

So the alternate solution, based on Ted’s proposal, extends the img element using a new srcset attribute that takes a comma-separated list of values:

Not nearly as pretty, I think you’ll agree. But it is actually nice and compact for the “retina display” use-case:

Just to be clear, that does not mean that otherimage.png is twice the size of image.png (though it could be). What you’re actually declaring is “Use image.png unless the device supports double-pixel density, in which case, use otherimage.png.”

Likewise, when I declare:

srcset="/path/to/image.png 600w 400h"

…it does not mean that image.png is 600 pixels wide by 400 pixels tall. Instead, it means that an action should be taken if the viewport matches those dimensions.

It took me a while to wrap my head around that distinction: I’m used to attributes describing the element they’re attached to, not the viewport.

Now for the really tricky bit: what do those numbers—600w and 400h—mean? Currently the spec is giving conflicting information.

Each image that’s listed in the srcset comma-separated list can have up to three values associated with it: w, h, and x. The x is pretty clear: that’s the pixel density of the device. The w and h values refer to the width and height of the viewport …but it’s not clear if they mean min-width/height or max-width/height.

If I’m taking a “Mobile First” approach to development, then srcset will meet my needs if w and h refer to min-width and min-height.

In this example, I’ll just use w to keep things simple:

(Expected behaviour: use small.png unless the viewport is wider than 600 pixels, in which case use medium.png unless the viewport is wider than 800 pixels, in which case use large.png).

If, on the other hand, w and h refer to max-width and max-height, I have to take a “Desktop First” approach:

(Expected behaviour: use large.png unless the viewport is narrower than 800 pixels, in which case use medium.png unless the viewport is narrower than 600 pixels, in which case use small.png).

One of the advantages of media queries is that, because they support both min- and max- width, they can be used in either use-case: “Mobile First” or “Desktop First”.

Because the srcset syntax will support either min- or max- width (but not both), it will therefore favour one case at the expense of the either.

Both use-cases are valid. Personally, I happen to use the “Mobile First” approach, but that doesn’t mean that other developers shouldn’t be able to take a “Desktop First” approach if they want. By the same logic, I don’t much like the idea of srcset forcing me to take a “Desktop First” approach.

My only alternative, if I want to take a “Mobile First” approach, is to duplicate image paths and declare ludicrous breakpoints:

I hope that this part of the spec offers a way out:

for the purposes of this requirement, omitted width descriptors and height descriptors are considered to have the value “Infinity”

I think that means I should be able to write this:

It’s all quite confusing and srcset doesn’t have anything approaching the extensibility of media queries, but I hope we can get it to work somehow.

A year and a half ago, Eric wrote a great article in A List Apart called Prefix or Posthack. It’s a balanced look at vendor prefixes in CSS that concludes in their favour:

If the history of web standards has shown us anything, it’s that hacks will be necessary. By front-loading the hacks using vendor prefixes and enshrining them in the standards process, we can actually fix some of the potential problems with the process and possibly accelerate CSS development.

So the next time you find yourself grumbling about declaring the same thing four times, once for each browser, remember that the pain is temporary. It’s a little like a vaccine—the shot hurts now, true, but it’s really not that bad in comparison to the disease it prevents.

Henri disagrees. He wrote a post called Vendor Prefixes Are Hurting the Web:

In practice, vendor prefixes lead to a situation where Web author have to say the same thing in a different way to each browser. That’s the antithesis of having Web standards. Standards should enable authors to write to a standard and have it work in implementations from multiple vendors.

Daniel Glazman wrote a point-by-point rebuttal to Henri’s post called CSS vendor prefixes, an answer to Henri Sivonen that’s well worth a read. Alex also wrote a counter-argument to Henri’s post called Vendor Prefixes Are A Rousing Success that echoes some of the points Eric made in his ALA article:

The standards process needs to lag implementations, which means that we need spaces for implementations to lead in. CSS vendor prefixes are one of the few shining examples of this working in practice.

Alex’s co-worker Paul disagrees. He recently wrote Vendor Prefixes Are Not Developer-friendly:

1. Prefixes are not developer-friendly.
2. Recent features would have been in a much better state without prefixes.
3. Implementor maneuverability is not hampered without prefixes.

All of this would have remained a fairly academic discussion but for a bombshell dropped by Tantek at a face-to-face meeting of the CSS Working Group in Paris:

At this point we’re trying to figure out which and how many -webkit- prefix properties to actually implement support for in Mozilla.

The superficial issue is that web developers have been implementing -webkit- properties without then adding the non-prefixed standardised version (and without adding the corresponding prefixes of other vendors). The more fundamental problem is that while vendor prefixes were intended to introduce experimental features until those features became standardised, the reality is that the prefixed version ends up being supported in perpetuity. Nobody is happy about this situation but that’s the unfortunate reality.

Among the unhappy voices are:

• Bruce who wrote On the Vendor Prefixes Problem,
• Aaron who wrote This Must Not Happen!,
• Remy who wrote Vendor Prefixes — about to go south,
• Rachel who wrote a Call for action on Vendor Prefixes on the WaSP blog, and
• Daniel once more entered the fray, writing Call For Action: The Open Web Needs You Now.

Once again, Eric sought to bring clarity to the situation in the form of an article on A List Apart, this time publishing an interview with Tantek. Alex also popped up again, writing a post called Misdirection which addresses what he feels are some fundamental assumptions being made in the interview.

Finally, Mozilla engineer Robert O’Callahan—who I chatted with briefly at Kiwi Foo Camp about the vendor prefix situation—wrote about Alternatives To Supporting -webkit Prefixes In Other Engines in which he makes clear that evangelism efforts like Christian’s, while entirely laudable, aren’t a realistic solution to the problem.

It’s all a bit of a mess really, with lots of angry finger-pointing: at Apple, at Mozilla, at web developers, at the W3C…

My own feelings match those of Eric, who wrote:

I’d love to be proven wrong, but I have to assume the vendors will push ahead with this regardless. … I don’t mean to denigrate or undermine any of the efforts I mentioned before—they’re absolutely worth doing even if every non-WebKit browser starts supporting -webkit- properties next week. If nothing else, it will serve as evidence of your commitment to professional craftsmanship.

My trip to Shanghai went swimmingly. It kicked off with W3C Tech, which was a thoroughly lovely event.

I gave my talk—The Design Of HTML5—with the help of an excellent interpreter performing consecutive interpretation. It was my first time experiencing that—I had previously experienced simultaneous interpretation in Spain and Japan—and it was quite a good exercise in helping me speak in complete, well-formed sentences (the translation usually occurred at the end of a sentence).

Once my talk was done, I took some questions from the audience and was then showered with good wishes and tea-related gifts. They really made me feel like a rockstar there; I’ve never had so many people want to have their picture taken with me or have me sign their copies of my books—the publishers of the Chinese translations of DOM Scripting and Bulletproof Ajax were also at the conference.

W3C Tech was held on the east side of the river so I spent the first few days in the futuristic surroundings of Pudong. Once the event wrapped up, myself and Jessica moved across to a more central location just off Nanjing road. I quite liked the hustle and bustle, especially once I remembered the cheat code of “bu yao!” to ward off the overly-enthusiastic street merchants. I wish there were something similar for the chuggers here in the UK, but I have the feeling that the literal translation—“do not want!”—will just make me sound like a lolcat.

Anyway, I had a great time in Shanghai, doing touristy things and taking lots of pictures. I particularly enjoyed getting stuck in at street-level exploring the markets, whether it was electronics or food. The fried dumplings—sheng xian bao—were particularly wonderful. I plan to deliver a full report over at Principia Gastronomica.

So long, Shanghai. ‘Till the next time.

It’s been good to be back in Brighton—especially over the past few days while Tantek has been around—but now it’s time for some more travel …and nipping up to the first day of UX London doesn’t count.

I’m going to Shanghai. Shanghai! I know, right‽

Ostensibly, the reason I’m going to Shanghai—I just like repeating that—is to speak at an event called W3C Tech this weekend. But I’m not about to turn around and hop on the first flight back, so I’m going to be spend the week afterwards being a tourist.

I fully expect to culture shocked but I’m really looking forward to this. So many things to see! So much food to try!

If you’re familiar with the megacity, I’d love to hear your suggestions. Feel free to leave a comment (that’s right: comments!) and assuming adactio.com isn’t blocked by the great firewall of China, I’ll check out your recommendations.

Oh, and on the subject of the dodgy web situation, I’m guessing you won’t be seeing any Twitter updates from me for a while. Also, if you send me an email, you probably won’t get a response any time soon …that’s got nothing to do with censorship; I’m just crap at responding to email.

旅途愉快!

Craig Grannell from .Net magazine got in touch to ask me a few short questions about last week’s events around HTML5. I thought I’d share my answers here rather than wait for the tortuously long print release cycle.

What are your thoughts on the logo?

The logo is nice. Looks pretty sharp to me.

Why were you unhappy with W3C’s original stance (“general purpose visual identity”)? What do you think now they’ve changed this?

I was unhappy with the W3C’s original definition of HTML5 in the logo’s accompanying FAQ, where they lumped CSS, SVG and WOFF under the “HTML5” banner. I’m happy they changed that.

What’s your thinking on the current state of the HTML5 situation, given that WHATWG is dropping the 5 and just going with HTML?

I think the current situation makes things much clearer. The WHATWG are working on a continuous, iterative document called simply HTML. The W3C use that as a starting pointing for nailing down an official specification which will be the fifth official iteration of the HTML language called, sensibly enough, HTML5.

The WHATWG spec is the place to look for what’s new and evolving. The W3C spec, once it goes into Last Call, is the place to look for the official milestone that is HTML5. In practice, the two specs will be pretty much identical for quite a while yet.

But the truth is that authors shouldn’t be looking at specs to decide what to use—look at what browsers support in order to decide if you should use a particular feature—look at the spec to understand how to use features of HTML5.

For authors, it probably makes more sense to talk about HTML rather than HTML5. Remember that most of HTML5 is the same as HTML 4.01, HTML 3.2, etc. Answering yourself a question like “When can I use HTML5?” is a lot easier to answer if you rephrase it as “When can I use HTML?”

Most of the time, it makes a lot more sense to talk about specific features rather than referring to an entire specification. For example, asking “Does this browser support HTML5?” is fairly pointless, but asking “Does this browser support canvas?” is much more sensible.

Two good things have happened.

WHATWG

Firstly, as I hoped, the WHATWG have updated the name of their work to simply be HTML. This is something they tried to do a year ago, and I kicked up a stink. I was wrong. Having a version number attached to an always-evolving standard just doesn’t make sense. As Hixie put it:

…the technology is not versioned and instead we just have a living document that defines the technology as it evolves.

This change means that the whole confusing 2022 business that was misunderstood by so many people is now history:

Now that we’ve moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.

The spec is currently labeled as a “Living Standard”. Personally, I find the “Living Standard” strapline a bit cheesy. I’d much rather the document title was simply “HTML” followed by the date of the last update.

Note that this change only applies to the WHATWG. The W3C will continue to pursue the “snapshot” model of development so the spec there definitely retains the number 5 and will follow the usual path of Working Draft, Last Call, Proposed Recommendation, and so on.

I think this difference makes it clearer what each group is doing. It was a pretty confusing situation to have two groups working on two specs, both called HTML5. Now it’s clear that the WHATWG is working more like how browsers do: constantly evolving and implementing features rather than entire specifications. Meanwhile the W3C are working on having a development milestone of those features set in stone and labelled as the fifth revision to the HTML language …and I think that is also an important and worthy goal.

W3C

The second piece of good news is that the W3C have backtracked on their “embrace and extend” attitude towards buzzwordism. When they launched the new HTML5 logo a few days ago, the W3C Communications Team initially said that HTML5 included CSS, SVG and WOFF‽ As Tantek said:

Fire the W3C Communications person that led this new messaging around HTML5 because it is one of the worst messages (if not the worst) about a technology to ever come out of W3C.

Following the unsurprising outbreak of confusion and disappointment that this falsehood caused, the W3C have now backtracked. HTML5 means HTML5. The updated FAQ makes it very clear that CSS3 is not part of HTML5.

Hallelujah!

I really wasn’t looking forward to starting every HTML5 workshop, presentation or article with the words, “Despite what the W3C says, HTML5 is not a meaningless buzzword…” Now I can safely say that the term “HTML5” refers to a technical specification, published at the W3C, called HTML5. Also, I can use that nice logo with a clear conscience.

Over time though, I’ll probably follow the WHATWG’s lead and simply talk about “what’s new in HTML.” As Remy points out, there are pedagogical advantages to untethering version numbers:

I don’t have to answer “Is HTML ready to be used?” ‘cos that’s a really daft question!

• Webmonkey: HTML5 Gains Logo, Loses Meaning

  It doesn’t really matter if the New York Times thinks CSS 3 or SVG are HTML5, but we’d like to think that at least the organization in charge of describing what is, and is not, HTML5 would make some effort to distinguish between tools. Lumping everything together is as silly as a carpenter referring to every tool in their toolkit as “a hammer.”

• CNET News: W3C’s new logo promotes HTML5—and more

  Curiously, though, the standards group—the very people one might expect to have the narrowest interpretation of what exactly HTML5 means—instead say it stands for a swath of new Web technologies extending well beyond the next version of Hypertext Markup Language.

• GigaOM: The Truth Behind HTML5′s New Logo Fiasco

  It’s as if the government suddenly announced that from today, all vegetables will be called potatoes, just because some vegetables are potatoes.

• The Register: W3C tackles HTML5 confusion with, um, more confusion

  And much like Apple, Google, and Microsoft before it, the organization that oversees HTML5 has confused it with all sorts of other web standards.

• The Web Standards Project: HTML5 logo: be proud, but don’t muddy the waters!

  Now the W3C has come out and essentially condoned the branding of everything from CSS to actual HTML5 to WOFF as “HTML5”. We can’t imagine a single action that will cause more confusion than this misguided decision (and the W3C has produced some pretty impenetrable specs in its time)

• Roger Johansson: HTML5 now includes CSS3, SVG and WOFF?

  This move from the W3C will not help people differentiate between very different technologies.

• CSS Squirrel: HTML5 Super Friends Assemble!

  The logo is pretty, but the intentional use of HTML5 as a blanket term for other modern web technologies is a crock. Newspapers making merry with the term is one thing, but a web standards organization?

The W3C have unveiled a logo for HTML5. I’m not sure the world needs such a logo, but I think it looks pretty good. It reminds me of some of the promotional materials used by the Web Standards Project back in the day—simple bold lines that work well at small sizes, with a whiff of Russian constructivism.

But I take issue with the scope of what this logo is supposed to represent. From the Frequently Asked Questions:

The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.

What. A. Crock.

What we have here is a deliberate attempt to further blur the lines between separate technologies that have already become intertwingled in media reports.

Don’t get me wrong; I don’t mind if marketers and journalists use HTML5 to mean everything under the sun, but I expect working web developers to be able to keep specs separate in their mind. If Apple or Google were pushing this kind of fuzziness, I wouldn’t mind …but this is coming straight from the horse’s mouth (or, in this case, straight from the horse’s ass).

“But,” cry the cheerleaders of ambiguity, “we need some kind of term to refer to HTML5 plus CSS3!”

Citation needed.

We never needed a term to refer to “XHTML 1.0 plus CSS2.1” or “HTML4.01 plus JavaScript” or “any combination of front-end technologies.” Why this sudden all-conquering need for a term that covers so many different technologies as to be completely meaningless? As I said before:

Clarifying what is and isn’t in HTML5 isn’t pedantry for pedantry’s sake. It’s about communication and clarity, the cornerstones of language.

But I guess I’ve lost that battle. Now even the W3C are intent on blurring the distinction between different technologies to the extent that using a particular font file format qualifies as HTML5.

So now what do I do when I want to give a description of a workshop, or a talk, or a book that’s actually about HTML5? If I just say “It’s about HTML5,” that will soon be as meaningful as saying “It’s about Web 2.0,” or “It’s about leveraging the synergies of disruptive transmedia paradigms.” The term HTML5 has, with the support of the W3C, been pushed into the linguistic sewer of buzzwordland. Instead, I will try using phrases:

• “HTML5, no really”,
• “The parts of HTML5 that are documented in the specification labelled HTML5”,
• “Actual HTML5”

But I think the term that’s going to be most accurate is:

• “HTML”

Update: The W3C have changed their mind. Yay!

It’s been a strange week in HTML5. The web—and Twitter in particular—has been awash with wailing and gnashing of teeth as various people weigh in with their opinions on either the W3C or the WHATWG—depending on which camp they’re in—being irreversibly broken …exactly the kind of ludicrous over-reaction at which the internet excels.

This particular round of chicken-littling was caused by the shuffling of some spec components. The W3C HTML Working Group recently decided to split microdata into a separate specification (which I think is fair enough given RDFa’s similar status). Hixie then removed some other parts of HTML5; a move which was seen as a somewhat petulant reaction to the microdata splittage. Cue outfreakage. Before too long, most of the changes were rolled back.

So all of the shouting and arguing was more about politics and procedure than about features or semantics. That’s par for the course when it comes to the HTML Working Group at the W3C; the technical discussions are outweighed by the political and procedural wranglings. But that’s the nature of the beast. Hammering out a standard is hard. Building consensus is really hard. The chairs of the working group face an uphill struggle every single day. Still, that’s a far cry from declaring the whole thing a waste of time.

As Tantek points out, if the HTML5 shenanigans seem particularly crazy, that’s only because they are that much more public than most other processes:

The previous several revisions of HTML (including XHTML) were largely developed in W3C Members-Only mailing lists (and face-to-face meetings) which contained a lot of similar “corporate politics, egotism, squabbles and petty disagreements” - however such tussles were invisible to search engines, the general public, and of course all the professional web developers and designers (like yourself) - you never saw how the sausage was made as it were.

Tantek was responding to a post by Malarkey who advises us to keep calm and carry on. That’s sensible advice, although he gets some push-back in the comments from people concerned about a market-led approach to web standards, wherein we only care about what browsers are implementing, not what’s enshrined into a standard.

It’s easy to polarise this issue into a black and white dichotomy: implementation first vs. specifications first. The truth, as always, is much more nuanced than that, as beautifully summed up by Rob O’Callahan:

Implementations and specifications have to do a delicate dance together. You don’t want implementations to happen before the specification is finished, because people start depending on the details of implementations and that constrains the specification. However, you also don’t want the specification to be finished before there are implementations and author experience with those implementations, because you need the feedback. There is unavoidable tension here, but we just have to muddle on through … I think we’re doing OK.

I think we’re doing OK too.

Not that I’m not immune to HTML5-related temper loss. Most recently, I was miffed with the WHATWG rather than the W3C but once again, it was entirely to do with specification organisation rather than specification contents.

The WHATWG have never been comfortable with the term HTML5 to describe the work they’re doing, which began life as Web Apps 1.0. The very idea of version numbers is anathema to their philosophy so they’re quite happy for the W3C to own the term HTML5 to describe a particular set-in-stone markup spec. But they still need a word to describe the monolithic ongoing WHATWG spec.

Historically, the term HTML5 was a pretty good fit for the WHATWG spec and it corresponded exactly with the W3C spec (in fact, the W3C spec is generated from the WHATWG spec). But Hixie declared Last Call for the WHATWG HTML5 spec a while back. That means that the specification at the WHATWG and the specification at the W3C can now diverge—the WHATWG spec contains everything in HTML5 and then some. To continue to label this WHATWG spec as simply HTML5 would be misleading. So a few weeks ago, the name of the spec changed from HTML5 to WHATWG HTML (including HTML5).

Accurate as that designation may be, I became very concerned about the potential confusion it would cause. Any front-end developer reading a document titled WHATWG HTML (including HTML5) might reasonably ask Oh, which bits are HTML5? …a question to which there’s no easy answer because at the WHATWG, the term HTML5 is seen as little more than a buzzword. In that sense, they share PPK’s assertion that HTML5 means whatever you want it to mean.

I was particularly concerned that the short URL http://whatwg.org/html5 would redirect to a document that wasn’t called HTML5. I could point developers at this diagram but I’m not sure that it would make things any clearer.

Things got fairly heated in the IRC channel as I argued for either a different redirect or a better document title. I understand why the WHATWG need to transition from using the term HTML5 to simply using the term HTML to describe their all-encompassing ongoing work, but flipping that switch too soon could cause a lot pain and confusion. A gradual evolution of titles reflecting the evolution of the contents seems better to me:

1. HTML5
2. HTML5 (including next generation additions still in development)
3. WHATWG HTML (including HTML5)
4. WHATWG HTML

Hixie made the change. The title of the WHATWG specification is currently at step 2. I think this will make things a lot clearer for authors.

• Anyone looking for the specification that will become a W3C candidate recommendation called HTML5 should look at the W3C site: http://dev.w3.org/html5/spec/.
• Anyone looking for the ongoing evolving specification that HTML5 is a part of should look at the WHATWG site: http://whatwg.org/html5.

I’m happy that this has been cleared up and yet I hope that smart, savvy front-end developers who have read this far will think that I’ve just wasted their time. That would be a healthy reaction to reading a bunch of irrelevant guff about what specifications are called and how they are organised. Your time would be far better spent implementing the specifications and providing feedback.

That’s certainly a far better use of your time than simply shouting FAIL!

Update: And, right on cue, Mark Pilgrim updates the WHATWG blog to explain the spec name change.

Keeping up with HTML5 can seem like a full-time job if you’re subscribed to both the W3C public-html list and the WHATWG mailing list.

If you have to choose just one, the WHATWG list is definitely the red pill. The W3C list has a very high volume of traffic, mostly about politics and procedure. Sam Ruby deserves a medal for keeping the whole thing on an even keel.

The WHATWG list, on the other hand, can get pretty nitty-gritty in its discussions of Web Workers, Offline Storage and other technologies that are completely over my head.

The specification itself is shaping up nicely. My list of bugbears is getting shorter and shorter:

1. I’m still not convinced that the article element is necessary, given that it is almost indistinguishable from section. Having two very similar elements is potentially very confusing for authors. It’s hard enough deciding the difference between a section and a div.
2. The time element is still unnecessarily restrictive. I don’t just mean that it’s restrictive in the sense that you can’t mark up a month, the very definition is too narrow. I hoisted the HTML5 spec by its own petard recently, pointing out that a different portion of the spec violates the definition of time.
3. The cite element is also too restrictively defined, and in a backwards-incompatible way to boot. I’ve written more about that over on 24 Ways.

There are much bigger issues than these still outstanding—mostly related to the accessibility of audio, video and canvas—but I’ll leave it to smarter people than me to tackle those. My issues all revolve around semantics and, let’s face it, they’re kind of piddling little problems in the grand scheme of things.

On the whole, I’d say the spec is looking mighty fine. Most of it is ready for use today.

I think the next big challenge for HTML5 lies with the tools. It’s great that we’ve got a validator but what we really need is a lint tool—something like JSlint but for checking markup writing style: case sensitivity of tags, quotes around attributes, that kind of thing. Robert Nyman concurs.

Let be clear: I’m not talking about a validator that checks for polyglot documents i.e. HTML that can also be parsed as XML. I’m talking purely about writing style and personal preference; a tool that will help enforce an in-house style guide of arbitrary “best” practices.

I’ve impressed this upon Henri in IRC on a few occasions. He has explained to me that it’s not so easy to build a true syntax checker …and no, you can’t just use regular expressions.

Still, I think that there would be enormous value in having even an imperfect tool to help authors who want to write HTML5 right now but also want to enforce a strict syntax on themselves. A working rough’n’ready lint tool that catches 80% of the most common gotchas is better than a theoretical perfect tool that will work 100% of the time but that currently works 0% of the time because it doesn’t exist yet.

Anybody want to step up to challenge?

Looking through the list of hiccups highlighted by the HTML5 Super Friends and my own personal tally, things are progressing at a nice clip with HTML5.

• The pubdate attribute has been removed from the article element and shifted to a nested time element instead.
• The content model for the footer element has been changed to match author expectations—that’s a biggie.

That still leaves a few issues:

• The confusion between section and article that I’ve been researching.
• The restrictive content model of the small element not matching that element’s updated semantics.
• The time element not allowing month or year dates i.e. YYYY-MM or YYYY.

Then there’s the issue with details and figure. The insistence on recycling the legend element leads to all sorts of problems with browsers today, as described by Remy.

This has been an ongoing discussion in the HTML5 IRC channel and on the HTML5 mailing lists. It flared up again recently and I fired off an email to the HTML Working Group yesterday:

I understand the aversion to introducing a new element … but I don’t understand why legend is being treated as the only possible existing element to recycle.

For example, dt and dd are being recycled in the new context of dialog so they no longer mean “definition title” and “definition description”. Now they can also mean (presumably) “dialog title” and “dialog description”.

If those elements are already being recycled, why not apply the same thinking to details so that dt and dd could also mean “details title” and “details description”?

To be honest, I was just spouting that out without really thinking. How about… something like—not this, obviously, not this, but what if…

So imagine my surprise when Hixie responded:

That’s not a bad idea actually. Ok, done.

Wow. Okay.

While I was at it, I also did this for figure

Alright. Makes sense, I suppose …although the names of the elements dt and dd aren’t quite as intuitive in the context of figure as they are in details.

and removed dialog from the spec altogether.

Er …okay. Seems somewhat unrelated to the issue at hand but I guess that the dialog element has been a point of contention. It’s mentioned by the HTML5 Super Friends so that’s another one that we can tick off the list.

So how should we mark up conversations now? Here’s what the spec now suggests:

Authors who need to mark the speaker for styling purposes are encouraged to use span or b.

Um… what? The b element? Really? You have got to be kidding.

Excuse me while I channel Carrie’s mother, but I can predict exactly how authors are going to react to this advice: They’re all going to laugh at you!

@gcarothers: Jaw, floor, WHAT?! http://bit.ly/48Bhta Why in the world would #html5 suggest using <b> tags to markup names?

@akamike: There are more appropriate tags than <b> for marking up names in conversations. “The b element should be used as a last resort…” #html5

@cssquirrel: Well, if the <p><b> recommendations for dialog in #html5 persist for a week, I know what I’m drawing.

Perhaps now would be a good time to mention that the cite element is also listed by the HTML5 Super Friends. Call me crazy but I think it might just be the right element for marking up the person being cited.

<p> <cite>Costello</cite>: <q>Who's playing first?</q> </p>
<p> <cite>Abbott</cite>: <q>That's right.</q> </p>

I can never pinpoint the exact moment at which I “get into” a particular technology. CSS, DOM Scripting, microformats …there was never any Damascene conversion to any of them. Instead, I’d just notice one day, after gradually using the technology more and more, that I was immersed in it.

That’s how I feel about HTML5 now.

There’s another feeling that accompanies this realisation. I remember feeling it about CSS in the late 90s and about DOM Scripting half a decade ago. At the same time as I look up from my immersion, I cast a glance around the web development landscape and ask Why aren’t more people paying attention to this?

In the case of HTML5, this puzzling state of affairs can, to a large extent, be explained by the toxic 2022 meme. Working web developers with an idle interest in HTML5 would google the term, find a blog post telling that it won’t be “ready” until 2022, and then happily return to their work, comforted by the knowledge that HTML5 was some distant dream on the horizon—one that doesn’t affect them in any way today.

Nothing could be further from the truth. The Last Call Working Draft status is (optimistically) planned for October; that’s one month away.

And what rough beast, its hour come round at last, slouches towards Bethlehem to be born?

If you want to have a say in the formation of the most important web standard in existence, don’t put off getting involved. As Bruce says, If you don’t vote, you can’t bitch.

Still, I think the attitude of most web developers towards HTML5 right now is, at the very least, “interested, if a little sceptical”—that’s certainly how I felt when I started dabbling in it.

A little while back, I got together with some of my interested (if a a little sceptical) colleagues in New York, thanks to a generous invitation from Zeldman.

After a fairly intense two days of poring over the spec, I think it’s fair to say that, on balance, the interest increased and the scepticism decreased. That’s not to say that everything looks rosy in the current incarnation of HTML5. When you’ve got some of the smartest front-end web developers I know of in the same room together and they all agree that some parts of the spec are confusing or downright wrong, that’s quite worrying.

On the plus side, most of the issues are pretty minor in the grand scheme of things. It’s fair to say that most of the stuff that interests web authors—the semantic side of things—only accounts for a small part of HTML5. Most of the HTML5 specification is about error handling, APIs and shiny new interactive content. There are plenty of programmers and browser makers forging those powerful new tools. But as qualified as they are to hammer out those complex constructs, they are not necessarily the most qualified to make decisions on creating new structural elements. For that, you need the input of authors. And authors have been decidedly slow to get involved with HTML5.

It’s time for authors to get involved. I believe our voices will be welcomed. According to the HTML design principles:

…consider users over authors over implementors over specifiers over theoretical purity.

I’ll get the ball rolling with my own little list of things that are troubling me…

small

I’m with Bruce and Remy. If the small element is being redefined for disclaimers, caveats, legal restrictions, or copyrights, it needs to be handling how that kind of content is published in the wild. That means it needs to be able to wrap paragraphs, lists and other flow content.

Alternatively, it should go the way of its evil twin, the big element, and simply be deprecated …sorry, I mean .

time

I’ll join in the chorus of people who think that the restrictions on the information that the new time element can contain are unnecessarily draconian. You can encode a date and time, you can encode a date, but you can’t encode just a month and a year. So you can’t make a piece of information like “April 1912” machine-readable. The spec says the time element:

…is intended as a way to encode modern dates and times in a machine-readable way

Which is great. But the sentence doesn’t finish there. It goes on:

so that user agents can offer to add them to the user’s calendar.

That’s one use case! I don’t think it’s wise to rain on the parade of anyone wanting to build, say, timeline mashups. Trying to mandate use cases ahead of time is not just counter-productive, it’s probably impossible. Can you imagine if Flickr had launched their API with strict instructions that it could only be used for one particular purpose?

figure

I have nothing against the figure element itself, although it does seem uncomfortably close to aside, but the insistence on recycling the legend element to handle the caption is problematic.

Don’t get me wrong: I’m all for re-using existing elements rather then creating new ones, and I know that Hixie looked at all the options. But the way that browsers currently treat the legend element makes it unusable outside of a form.

I think that the label element could work instead.

details

Just like figure, the details element reuses legend. In this case, label won’t do the trick. details is an interactive element and it doesn’t look like the label element can be made keyboard accessible.

In this case, as undesirable as it is, a new element may be called for.

article

I’ve got two issues with the article element.

1. Firstly, its definition sounds awfully similar to section. I’m not convinced that there needs to be two different elements. Having two elements that look like a duck, walk like a duck and quack like a duck is just going to lead to confusion amongst authors wondering which duck to use.

2. The article element, unlike the section element can take an optional pubdate attribute to encode the publication date. I’m all in favour of having this information be machine-readable but the pubdate attribute smells like dark data, subject to metacrap rottage. In most cases, the publication date will be repeated in the content of the article anyway, so I’m in favour of adding a flag there rather than duplicating data. A Boolean pubdate attribute on a time element within an article header or footer should do the trick.

Speaking of footer, this one is the biggie…

footer

There is a big disconnect between what the HTML5 spec calls a footer and what authors on the web call a footer.

According to the spec, you’re only supposed to put some kinds of content inside a footer:

Flow content, but with no heading content descendants, no sectioning content descendants, and no header or footer element descendants.

That means no nav or headings in footer. The way that the footer element is defined in the spec, it’s a slightly more expanded version of address.

Ah, address! One of the most problematic elements in HTML 4. It is often incorrectly used to mark up street addresses. But is it any wonder? When an element has a name address, it’s hardly surprising that authors are going to use it for marking up addresses. The same thing is going to happen with footer.

The term “footer” was not invented for HTML5. It’s been in use on the web for years and in print for even longer. But if you ask any author to define what they mean by the term “footer”, you’ll get a very different definition to the one in the HTML5 spec. They may even point to specific examples of footers on sites like Flickr or on blogs, where they contain headings and navigation.

To be fair, when the new structural elements were being forged back in 2005, there wasn’t as much prevalence of what Derek Powazek termed fat footers. So when Hixie ran his analytics on a shitload of web pages crawled by Google and found that “footer” was by far the most common class name, most footer content was pretty meagre. But usage changes (see also: time).

The way that the element named footer is defined in HTML5—to be used multiple times in a single document in sections and articles as well as at the document level—is very different from the convention named footer in common usage on the web today. Most of the instances of what authors call a footer are more like what the HTML5 spec defines as aside.

I don’t want to spend the next decade telling authors not to mark up their footers as footers. It was bad enough telling people not to mark up addresses as addresses. In any case, authors aren’t going to listen. If they see there’s an element called footer, they will assume it refers to the device known as a footer, and mark up their content accordingly. At that point, the HTML5 spec will have become a work of fiction instead of documenting what’s actually on the web.

One of two things needs to happen. Either:

1. The content model of footer is updated to match that of header, which is much more liberal in what it accepts, or:
2. The name of the element currently called footer should be changed to match the current, restrictive definition. I suggest using contentinfo, which is the name of an existing ARIA role for exactly this kind of content.

ARIA roles, by the way, are an excellent addition to HTML5. ARIA integration is a win for ARIA and a win for HTML5, in my opinion. Most of all, it’s a win for authors who now have a whole swathe of extra semantics they can sprinkle into their documents (and use as styling hooks with attribute selectors).

Thus endeth my list of things I want to see fixed in HTML5. I’m leaving out the massive issue of canvas accessibility because:

1. that’s beyond my area of expertise,
2. smarter people than me are working on it, and
3. I think that canvas would probably benefit from being spun off into a separate spec.

There are other little things that bother me in HTML5—hgroup smells funny, cite shouldn’t be restricted to titles of works, and I miss the rev attribute on links—but those are all personal foibles; opinions unsupported by data. I’d rather concede than argue without data.

Because, make no mistake, data is what’s needed if you want to affect change in HTML5. Despite the attempts to paint Hixie as a stubborn, opinionated dictator, he is himself a slave to data. He shows an almost robot-like ability to remove his own ego from a debate and follow where the data leads.

If you are an author of HTML documents, I strongly encourage you to get involved in the HTML5 process.

1. Read the spec.
2. Join the mailing list.
3. Hang out in the IRC channel.

Like I said, most of the spec and discussion is about APIs rather than semantics, but it’s precisely because the spec isn’t directly aimed at authors that authors need to get involved.

HTML5 is a strange character with what appears to be a split personality. Hardly surprising then that something so divided would appear to be so divisive.

First of all, there’s the spec itself.

The specification

HTML5 walks a fine line between maintaining backward compatibility with existing markup and forging the way as a modern, updated specification for the future. If it strays too far in paving the cowpaths and simply codifies what authors already publish, then the spec would mandate using tables for layout and font elements for presentation because that’s still what most of the web does. On the other hand, if it drifts too far in the other direction, the result will be something as theoretically pure but as practically useless as XHTML2.

The result is that HTML5 appears to be a self-contradictory mess. But it’s hard to imagine a successful web technology that isn’t a mess. That’s because the web itself is a mess. Clay Shirky described exactly how messy it is back in 1996:

The server would use neither a persistent connection nor a store-and-forward model, thus giving it all the worst features of both telnet and e-mail.

The hypertext model would ignore all serious theoretical work on hypertext to date. In particular, all hypertext links would be one-directional, thus making it impossible to move or delete a piece of data without ensuring that some unknown number of pointers around the world would silently fail.

And yet the web succeeded because:

…of the various implementations of a worldwide hypertext protocol, we have the worst one possible.

Except, of course, for all the others.

…a reference to Churchill’s oft-cited maxim that:

…democracy is the worst form of government except all the others that have been tried.

Which brings us nicely to the subject of governance and process, another area where HTML5 appears to be split.

The process

Democracy—or at least, consensus—drives the process of most W3C specs. But HTML5 isn’t just being developed at the W3C. HTML5 is also being developed by the WHATWG. Sounds crazy, doesn’t it? The reasons for the split are historical—the W3C rejected HTML as the future of the web in 2004 so the WHATWG started their own work and then the WC3 had a change of heart in 2007. Hence the parallel development. It turns out to be a pretty good system of checks and balances. The editors on the WHATWG side—Ian Hickson and Dave Hyatt—are balanced by the chairs on the W3C side—Chris Wilson and Sam Ruby.

The WHATWG process isn’t democratic. There’s no voting on issues. Instead, Hixie acts as a self-described benevolent dictator who decides what goes into and what comes out of the spec. That sounds, frankly, shocking. The idea of one person having so much power should make any right-thinking person recoil. But here’s the real kick in the teeth: it works.

In theory, a democratic process should be the best way to develop an open standard. In practice, it results in a tarpit (see XHTML2, CSS3, and pretty much any other spec in development at the W3C—not that the membership policy of the W3C is any great example of democracy in action).

In theory, an unelected autocrat having control of a specification is abhorrent. In practice, it works really, really well …if it’s the right person.

That’s always been the case with benevolent dictatorships. The populace transfers moral responsibility to the Leviathan of the state, personified by an-powerful ruler like Shakespeare’s Henry V:

If his cause be wrong, our obedience to the King wipes the crime of it out of us.

That’s a lot of responsibility for one person to carry. Remarkably, Hixie carries the weight with exceptional disinterest and a machine-like even-handedness:

Let it be said that Ian Hickson is the Solomon of web standards; his summary of the situation is mind-bogglingly even-handed and fair-minded.

But it doesn’t always seem that way to those on the outside looking in at the HTML5 process. Debates around the summary attribute or RDFa might well give the impression that Hixie is ignoring voices in opposition. Nothing could be further from the truth. The real challenge is in finding good solutions to problems, and sometimes that doesn’t necessarily mean using an existing solution—despite the pave the cowpaths mantra.

If you have a potential solution to a problem in HTML5, the way to present it is with data. If you don’t have the data, then maybe it isn’t such a good solution. I’ve experienced this myself with the rev attribute, which has been removed from HTML5. I think it should remain. I think it’s a potentially powerful attribute. But I can’t argue with the data. My personal preference isn’t a good enough reason to keep it (‘though I may occasionally tip out some beer to honour its memory).

The irony is that HTML5 has the reputation of being a spec beyond the influence of the average web developer when in fact it has the most open process of any web standard. If you want to have a say in the development in CSS3… well, good luck with that. If you want to have a say in the development of HTML5, you can.

Unlike just about every other W3C activity, the HTML working group is open to the public. You can join in as a public invited expert—except you don’t actually get invited. Instead you’ll need to complete this three-step process:

1. Sign up for an account with the W3C.
2. Fill in the invited expert application—you’ll need your W3C credentials to do this.
3. Fill in the form for joining the HTML working group.

But a lot of the activity on the W3C side of things is very much about the process of developing a spec; voting, consensus and meetings. To have your say in putting the content of the HTML5 spec together, join in the WHATWG activities.

• Anyone can join the WHATWG mailing list.
• Anyone can join in the discussions on IRC.
• Anyone can edit the wiki.

Two words of warning…

Firstly, time is of the essence. HTML5 is due to enter Last Call Working Draft in October of this year. From then it’s going to be a race towards Candidate Recommendation in 2012. If you want to influence this spec, now is the time to get involved. Don’t wait. The FUD around the boogieman date of 2022 is proving to be a particularly virulent meme that web developers have latched on to as an excuse for not caring about HTML5.

Secondly, you might be surprised by the contents of the specification. This is yet another area where HTML5 displays a split personality.

The feature set

Traditionally, HTML has been a format for semantically marking up hypertext—the clue is in the name. That’s still true but HTML5 is also a format for creating web applications; the WHATWG work that became HTML5 started life as a spec for web apps. This means that a lot of the discussions on the mailing list are about APIs, DOM trees, and some fairly code-heavy stuff around canvas and video. Discussions of the semantics of new structural elements like header, footer and article aren’t nearly as prevalent—all the more reason for working web developers to get involved in the process.

The truth is that much of the HTML5 spec isn’t aimed at web developers at all; it’s aimed at browser makers. This has fostered some conspiracy theories about how browser makers are controlling the spec but the truth is that browser makers have always had the final say in what gets implemented. It doesn’t matter how perfect a web standard is if nobody can use it. Hixie, for all his apparent power, acknowledges this:

I don’t want to be writing fiction, I want to be writing a spec that documents the actual behaviour of browsers.

Fortunately we don’t have to wade through a spec aimed at browser makers. Michael Smith has taken all the author-specific parts of HTML5 and published them in a parallel document: HTML5: The Markup Language.

Sam Ruby tells of a useful distinction drawn up by TV Ramen of the kind of new features we’re seeing in HTML5:

extending the platform vs. extending the language.

The first type of feature is something that requires significant effort from browser makers; canvas, video, and all the new APIs. The second type of feature is something that requires very little effort from browser makers but is enormously significant for authors; header, footer, article, etc.

The diagnosis

HTML5 is the web equivalent of a circus tightrope act, performing equal feats of balancing and juggling

• backward compatibility with shiny new features,
• W3C consensus with WHATWG benevolent dictatorship,
• and new browser features with new semantics.

It’s hardly surprising that such a schizophrenic spec can seem so confusing. If you spend some time immersing yourself in the world of HTML5, most of this confusion will evaporate. If symptoms persist, I recommend consulting the HTML5 doctor.

The French Revolution was an uprising in extremis (in contrast to The Glorious Revolution). We all know about the storming of the Bastille but the revolutionaries didn’t stop at regime change. They also introduced their own calendar. While I personally might find decimal time to be a splendid idea, it was doomed to failure. It required the existing system to change too much too quickly.

I was reminded of this over the past week as I watched a fever of clock-smashing fervour sweep the world of web standards.

It all began with Håkon’s open letter to the Web community wherein he justifies Opera’s antitrust complaint with the EU. This justification revolves around conflating Internet Explorer’s market dominance with its relative lack of standards support. But for the purposes of an antitrust complaint, these aspects are entirely unrelated. If Microsoft is abusing its market dominance to push its own web browser, that’s one issue. If that web browser happens to be sorely lacking in standards support, that’s a separate issue. Eric has already called them on this—if the issue were really one of standards-compliance, the time for action was when IE6 was languishing in the doldrums, not after the release of IE7 which shows Microsoft is at least back on track:

What I’m advocating is that rather than attacking the laggard right when he’s showing promise of catching up and being part of the team again, it might be better to help him along, maybe even say a few words of encouragement. Unless, that is, this attack springs out of some sort of perceived threat—in which case, just say so, and don’t use web standards as a fig leaf.

If I were cynical, I might suggest that Opera’s mashup of issues is a ploy to manipulate the emotions of web developers who care about standards. But I don’t think that’s the case. Håkon is passionate about web standards—one of the most passionate advocates I’ve met—and I believe that his intentions are honourable. I think he honestly believes that Opera’s actions are in the best interests of the Web. It’s just a shame that, in making his case, he has muddied two separate but important issues.

Spurred on by Håkon’s call to arms, Malarkey predicts a riot and proceeds to lob a brick through the window of the W3C. He outlines his plan for the CSS Working Group equivalent of a decimal clock as one in which browser manufacturers—the people who actually implement the specs—aren’t invited. He cites the situation between Opera and Microsoft:

What I am concerned about is how Opera’s action will further destabilize the W3C’s CSS Working Group of which both Opera and Microsoft post representatives. I am concerned that this action will irrevocably damage the promise and progress of CSS3.

But, as Zeldman points out, this connection is tenuous at best:

Apple and Microsoft and Netscape and Sun and Opera have been suing each other since the W3C started. What lawyers do has never stopped developers from Apple and Microsoft and Netscape and Sun and Opera from working together to craft W3C and ECMA specs.

The next bit of clock-smashing comes from Alex who cries from the barricades that The W3C cannot save us!

Alex solves the kinds of problems that us mere mortals haven’t even recognised as being there. He’s constantly thinking a few years ahead of the rest of us. No surprise then that his frustrations are magnified by his time-travelling perspective. His takeaway soundbite quote is this:

In order for the future to be better by a large amount, it must be different by a large amount.

He is absolutely right. But here’s the thing… I don’t want the future to change by a large amount. The present isn’t that bad. HTML is good enough. CSS is not bad. JavaScript is okay. Yes, I’d like to see improvements. Yes, I’d like to see innovation. But not at the expense of interoperability. I’m certainly not in a hurry to return to the bad old days of the browser wars, which is the very thing that Alex thinks is required to drive innovation.

I suspect that the frustrations felt by Jeff and others are on a different scale to what Alex is talking about. We don’t want the decimal clock of some brave new browser war; we’re just looking for the Gregorian reform of CSS3 with its multiple background images, embeddable fonts and other shiny goodness.

Alex sets up a false dichotomy by suggesting that change must either come from a standards body (something he believes is impossible) or it must come from browser vendors. The truth is that both are possible, as evinced by namespaced CSS rules or, on a more extreme scale, the success of the proprietary XMLHttpRequest object.

While acknowledging the truth in Alex’s frustrations, Stuart sums up the problem with his proposed solution:

Let us not forget that the problem with the browser wars wasn’t that it fragmented the world in lots of different directions. The problem with the browser wars was that it fragmented the world in lots of different directions that weren’t possible to eventually implement everywhere.

I fear that a new wave of browser wars would lead to an ascendancy of Robespierres and, inevetiably, Napoleons.

Lest you think I’m being a W3C apologist here, let me make it clear that I am as frustrated as any other web developer at the glacial pace of the CSS Working Group and the lack of progress with CSS3. I just don’t think we need to dump the baby out with the bathwater. I think we can avoid any water disposal related infanticide by just changing what needs to be changed.

I think we can all agree that we’d like to see more transparency and movement from the Working Group. I don’t think we can avoid the process being a “battlefield”, an idea that many find distasteful but which is inherint to any heterogeneous body. It would be a wonderful world indeed in which Parliament, Congress and the United Nations never had to deal with heated disagreement. Disagreement isn’t a reason for abolishing these bodies; it’s the reason they exist in the first place.

It looks like all the recent sound and fury is starting to have an effect. David Baron is taking a stand from within:

I’ve informed the CSS working group that I am no longer participating in member-only mailing lists or meetings. I believe the member-confidential nature of the group hurts the future development of CSS.

Change is needed. It looks like change is coming. It may even be a regime change. But let’s not start drawing up new calendar systems just yet. The clock of CSS is running slow. We need to wind it up. That doesn’t mean we need to smash it.

Day one of Fundamentos Web just wrapped up here in Gijón.

I got my talk out of the way pretty early on: I was the second speaker, right after Bert Bos. He invented CSS; I… um… build websites… sometimes.

Not everyone was listening to the simultaneous translation. I estimated that less than 50% of the audience were wearing headphones (I’m assuming that they weren’t all listening to their iPods). Either way, I made a conscious effort to speak slowly. In fact, I overdid it a bit and over-ran. If recollection serves, that’s something I’ve never done before.

I played it pretty straight, leaving out a lot of jokes and culturally-specific references. I couldn’t tell whether the audience was completely bored or just paying close attention. People came later and told me they liked it so I hope it was the latter.

One person who told me that I made Ajax understandable was my interpreter. I thanked her for the compliment but I was kind of surprised. When I’ve talked to interpreters, I got the impression that the key to simultaneous translation is to become a conduit—to remove yourself (literally your “self”) from the equation. So I’m amazed that my interpreter, Priscilla, was able to translate and pay attention to the content at the same time. But then, I’m somewhat in awe of the ability to do simultaneous translation. As Priscilla said, when it’s done really well, it’s invisible—kind of like what Jared says about good design.

I wonder how Priscilla managed to cope with the talk after mine. If you’ve ever seen Jeff Veen talk, you’ll know that he’s quite animated. I must find out how she translated “Tingle Fizz.” Jeff managed to out-do my pitiful attempt at localisation: I just translated some slides; he gave a short speech in Spanish (although that’s still not quite as impressive as Joe’s Icelandic benediction).

The day wrapped up with an impressive panel of representatives from browser vendors: Microsoft, Mozilla, Opera, Konquerer and Nokia, moderated by Bert.

I noticed a certain dichotomy in the panel (dichotomy is a milder word than hypocrisy).

There was a lot of talk about standards and innovation and debates about what features browsers should implement. The general concensus was that browsers should implement what the developers are asking for… or, even better, implement what developers are actually doing.

That’s fine. It sounds great in theory. But the reality that I saw was that each browser vendor had their own hobby horse. For some, it was SVG. For others, it’s canvas. The actual technology is irrelevant. That reality conficts with the theory: instead of implementing what’s relevant, browser vendors sometimes push their own agendas. That’s all well and good but the real problem arises because those browser makers are W3C contribitors. Those hobby horses don’t get checked at the door. The result is that browser verndor politics end up having a big influence on the W3C process—they become W3C politics. And who gets the blame? The W3C.

I started typing this in the hotel bar in Gijón and, as I was writing, the browser representatives one-by-one showed up. So now I’ve ended up having this rant IRL as well as having a good ol’ blog rant.

Ah, that feels better.

Update: You can download the slides of my presentation and scoff at my attempts at localisation.

XTech 2006 is over and with it, my excursion to Amsterdam.

All in all, it was a good conference. A lot of the subject matter was more techy than I’m used to, but even so, I found a lot to get inspired by. I probably got the most out of the “big picture” discussions rather than presentations of specific technology implementations.

Apart from my outburst during Paul Graham’s keynote, I didn’t do any liveblogging. Suw Charman, on the other hand, was typing like a demon. Be sure to check out her notes.

The stand-out speaker for me was Steven Pemberton of the W3C. He packed an incredible amount of food for thought into a succinct, eloquently delivered presentation. Come to think of it, a lot of the best stuff was delivered by W3C members. Dean Jackson gave a great report of some of the most exciting W3C activities, like the Web API Working Group, for instance.

I had the pleasure of chairing a double-whammy of road-tested presentations by Tom Coates and Thomas Vander Wal. I knew that their respective subject matters would gel well together but the pleasant surprise for me was the way that the preceding presentation by Paul Hammond set the scene perfectly for the topic of open data and Web Services. Clearly, a lot of thought went into the order of speakers and the flow of topics.

Stepping back from the individual presentations, some over-arching themes emerge:

• The case for declarative languages was strongly made. Steven Pemberton gave the sales pitch while the working example was delivered in an eye-opening presentation of Ajax delivered via XForms.

• Tim O’Reilly is right: data is the new Intel Inside. Right now, there’s a lot of excitement as to do with access to data via APIs but I think in the near future, we might see virtual nuclear war fought around control for people’s data (events, contacts, media, etc.). I don’t know who would win such a war but, based on Jeffrey McManus’s presentation, Yahoo really “gets it” when it comes to wooing developers. On the other hand, Jeff Barr showed that Amazon can come up APIs for services unlike any others.

• Standards, standards, standards. From the long-term vision of the W3C right down to microformats, it’s clear that there’s a real hunger for standardised, structured data.

Put all that together and you’ve got a pretty exciting ecosystem: Web Services as the delivery mechanism, standardised structures for the data formats and easy to use declarative languages handling the processing. Apart from that last step — which is a longer-term goal — that vision is a working reality today. Call it Web 2.0 if you like; it doesn’t really matter. The discussion has finally moved on from defining Web 2.0 to just getting on with it (much like the term “information architecture” before it). The tagline of XTech 2006 — Building Web 2.0 — was well chosen.

But the presentations were only one part of the conference. Just like every other geek gathering, the real value comes from meeting and hanging out with fellow web junkies who invariably turn out to be not only ludicrously smart but really, really nice people too. It helps that a city like Amsterdam is a great place to eat, drink and talk about matters nerdy and otherwise.