Re: Sites using webkitAudioContext only

On Wed, Jun 19, 2013 at 3:47 PM, Kevin Gadd <kevin.gadd@gmail.com> wrote:

> I'm a little confused on a detail here, so pardon my request for
> clarification:
>
> It seems like at present, we have effectively 'two different Web Audio
> APIs':
>
> AudioContext (and, to a degree, mozAudioContext), which are both
> theoretically implementations that attempt to conform to the
> spec-as-published
> webkitAudioContext, which conforms to an older version of the spec and is
> constrained by unfortunate backwards-compatibility requirements with
> existing applications
>

Small correction, there is no mozAudioContext.  Our implementation is
unprefixed, and it follows the spec very closely, much closer than the
current WebKit and Blink implementation.

But it is the spec itself which is constrained by the backwards-compat
requirements of Blink (and perhaps WebKit?).


> And then as I understand things, it is very difficult to remove
> webkitAudioContext from Webkit (to force use of the non-prefixed name) or
> make backwards-compatibility breaking changes, because of existing web
> content out there? This is also what's motivating discussions about Gecko
> possibly implementing the prefix, right?
>

Correct.


> Assuming what I stated above is correct:
>
> Would it be possible to do a 'least possible damage' sort of thing like MS
> tried to when they globally disabled plugins (like flash), where we
> whitelist known sites that need backwards compat and for whatever reason
> can't be updated? This would keep existing big names like Angry Birds or
> Turbulenz working in Chrome just like before, while limiting the spread of
> broken/old Web Audio to new sites - people would use the broken code and it
> wouldn't work (perhaps they'd even get an informative error in the console
> telling them why) Whitelisting production domains only would also ensure
> that anyone actively doing development against Web Audio would see these
> problems in their development environment (since it's not whitelisted).
> Even better, the whitelisting could function by loading a user script that
> defines webkitAudioContext in terms of spec-compliant AudioContext, and
> Firefox and other browsers could load that same user script to become
> compatible with busted old content on the whitelist.
>

The big titles are *not* an issue, since Mozilla, Google, Apple and others
can just reach out to them and ask them to fix their stuff.  It is the
other content that is an issue, but we don't have data on what those other
content are.

This is definitely one technique which can be employed to narrow down the
backwards-incompatibilty scope, but unless we have a list of such websites,
which we don't, it won't be very useful.  Also, it would be a very
unfortunate thing to do for the health of the web, but I understand that
sometimes pragmatism needs to prevail.


> Is the difficulty of making changes to Webkit what creates the friction
> here when discussing the possibility of bigger changes (like the
> constructor pattern)? Or is it more that there is simply a desire to
> solidify the current spec and ship it instead of continuing to iterate?
>

I believe it's mostly the difficulty of making changes to Blink, not
WebKit.  Jer has already showed support for removing the "alternate names"
at least.

The only implementation which currently has an unprefixed implementation
which is close to shipping is Gecko, and I've said many times in this
thread that I'm open to delay shipping Web Audio in Firefox if we end up
making a large number of changes in order to improve the API.

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>