Jeff Jaffe lights a fire under Web standardization

BARCELONA--It's been an action-packed two years since "http:="" news.cnet.com="" 8301-30685_3-20000131-264.html"="" rel="">Jeff Jaffe took over as the World Wide Web Consortium's chief executive, but more action is the order of the day at the standards group.

The W3C oversees the standardization of Hypertext Markup Language (HTML) and Cascading Style Sheets (CSS), technologies that carry tremendous importance as the Web expands from a medium to publish documents into a foundation for applications that can run on anything from mobile phones and cars to TVs and tablets. These Web standards, combined with the JavaScript programming language and other related technologies, let programmers reach a broader range of electronic devices than any other single technology.

If you're creating these standards, therefore, you don't want to mess anything up. But Jaffe also acutely feels the need for speed.

"The consensus process by its nature moves too slowly. Business moves quickly. We need agile processes to make sure people understand that the standards process has to keep up with the industry," said Jaffe, who sat down with CNET News' Stephen Shankland at the Mobile World Congress show here last week. And that's going to change, he added.

It's hard to move fast with innumerable interested parties and an elaborate standardization process. But even as the "Web platform" advances through projects such as Google's Chrome OS and Mozilla's B2G -- browser-based operating systems that can't run anything except Web apps -- iOS and Android are drawing programmers to new domains for native applications instead.

A recent "prefixes" spat over CSS -- formatting technology called Cascading Style Sheets -- illustrates the plight of Web standards. Some Web programmers employ features so that only browsers such as Safari and Chrome that are based on the WebKit engine can use those features -- even when rival browsers support the feature, too. This fragmentation stems from standardization that can't keep up with the arrival of new features.

Here's an edited transcript of the interview:

Shankland: Facebook just announced a test suite called Ringmark to check how well mobile devices support various Web standards, an attempt to make life easier for programmers who want to develop mobile Web software, and it's working with the W3C to develop the test suite. What exactly is Facebook doing, and how much of the project is Facebook and how much of it is other companies and organizations involved?
Jaffe: Let me start by anchoring my remarks with an article you wrote about a year ago in which you said that I had to be very impatient about certain things and very patient about other things.

One of the things we wanted to be impatient about was we wanted to get things more agile starting things in the W3C. We started the community group concept, which makes it really easy to start new things. We introduced this in August. We have over 50 community groups. What it means is that we have a very patient process to be sure something is ready to be called a standard. And we have a very immediate process whereby any of our stakeholders can step up and say, "We need to start moving something fast."

It's great Facebook could move on this, together with their 30-plus partners. It's an illustration of what could not have been possible a year ago. Our standard process is a consensus to do everything. This allows people to jump out there and say, "Here's a need, we're going to address it as a community group." That's what FB did. There's no question that Facebook is exhibiting leadership in doing this. They're doing it together with community of like-minded individuals, but obviously they're taking the lead, and they deserve a lot of credit for that.

So this isn't a formal standards process yet. This is a maybe-it-it'll-turn-into-a-standard process.
Right. Community groups'...recommendations are not formal W3C recommendations. Those recommendations take place when the entire community gets a chance to weigh in. That's the working group process. At the appropriate time, we'll take the output of this community group, and there's a good chance we'll put it into a working group. If it's done well, it'll sail through.

Are there other profile efforts at the W3C besides Facebook's? When I heard about profiles I immediately started thinking of the Java Community Process, with J2ME and this profile, that profile, Connected Limited Device -- I can't remember all the different ones. It was a mess. People were trying to assemble a collection of different interfaces. This bundle is this profile, that bundle is that profile. Does that answer a need in the marketplace?
One thing that's driving this need, in all candor, is that Web standards tend to move very fast, and as a consequence, it's not the case that every implementation is in perfect lockstep. That fragmentation is what [Facebook CTO Bret Taylor] called out in his announcement. Having a profile to balance the fragmentation -- to say here's a big piece of the market that we're all going to do the same way -- is extremely valuable. At the end, whether we need one mobile profile or two or six or seven, that's in front of us. That's the kind of thing that might be done in the working group.

Another big issue that's been causing a lot of angst in the Web standards world is this issue of prefixes with WebKit. [Prefixes are used on Web pages to target specific browser engines that support new features still in testing phase; at issue is whether prefixed CSS features are in effect becoming standards without being standardized so all browsers can benefit.] Daniel Glazman [CSS working group co-chairman] kind of went ballistic. He got some sympathy, but he also got some pushback. What do you think about prefixes as a way to develop new Web standards features, and what do you think specifically about the CSS WebKit situation?
With Web development, we're always balancing innovation with standardization. We need some mechanism that support innovation, and some way of having adoption of new concepts while they're on the track to standardization. Prefixes have been used for some time. I think they're a valid and effective means to do it.

