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.

 

Tell us about yourself.

My name is Robin Berjon (@robinberjon, berjon.com) 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 HTML.next 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.)