Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Friday 30 September 2011

Shifts In Promoting The Open Web

Historically Mozilla spent quite a bit of energy promoting use of the "open Web" over proprietary platforms and non-standard browser extensions (IE6). This is still needed, but the landscape has shifted and I think our emphasis needs to change with it.

The platforms we need to worry about have changed a lot. Instead of WPF, Silverlight and Flash, the proprietary stacks competing for developers are now iOS and Android. Accordingly, the features the Web needs to catch up on are mobile focused. We need to be knocking down the barriers that make mobile app developers write native apps instead of Web apps (and we are!) and we need to be promoting the development and use of Web apps instead of native mobile apps. Demos that only work on desktop browsers are less important.

The open Web also has some interesting new platform competitors: platforms that build on (embrace and extend?) Web standards but take control of application delivery to create a vendor-controlled platform. The Chrome app store and the upcoming Windows 8 Metro app store are examples of this. I was very disappointed to see offline GMail and Google Calendar restricted to being Chrome apps. Even though Angry Birds works great in Firefox, its Chrome branding alone probably makes people think it only works in Chrome. To counter this we have to make sure that browser competition stays strong and offer developers browser-neutral Web app stores. Mozilla is working on these, of course :-). We also need to send a clear message that browser-specific app stores run counter to the open Web.

A less obvious form of platform competition is application developers targeting a single browser or browser engine. Google is explicitly telling its developers to target Chrome-only at first and support other browsers as an afterthought. That's understandable, but still disturbing. Also disturbing is that many mobile sites only target Webkit (sometimes implicitly by relying on Webkit bugs, more often explicitly by relying on -webkit-prefixed features). Many mobile developers, even developers at good places like Google, are reluctant to change this behavior. This is a huge problem for the open Web. We need an open-Web-standards campaign targeted at mobile Web developers. We need to be clear that apps working only a single browser engine, whichever engine that is, run counter to the open Web.

It's unfortunate that only Mozilla (and maybe Opera) of the major browser vendors has no vested interest in the success of a non-open-Web platform. I'm glad I work here.

One of the great things about the Web right now is the explosion of new features and standards for Web developers. However, we need to carefully distinguish good open standards from "open-washed" single-vendor initiatives. Not every proposed standard is good for the Web, even if it comes with an open-source implementation. Maciej Stachowiak points out a few Google projects --- VP8, SPDY, Pepper, and Native Client --- that, while they may be good ideas, fall short of true open standards to varying degrees. (The lack of a good spec for VP8 is an issue that we at Mozilla can and probably should address ourselves.) There are also cases where even though a good multi-vendor spec exists and some Web developers want it, the feature is not good for the Web and should be resisted. So I think when we promote the open Web we need to be very discerning about which specs we promote. Just because someone pushed out a draft spec with "CSS" (or "HTML" or "Web") in the name, and shipped a prefixed implementation, doesn't mean that that spec is, or should be, part of the open Web. People need to ask: is this feature good for the Web? is there a thorough draft spec that doesn't require reverse-engineering of an existing implementation? are there multiple implementations? is the spec actively edited with feedback from multiple vendors, and Web authors, being taken into account?

It's a challenging time. It's an exciting time. Despite the threats I mentioned, it's great to see massive investment in improvements in open Web technology. It's great to see Microsoft moving away from Silverlight towards a standards-based platform. We've won some battles, but the war for open Web standards is not over and we need to keep fighting it, on the right fronts.

Comments

Henri Sivonen
What we are seeing with -webkit-CSS makes me wonder if the practice of vendor prefixing is inherently anti-competitive and something we should discourage. Even if Web authors were providing -webkit-, -moz-, -o- and -ms- prefixes, what should a new entrant to the market do except implement someone else's prefix? Vendor prefixing is working great for WebKit, because the current market situation makes Web authors consider at least WebKit compatibility. Vendor prefixing has worked for Mozilla on desktop, because Firefox has had strong enough a position on desktop that authors have considered Firefox-compat. However, as you mention, vendor prefixing is a problem for us when it comes to "mobile" sites designed for a WebKit monoculture. Vendor prefixing is a problem for Opera everywhere, because some portion of Web authors is ignorant (sometimes willfully) of Opera. For Microsoft, vendor prefixing is a problem, because they are late to reboot IE and there's now a lot of legacy that ignored IE. (Even Mozilla's demos: https://bugzilla.mozilla.org/show_bug.cgi?id=642265 ) Maybe the old "first to ship gets to define the feature" model was better after all. Especially when the time scales of the CSS WG (with proper test suites, I know) are so much longer than the time scales for browser releases and deployment on sites.
Anonymous
I totally agree, ROC. But I think the main threat is that currently Mozilla's reputation is going down the drain by this unfortunate versioning / fast release cycle debate. And once you've lost your users, it's hard to get them back. Currently every month counts!
Anonymous
IMHO, just as large competitors to the open Web as Android and iOS, which all can run open Web code reasonably, are Facebook, Twitter and similar systems that don't go with the decentralized nature of the open Web. And then there are Windows 8 and any other platform that advertizes web technologies but means a stack that is tied to native interfaces (WebOS if it survives somehow and possibly even Tizen might come into play there as well). And I see those as a way larger or at least equally large problem in terms of destroying the open Web than iOS or Android right now...
Mike Shaver
The VP8 spec is actually in decent shape now, in the git repo, but it hasn't been well-advertised. There's an IETF Informational draft as well, since January, which I think was sufficient for the ffmpeg folks to interop. I believe we did help with it (and by "we" I mean Tim of course!), but mostly it was Google's people. Google's a big place, I'm not sure their position on openness and neutrality and suchlike is coherent. Certainly Paul Irish has been as disappointed in the needless-Chrome-specialization stuff on the big demos as I have been, and has helped fix them.
Robert
The ffmpeg implementation had to do quite a bit of reverse-engineering, I understand. Of course their independent implementation does put VP8 in a better position than some other wannabe-open standards (thanks guys!).
Cody Russell
I don't agree with Henri's assessment. Vendor prefixes are a great way to expose new features and promote competition between browsers. And the perceived problem that people may choose to use -webkit prefixed CSS rules is one which already has solutions for application developers: Sass and LessCSS. Sure, not everyone is using those.. but they should be. :) However, I have thought before that it is a little silly to copy someone else's CSS rule exactly but then to change the name (e.g., copy -webkit-foobar and call it -moz-foobar). These prefixed rules remind me of OpenGL extensions, where before features became part of the OpenGL standard they would begin life in the form of an extension prefixed by NV_ or ATI_ or INTEL_ or something. But if you look at the list of OpenGL extensions supported by your video card, you'll likely find extensions created by companies other than the maker of your GPU. It would make more sense to me that if WebKit adopted a CSS extension that first appeared in Firefox, it should be prefixed with -moz if the functionality and syntax is the same. If they change something then they would prefix it with -webkit instead. Alas, that doesn't seem to be how it works, and we move on in our lives. :)
blizzard
(this is a test post.)
Mark Steve
Open web deliver best platforms. Now iOS and Android app developers have more features which are useful for their job. Event app for iphone