Web standards vet marches Microsoft to the front lines (Q&A)
Paul Cotton leads Microsoft's involvement in the important and often fractious world of Web standards, amid debates that underpin how you live your life online.
You might think developing technology standards is plodding, bureaucratic tedium compared to something like the frenzy of smartphone innovation.
But you'd be wrong, at least in the case of Paul Cotton, who leads Microsoft's involvement in the important and often fractious world of Web standards. Web standards are hot -- and hotly contested.
Cotton, an even-keeled Canadian, discovered a passion for standards more than 20 years ago when figuring out how to digitize airplane maintenance manuals. He's comfortable with the contradictory motives of standards groups: fierce competition one moment and gentlemanly cooperation the next.
It's a good mindset for the debates shaping the Web, which is the world's most important publishing medium and could become the world's most important software foundation, too.
This is no easy job. For years, Microsoft sidelined itself from the world of Web standards. Internet Explorer, especially the now-despised IE6, exemplified how spurning standards held back the Web.
But Microsoft has performed an about-face. With IE9, the company embraced a wide range of standards and jump-started the move toward hardware-accelerated graphics and text, a move that helped usher in high-performance Web games such as Windows 8, Microsoft embraced even more standards and built them into the operating system's cross-platform interface.and . And with IE10, which just arrived with
Accompanying that about-face has been Microsoft's heavy presence in the World Wide Web Consortium (W3C) standards group. But it's conspicuously absent from the Web Hypertext Applications Technology Working Group (WHATWG), an informal rival that carried the HTML torch for years when the W3C and Microsoft had left it for dead.
Microsoft has often been at odds with others in the industry for Web standards. It doesn't like WebGL for bringing 3D graphics to the Web. It's had other disagreements over important standards including WebRTC, Web Socket, and Do Not Track. And it showed up late in the game with a new proposal for handling touch input on the Web.
Cotton isn't just on the front lines of these standards battles. As co-chair of the W3C's HTML Working Group, he's also trying to show that the W3C's consensus-based approach and patent protections are better than the WHATWG's approach. The following is an edited transcript of Cotton's discussion with CNET's Stephen Shankland.
Shankland: Are you worried about the tremendous momentum behind the move to native apps? When Apple runs iOS and Google is in charge of Android, companies and developers can move faster.
Cotton: It's an interesting problem. What developers are looking for is an environment to build Web sites and apps as cheaply and effectively as possible. I think the reason developers use tools like [Adobe Systems'] Flash and [Microsoft's] Silverlight are the developer tools that come with them. So partly my answer to the question of HTML vs. native apps is that I don't think developer tools for doing HTML apps are at nearly the same maturity as developer tools for native apps. Microsoft is very interested in this, with products like Visual Studio.
We've got performance challenges as well. We have to be very responsive to events likeWhen they do HTML5, they don't have any way to measure their app's memory usage. That's not got anything to do with the way the HTML5 spec is written. That's got everything to do with the development environment.
Cotton: We still are concerned about the security holes we believe WebGL offers. If we were ever going to implement WebGL, we think finding a solution to those problems is not optional but actually mandatory. Over the lifetime of IE8, IE9, and IE10, every single time we said we added newer features like pointer events, [a request for WebGL support] is one of the first five responses.
We are very conscious of the input we get on the IE blog and very conscious of the scenario you described. It would be great to have interoperable 3D graphics on the Web. If we can solve the security problems, I think we'd seriously look at some way of producing 3D graphics for the Web.
Shankland: Several other browser makers have added WebRTC, a standard for bringing real-time chat to the browser for activities like videoconferencing. But just as standardization was finishing up,
Cotton: We were late in the game in WebSocket as well. When we got to the table, we had serious problems convincing people the model WebSockets initially had was broken. Another example of coming late in the game is the submission we made about pointer events [such as multitouch gestures or mouse clicks]. If you look at the W3C response, it says maybe [Microsoft's] model is better than the one the touch events working group was working on. The problem with the touch events [model] they're working on is they have an IPR [intellectual property rights] disclosure from Apple saying the API [application programming interface] they're designing touches on Apple's IPR. We decided that we'd made a mistake: Developers had to have a separate interface to deal with touch events on a touch device than they would from a mouse or pen or tablet device. Even though it was late in the game, we changed the model we had in IE10. It was through that experience that we shipped off to the W3C this pointer events spec, because we believe it's a late arrival but also much, much better than what was before.
So my first comment is: Yeah, maybe it's late, but that doesn't make it wrong. We think there are very serious problems with the [WebRTC] API the W3C is working on. It's obvious the working group has rejected our rationale and plea for a different API, but I don't think we're going to back away from the principles in our design or the concerns we have. I don't think we've decided how to move forward. We're very firm believers in the architectural principles our position was based on, and we're going to try to figure out how to propose an API that represents those principles.
Shankland: What's the best way to
Cotton: I've got tremendous respect for the chairs of that working group, which has perhaps the most diverse community in the room -- browser vendors, advertisers, and privacy and consumer-protection people. It's bad enough when you have two poles, but in this case you have three. There are strong personalities. I know [Do Not Track author] Roy Fielding, who's principal scientist at Adobe. His mission in life is to protect the Web. I have extreme respect for Roy.
People should be aware [that Do Not Track] is among the settable items when you first install Windows 8.
I agree this is a very contentious item. You have some people who think consumer protection should be the overriding factor, and you have the advertising industry -- in which Microsoft has a very large investment ourselves. Without a doubt there are different opinions on how that flag should be respected or not respected depending on how it was set. Microsoft thinks we've done the right thing for consumers when used with a browser like IE, but it's obvious this deal is not done yet. The working group is going to have to decide what's conformant [in other words, whether Microsoft's approach complies with the standard].
Shankland: What if the working group decides that people wanting to use Do Not Track have to take a more active role in setting it rather than accepting the Windows 8 installation defaults? Would Microsoft change?
Cotton: I think we'd want to know what regulators think about that. There are three parties involved, not just two. I'd be really interested to know what the various government agencies and consumer-protection people would say about whether that was advisable or the right model. I was careful to point out there were three groups. Your question focuses only on two of them. The browser makers vs. the community of advertisers that have servers out there that, say, won't respect if Do Not Track is set in particular way.
I don't know if your life changed at dinnertime. It used to be at dinnertime the junk phone calls were phenomenal. Then the government decided to create a Do Not Call list that consumers could put their names on. As much as the advertising industry didn't like it, that's exactly what happened. Now my wife and I don't get junk calls at dinner. That occurred because of a government-facilitated mechanism for consumers to be protected.
Shankland: Ian Hickson [the WHATWG's HTML editor and a Google employee]
Cotton: The way the encrypted media spec is being done, much to the dismay of people who don't like DRM, is that we aren't standardizing how the DRM black box actually works. We're saying if you get an encrypted stream, here's how you fetch those bits, pass them to the black box, and get them back unencrypted. That's one reason Ian has such a strong DRM opinion -- he said it was evil, maybe. The reality is that specification is being written. In the same way we haven't standardized a video codec [for HTML video in general], we aren't specifying how the black box actually works for the encrypted video spec. We had to find novel ways for a company like [new W3C member] Netflix if it wants licensed content delivered under some sort of encryption.
Shankland: You could avoid DRM on principle, but you would never see the Netflix Web app, so you'd always have to use some native app or plug-in?
Cotton: I joked [at an HTML Working Group meeting] that this was no longer my father's W3C. Zynga was there, Disney was there, Netflix was there, Comcast was there. All of a sudden you had the media people. They decided to join the W3C because they saw it as the really high-value venue where even if they had different business models, they could find technology solutions in the W3C.
I think, has done an amazing job in his tenure of not only holding the current community together, but to include not only a much wider range of developers through community group process, but also bringing the Netfixes, the Facebooks to the table.
Shankland: What do you say to people who think the W3C is moving too slowly, with plans to finish the HTML5 standard in 2014 and 5.1 in 2016?
Cotton: To start, I'm usually pretty honest. Standards have a very, very high value. Sometimes things that have high value do take longer, but it's important that we get it right. Microsoft and I personally are big supporters of the W3C as the venue to get all the browser vendors and as many of the application vendors as we can on the same phone call and in the same room.
The current proposal is HTML 5.1 and to call the next modular one on top 5.2. I think the two media specs [encryption and adaptive streaming] could be done well in advance of 2016...because it's written as extension specs and has no dependency on anything for HTML 5.1.
Shankland: There's a big difference of opinion between developing the HTML standard at the WHATWG, which prefers its
Cotton: To start, I have a tremendous amount of respect for what Ian Hickson and the WHATWG have done. In particular, I admire Ian Hickson's tenacity. When the W3C was focusing on XHTML [an incompatible would-be successor to HTML] and he didn't believe them, he continued to work on what he thought was the right solution, which was HTML.
But the No. 1 difference [between the WHATWG and W3C styles] is that I believe in a larger group of people deciding what's going to be a standard, rather than one person saying, "I'll take all your opinions and I'll decide." I'm a firm believer in the consensus-driven process. You get everyone in a room, then find the right solution that meets the maximum number of requirements.
I'd be the first person to admit the work at the W3C and other standard organizations is perceived as taking too long -- and sometimes correctly perceived. But the other side of that double-edged sword is yeah, you can go really fast, but you can make mistakes. And if you don't have consensus, getting the wrong answer fast can be worse.
We put out a revised plan, the second time we've issued our HTML 5 and 5.1 plan. We want the HTML Working Group to work faster and be more agile.