Interview with Robin Berjon, HTML5 editor

by .

At the recent Apps World expo in London, Doctor Bruce spoke on a panel with Robin Berjon, recently appointed W3C HTML5 editor. He took the opportunity to ask Robin some questions on process, living standards and male grooming.

Bruce Lawson and Robin Berjon
Bruce and Robin


Tell us about yourself.
My name is Robin Berjon (@robinberjon, and I live in Paris with wife, daughter, and cat. I’ve been hacking Web and open source stuff since 1996. A little over ten years ago I started becoming involved in standards with the hope of helping make hacking with Web technology as cool as I thought it could be. I hadn’t realised that “as cool as it could be” would be notion prone to evolving so fast over time.

How long have you been editor of HTML5?
Since September, so a touch over two months by now.

But isn’t Hixie editor?
Hixie is the editor of the WHATWG HTML specification; I’m part of the W3C team of HTML editors. Essentially the same source document is used by everyone, but we produce different views on it. The WHATWG view is a single document containing features at varying levels of maturity; the W3C publishes that document as multiple separate specifications and currently focuses on a more stable subset of features.

It’s a big document — there’s room enough for a broad community to collectively figure out the future of HTML.

What does the job entail? Just tidying up and getting tests written? Isn’t that terribly boring?
Our goal is two-fold. First, we are on track to producing a stable snapshot of HTML5 by 2014. The first step in getting there is to produce a draft that is ready for intensive testing, which is the next step in the W3C process. In parallel, we will shortly start publishing drafts on the track (also known as HTML 5.1) including a number of new features. This basically corresponds to switching to something that resembles software development best practices in which one can choose either to use a stable release or the nightly build.

Based on the stable snapshot, we will ramp up our testing effort in earnest. To some, testing is a tedious occupation but I beg to differ. With testing, you get to break stuff. And other people’s stuff, too! And those people then thank you for it. Remember all that time spent working around browser bugs? Well with specification testing you get to turn that around, find the bugs instead of avoid them, and then wait as the browser vendors fix them. It’s Web developer payback time!

And there’s a host of things to be done for HTML 5.1 such as fixing AppCache (with our friends from WebApps) or evaluating the various proposals for responsive images. There’s no point in waiting for a finished specification to start work on the next one, and one thing that I find particularly exciting is that a lot of the novel stuff is exciting tech that’s brought to us by the community.

It’s not all just mopping up, though, is it? You’re already looking at new features. For example, W3C is considering <picture> element; WHATWG isn’t. Is there a danger of differing specs for the same markup language?
I’m not really worried about differing specifications because there’s a reality test: what’s really implemented out there? If you have two specifications saying different things about the same feature, and that feature happens to be reasonably reliably implemented, then one of those specifications is wrong. And it’s pretty hard to stay relevant while being wrong.

I would actually like to see more variation in input rather than less. It can be rather daunting for a group of Web people who care a lot about one specific feature to start contributing to any standards group. A lot goes on there, there tends to be a fair bit of email, the mailing list’s culture can be hard to grasp even if it’s not downright aggressive. This puts a high bar on such contributions, high enough that it is too rarely turned into a reality.

At the same time, it is difficult for even seasoned Web hackers to draft specification text without input from browser vendors and experienced standardistas, which in turn can lead to frustration as carefully crafted and nurtured work is turned down.

So we need to figure out how to make this type of group working on a specific improvement work more easily, more often. We already have a lot of the technical infrastructure with Community Groups, but getting the human bits to work is always the hardest part. I think that the work going on in the Responsive Images Community Group is a truly great experiment (even if it means occasional drama) and that the experience they are building up will serve to guide a lot of subsequent groups working in a similar fashion.

I bring this up because successful open projects are those that can keep bringing in new contributors over time. The Web standards community as a whole needs to do a better job there — and we will! So no, I’m not worried about differing specs. So long as we can figure out how to get all the browsers on the same page one way or another, the more input the sexier.

I recall someone saying that 20,000 test cases will be needed? That’s a lot – how are you going to do it all?
It’s probably a fair bit more than 20,000 since we already have over 11,000 and aren’t anywhere near satisfied yet. But the exact number is not as important as the fact that the number will be big. In order to pull this off, it would be tremendously helpful to benefit from broad community involvement.

And as it happens, that’s precisely something that’s been ramping up. You’re of course familiar with Move The Web Forward, the grassroots movement that’s pushing for a better Web. A part of that is Test The Web Forward. It’s a series of events specifically dedicated to making the Web a better place for all through testing. There was a first event in San Francisco last summer, and we’ve just recently had one in Beijing this week, and another in Paris. The TestTWF folks are looking into more events in other locations, so if you’re interested in having one in your city make your voice heard.

What happens there is that we kick off with a few presentations to explain how testing works, and then we all get our hands dirty in a hackathon with ample help from testing experts. For developers it’s a
great way to learn more about Web technologies and to get involved in a project that gives back to the Web. Plus: payback!

I was at the Paris TestTWF a couple weeks ago, and I have to say that I’ve been overwhelmed with how good the participants were. The turn-out was great, and people there just showed up, asked great questions, and immediately started crunching on tests. It’s not as if I didn’t already know that the Web community rocks, but it’s still amazing to see just how much people care and how dedicated so many are to improving the Web.

The w3c has “chopped up” HTML into modular specs; WHATWG hasn’t. Why?
A lot of people, including spec reviewers, test writers, and implementers have told us that they find it easier to handle smaller specifications because they’re easier to swap into one’s brain, and because you can more easily have someone work on a well-defined area. I think that Tim Berners-Lee explained it well a few years ago.

Of course, a lot of the Web platform is intricately meshed together so that cutting things into smaller pieces can be difficult, and at times risks hiding vital information. This is particularly true of existing features; for new features we certainly intend to try hard to make things as modular as possible. That’s why we expect a lot of the new features developed in the HTML WG to be created as extension
specifications. This does not mean that they have lesser status that the “core” HTML specification, rather it becomes a logical, modular way of adding new functionality. It also makes it easier for third parties, such as smaller, more focused communities or even individuals with a good ideas, to provide very concrete input that can more readily be reviewed by the group. Great examples of this include the Responsive Images work or the <main> element.

At the end of the day a lot of it boils down to taste, or perhaps more importantly to how your work in relation to those specifications is organised. If you’re working on all of it at once, it may be simpler to keep it all in one place; but if you’re trying split work off in a larger team you might prefer some predefined boundaries between documents. At least that’s the impression I get from the input people provide whenever this topic crops up. As far as I’m concerned I find that the extension specification model is more conducive to community contributions and so it definitely has my preference.

Why do we need W3C snapshots and versions, instead of a “living standard”?
It’s a big Web out there and a lot of people are involved in it in different ways. Again, whether you prefer snapshots or the bleeding edge document likely depends on what you’re doing with it. If you’re continuously working on and with the spec, producing snapshots is a drag. At the other end of the spectrum if you’re burning the implementation into silicon and you need to interoperate with others who are doing the same, you want something that’s almost literally carved in stone. In between those extremes, the specifics of your situation as a user of the spec will make you fall on either side of the fence.

One of the notable costs of a document that changes continuously is that for any work you do with it you need to track it with equal continuity, which can be quite taxing. In order to enable more loosely coordinated work on improving the Web platform, producing snapshots (e.g. for test writing or implementing) can help a fair bit.

It’s important to notice that stability is important for legal reasons: companies like to know what their commitments are and what others have committed as well. W3C’s Royalty-Free patent policy helps ensure that these commitments make it possible for anyone to implement Web standards without paying royalties. Snapshots help us keep the Web free.

That’s why we’re working on making both possible in parallel. The setup we’ve progressively been putting together enables us to have a continuously updated document and snapshots taken from it at regular intervals. This just might be one of those cases in which we can actually make everyone happy.

You’ve put the HTML spec on github. Why?
We wanted to go with git anyway since its branching features are a great match for the approach we’re taking in which we have a stable branch that is used to produce snapshots and a more advanced branch into which new features go.

If you mix that with our desire to involve the community more in the standards process, then GitHub was the logical choice: that’s where our community is.

Do you communicate much with WHATWG? Some of them aren’t great fans of W3C.
Several of us hang out permanently on the #whatwg channel, and on the WHAT’s mailing lists. I can’t say that it has been anything other than friendly and pleasant.

Some people in the WHAT community have criticism of how the W3C operates. A lot of that criticism is constructive, and I am more than happy to relay it inside. W3C has a long history of doing the right thing with respect to opening up the standards process (e.g. with its RF policy or working in public). I’m confident that the consortium will continue in this vein, even if it can occasionally take time for some things to change.

And on the rare occasions when such criticism veers towards trolling, everyone’s experienced enough with online discussion not to bite.

Is it time for Hixie et al to disband WHATWG and return HTML to the W3C fold, now they’ve won?
You’d really have to ask them that!

The WHATWG has certainly done an astounding job of bringing HTML back to life and making it the biggest blip on anyone’s radar. I don’t think that that necessarily entails that it should close shop just yet, if ever. As I said, I believe we should ideally have more decentralised work on improvement, not less — even if it’s difficult.

Is it true that Tim Berners-Lee comes to you for tips on male grooming?
I can’t possibly disclose the list of those who come to me for advice, but it is certainly true that since my breakthrough feature in GQ France an increasing number of Web hackers have been asking how to approach the ruggedly handsome magnetism of these roguish good looks.

Thank you very much Robin. (Evidence of Robin’s “ruggedly handsome magnetism” may be seen in his TPAC dance-off.)

7 Responses on the article “Interview with Robin Berjon, HTML5 editor”

  • Ian Hickson says:

    For example, W3C is considering <picture> element; WHATWG isn’t.

    That’s not quite accurate. The WHATWG has already considered the <picture> element, several times. It’s just been rejected in favour of something technically better.

  • Mat Marquis says:


    Putting the two proposals forth as identical and competing isn’t really accurate—the respective use cases of `srcset` and `picture` share some overlap, but the two patterns don’t solve an identical set of problems.

    This isn’t really the forum, but for the public record: we’re documenting a comprehensive list of use cases for any “responsive images” solution(s) at

    Once this is finalized, we’ll file bugs against each use case for further discussion.

    Sorry for the derail, guys!


  • “Technically better” yet the community hates it. YAY!

  • Matt Wilcox says:

    “Technically better” for your use cases. Which are not the same use cases as people in the real world are talking about. WHATWG approach things from an engineer perspective, not a designers perspective. Which has always been an issue – HTML isn’t “for” engineers to spec, it’s for designers to spec and engineers to build.

    Otherwise you end up with exactly this arrogance and examples like the grid module. Which ignores a century of designer’s terminology and proven system in favour of emulating the way tables work – because the engineers who specc’d the Grid system think in tables and put their own agenda ahead of the designer’s agenda.

  • Matt Wilcox says:

    * Grid module is CSSWG and not the HTMLWG btw – just extending my thinking to other standards groups and how they behave; you can tell there’s a lack of designers from the choices that get made.

    I’m not criticizing any particular group, just observing that there are questionable decisions from a design perspective, because there’s a lack of priority to design decisions. The order of importance for decision making about HTML and CSS’s feature set seem to go:

    1) Engineering priorities
    2) Newbie priorities
    3) Fallbacks for people using things wrong
    4) Actual designers wants and desires

    An odd order for a tool-set that’s primarily used by and most important to; designers.

  • Ian Hickson says:

    By “technically better” I mean that all the use cases presented were considered, and the solution that met the combination of factors required for something to be specced (meets the most use cases, can be implemented, doesn’t interfere with other features, etc) was the one chosen.

    I’ve written massive e-mails that discuss every detail that has been brought up; if there is information that wasn’t considered in those e-mails, please don’t hesitate to e-mail the list:

  • @Matt Wilcox — Your Grids Module slag-off is a little stale. You’ll enjoy reading:

    CSSWG Minutes and Resolutions San Diego F2F
    Peter Linss’ followup proposal

    …from August and September respectively.

    The TL;DR summary is Peter Linss (co-chair of the CSS Working Group) was concerned that “the grid layout module has become narrowly focused on the task of application UI layout and is not providing the kind of behavior typically expected from traditional typographic layout grids”, so he’s redrafted it. Terms like rows, columns and cells have been replaced with ones like lines, roles and fields. The dynamic duo of Tab Atkins, Jr. and Fantasai are helping refine it now.

    WHATWG (and CSSWG) approach things from a spec writer perspective. HTH.

  • Join the discussion.

    Some HTML is ok

    You can use these tags:
    <a href="" title="">
    <abbr title="">
    <blockquote cite="">
    <del datetime="">
    <q cite="">

    You can also use <code>, and remember to use &lt; and &gt; for brackets.