On Mon, Jun 17, 2013 at 6:03 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > - but we need to be realistic that on day one, all the content developed >> to the nascent webkit/blink implementation is not going to work on a >> standards implementation, and some of it never will (if it's never >> maintained). >> > > We might be able to get close without much work. > > I think we (Mozilla) should put the non-standard names behind a pref and > put webkitAudioContext behind another pref. Then as our Web Audio > implementation marches through our release process, users and developers > can easily experiment to see how much compatibility we get by turning on > those features. If we get valuable compatibility, the argument for > defaulting on the necessary prefs is strong. > For whatever that's worth, I'm fairly strongly opposed to Mozilla (or any other engine for that matter) to ship webkitAudioContext, because firstly it will make it impossible to finally get rid of the long tail of small web applications that depend on it, and it will be a point at which we will have a harder time resisting implementing all of the existing WebKit/Blink bugs where they don't fully adhere to the spec. I also believe that it's damaging to the Web for an engine to ship a prefixed implementation of another engine, since doing that has the potential of setting that into stone for an extended period of time, once web developers realize that their content using webkitAudioContext suddenly starts to work in Firefox without modifications. I'm less opposed to implementing the alternate names behind a pref, if that pref is set to off by default. Also, I'm still quite hesitant to believe that there is a lot of important Web content (that is, not Chrome apps, or content that depends on other Chrome specific features) out there that uses Web Audio. We don't really have any evidence to believe that, and it seems like we have no data to prove me wrong. :( -- Ehsan <http://ehsanakhgari.org/>
Received on Tuesday, 18 June 2013 02:06:50 UTC