The hottest phones and tablets of Mobile World Congress 2012 (photos)

+23 More

See all photos

A challenge that we've had in CSS is that some functions, which today are not yet standard but are supported in a widespread fashion in prefixes, are really ready for standardization. The dialog that took place early this month drove an emerging consensus within the working group that there's an opportunity to move faster in standardizing some of the things that are currently prefixed. To the extent we do this, that's going to settle down some of the discomfort. You start by prefixing when you're in the innovation phase. When you get wide enough acceptance for it to be a standard, it's time to cut over and move to a non-prefixed standard.

One of the specific complaints is that Apple doesn't have enough people working on those standards -- they create some new standard but then they don't hand it off. Are you leaning on them to say ahem, you're breaking the standards process? You have non-WebKit browsers threatening to use WebKit prefixes, which seems like a pretty broken solution to the problem.
What makes things most successful is when people bring their ideas to W3C. My sense is that, as the person who has responsibility for the W3C, I'd love it if we had maximum participation from all the vendors. On the other hand, it's a volunteer organization. On balance we do quite well.

I'm not trying to suggest overall it's not working, but it does seem to be it's not working in one very high-profile part of the Web platform.
From my perspective, people are innovating, they're contributing new ideas. It's fair to say all the companies participating in CSS are contributing ideas and participating. There are times when some of these specs could move faster, and we're pushing that forward now.

Where are the points of leverage where it seems you can make a difference?
I think that W3C does a good job in shepherding the industry to agree on standards. Consensus takes a long time. I think we need to learn how to move faster than we move today. There are two phases of development. One is the early, innovative phase of development -- how do you get something started. Second the standardization phase. What we learned over the last couple years is that we were trying to do both the early development and the standardization phase with the same set of tools, and that was a mistake. The easiest thing was introduce a new set of tools to do the early development. That's the community groups.

The way we develop standards, our working group process, is something which evolved over 15 years, and I think moves a little too slowly. It needs to move faster. We haven't yet taken that on. Taking on an existing process is more challenging than introducing a new process. That's what's on the agenda for the next year.

The consensus process by its nature moves too slowly. Business moves quickly. We need agile processes to make sure people understand that the standards process has to keep up with the industry.

How do you make that happen? Do you raise the ugly specter of the CSS prefixes situation and say that if you don't move fast enough, you lose control of the situation and standardization happens elsewhere or doesn't happen at all?
There are things that have crept in over the years -- maybe there was a corner case here introduced some delay bar, then another corner case there so we introduced another delay bar. We have to look at whether we need all the mechanisms we have and strip out the ones we don't need. We'll really take a fresh look at pretty much everything and make sure we keep what's good.

When will you have an idea how to proceed and when will you proceed?
We're just getting started. We have semiannual meetings with membership. The next one is in May. That's our first opportunity to have a really robust conversation.

And when will it actually start speeding up?
It's too early to tell. Right now we're still in diagnosis mode.

A year ago we talked about the Web being a platform. How much progress have we seen toward that. I don't see any signs of PC operating systems going away. It seems in the mobile world that Android and iOS are gaining in credibility, power, and utility. How much progress has the Web made as a platform, and is it keeping up with the native platforms? Is its glorious future moving as fast as the others' glorious future?
Here are a couple proof points. Mobile World Congress has a very nice daily newspaper which comes out. There's a lot of stuff that goes on here, LTE and so forth. I thought it was pretty stunning that in the lead each of the first two days, there was a pretty big focus on contributions to the W3C. Yesterday's lead article was the Telefonica and Mozilla announcement, and the other was Facebook. The more substantial proof point is that if you look at analyst coverage -- Gartner, Forrester, Yankee -- I look at what they're advising the IT world about. I use that as a pretty good metric as to the impact of the Web platform. They're all talking about HTML5 and the Web platform. the last 3 or 4 months -- a lot of reports. They're pointing out strengths and weaknesses. They're talking about it. If you were looking a year ago, you wouldn't have seen that. There's a recognition that the open Web platform is the most interoperable thing and it's quite impactful for the industry.

Do you want bring WebGL [a standard for 3D Web graphics, typically hardware-accelerated]. The work is being done at the Khronos Group. Is that something you'd like to work more closely with or maybe even take over?
From my perspective it works pretty well having a formal liaison with the Khronos Group. If you look at the Web platform, it doesn't only come from W3C. I comes from IETF, from Oasis, from the Khronos Group. The thing we look over in W3C is we try to make it as architecturally coherent as possible. But the world's pretty interconnected. You can't draw any simple boundaries around what belongs where. For those things done elsewhere, we just work with the other organizations.

