Re: Sites using webkitAudioContext only

On Mon, Jun 17, 2013 at 6:03 PM, Robert O'Callahan <>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.  :(


Received on Tuesday, 18 June 2013 02:06:50 UTC