- From: Rich Tibbett <richt@opera.com>
- Date: Mon, 12 Mar 2012 15:11:49 +0100
- To: Anant Narayanan <anant@mozilla.com>
- CC: public-media-capture@w3.org
Anant Narayanan wrote: > On 3/8/2012 3:21 AM, Rich Tibbett wrote: >> Either an API is mature enough for release or it's not. CSS vendor >> prefixes is a lesson learned. We don't want to see a repeat of this >> practice. > > I hope having getUserMedia already implemented without a prefix in your > builds won't mean we can't change the specification; as I suspect we are > close, but not done. We will support the standard. If the standard changes then the implementation will adapt accordingly. Non-prefixing is a response to web silos and browser fragmentation that promotes less than optimal web development practices that leads to inconsistent user experiences. All of these things are bad for the web, UAs, developers and users. In the link I attached to my initial reply, Paul Irish argues that non-prefixing does not hamper implementer maneuverability [1] and we agree with that sentiment. A lot of features would be in a lot better state if we hadn't prefixed them in final browser builds. We've successfully tweaked our implementation a number of times over the last few months with getUserMedia (e.g. moving from string based options to object based options) without any significant problems. We expect to have to make more tweaks in the future. Opera run a number of programs designed to fix incompatibilities between implementations. The least successful of these is reactive developer evangelism which is where vendor-prefixing leads all browser vendors eventually. The most successful approach is simply making provisions for API incompatibilities in our browser.js [2] as we go while maintaining a single consistent entry point for developers to use these APIs now and in the future. It would be a lot better if we collectively release un-prefixed implementations while simultaneously creating a defacto cross-browser test suite that can be used to check and maintain consistency between different implementations rather than promoting silo-based development. I could argue that had we prefixed we have locked a number of very cool very early demos in to an opera prefix. We decided not to do that. - Rich [1] http://paulirish.com/2012/vendor-prefixes-are-not-developer-friendly/ [2] http://www.opera.com/docs/browserjs/
Received on Monday, 12 March 2012 14:12:28 UTC