Re: Sites using webkitAudioContext only

On Wed, Jun 19, 2013 at 1:42 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> But it is the spec itself which is constrained by the backwards-compat
> requirements of Blink (and perhaps WebKit?).
>
>> 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.
>

As have I, so no, it's not the difficulty of making changes to Blink (at
least, certainly not in the unprefixed AudioContext that we haven't shipped
yet).

I would say I would like to not continue to bikeshed issues like
constructors vs creators for an unspecified period of time, and that
changes on that level should not be considered without strong need.
 Removing alternate names is not a problem.


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.
>

Yes, which I think is the right thing to do.  But simultaneously, I feel
that pressure is being placed on Blink to remove its current somewhat
stable webkitAudioContext, and to sign up for an unbounded set of changes
to the API.

Sorry to miss the call this morning; but I really need to get on the road.