HTML editor Ian Hickson just reiterated his belief that HTML should be a "living document," not a static snapshot of a standard. [He stopped using version numbers just as the term "HTML5" caught on, often standing for more than just version 5 of HTML.] Hickson argues that you need need to be able to fix bugs and change the specification. Are you any more persuaded by his views than you were a year ago? You said then that for device makers and chipmakers need something fixed they can grab onto.
I believe that HTML is a living technology. It's lived through HTML 1, 2, 3, 4, and we're up to 5. When we're done with 5, there will be a a 5.1, a 5.2, or a 6. Will there always be a bleeding edge in HTML? For the foreseeable future, yes. That's different than standardization. Standardization is a process by which a huge ecosystem, which the economy has a huge dependence on, moves in lockstep, so Web designers know what to put on Web pages, browsers can browse it, chipmakers can build chips on it and build it into devices, and it can be fit for consumer electronics and televisions and automobiles and refrigerators and so on.

I don't disagree that HTML is living. But I think the industry needs a standardization process whereby every few years we say we're ready for the next generation.
We're still a couple years away before HTML5 is actually, formally done. It seems to me that if you're a consumer electronics company, you're not going to wait until 2014 to support the HTML video tag [which enables streaming video]. There's still a pretty big disconnect between the rate at which the standardization process works and the rate at which the technology gets adopted. People in effect do complete with incomplete versions of the standard because they have to.

People experiment in the Web. The Web would slow down tremendously if people waited to final standards before implementing. Prefixes are one of the many ways we encourage innovation in the Web. There's a balance.

There's work to update the HTML video tag and audio tag so you can use DRM copy protection but you wouldn't need a browser plug-in for it. What's your take on building DRM into a W3C standard?
We have a couple of very fundamental rules within W3C about what we accept and don't accept. One we accept is all our specs are prepared and provided on a royalty-free basis. That one is cast in concrete. Any new recommendation has to follow that as well. If anybody wants to have a DRM recommendation, it would have to be royalty-free. It's not the case we have any rule in the W3C process which prevents a DRM idea. That certainly makes it possible for W3C stakeholders to provide use cases and requirements. The Web and TV interest group several months ago put in some requirements. They did not put in a requirement for DRM, but they require for APIs [application programming interfaces] to make it possible to add DRM. Those are provided to the HTML working group. The group is now debating the use case and requirements. There's nothing in our Bible that would prevent that.

There's no problem with having an open specification with DRM which necessarily has to have some sort of closed element to it?
Encryption doesn't have to be impacted. We try to avoid patents where possible. It's not always possible. A similar example is video itself. Much of video on the Web today is H.264 video, and it's patent-protected. Two and a half years ago we looked at standardizing a codec [an encoder-decoder engine for handling compressed video] for the Web. We said we can't find one of good quality that's not tainted with patents. Our working group concluded we are not going to standardize a codec at this point. From time to time i request patent holders to provide us royalty-free codec for the Web, and to date I have not succeeded.

From a patent perspective, DRM can be quite similar. We can have interfaces to patented technology and we won't standardize the underlying patented technology until the owners of that technology releases those patents.

Google has released VP8 as royalty-free. What's standing in way of adopting VP8 for HTML5 royalty-free video?
No company has brought VP8 to W3C for standardization.

One thing that came out at W3C is Boot to Gecko, and Mozilla's partnership with Telefonica to use that browser-based OS. And Deutsche Telekom and Qualcomm are helping. How mature does that need to be for to call it a success in the real world?
You have to measure success on a number of criteria. It's an illustration of the success of a Web platform which people can build on top of. From that early-indicator perspective it's a success. They're just getting tarted in terms of productization, so it's fair to say it's not yet a market success. At the end of the day that's how the industry does tend to measure success.

Do you think B2G will improve Web programming even if the Web programs run in an actual browser on a native OS, not just a browser-based OS?
Sure. What people like about the Web is it is the most interoperable platform. It's open, it's not controlled by anybody. It's not controlled by W3C. It's controlled by the industry, by all of us. That appeal is unstoppable.

There are lots of reasons to do native apps. I don't think I ever said that native is going away. But the number of things you can do in an interoperable fashion keeps growing. The allure of writing software once, having it run everywhere, having it be interoperable, having it be open -- that's what developers want to do. That's what a lot of companies want to do as well. It's not just Web video. There's work we're doing at the W3C on device APIs [an interface with hardware such as cameras and battery status], consumer electronics, geolocation, privacy -- there's a lot going into the Web platform. Hundreds of companies are participating. Large numbers of companies are joining W3C every year.