Re: Sites using webkitAudioContext only

On Mon, Jun 17, 2013 at 3:27 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Tue, Jun 18, 2013 at 10:09 AM, Chris Wilson <cwilso@google.com> wrote:
>
>> I'm confused as to whether you're prioritizing support a great Web Audio
>> standard, or being compatible with "all the content" currently out there.
>>
>
> We're juggling both. And ultimately, a Web Audio standard that doesn't
> match the content that's actually out there is no standard at all.
>

To be clear - I agree with you, a Web Audio standard that doesn't match the
content that's actually out there is no standard at all.  So - we can
either choose to leave the standard where webkitAudioContext was six months
ago, or we can  change the content that's out there through evangelism.

See above.  I can guarantee you will get much more compatibility if you
>> replicate webkitAudioContext and the old names; that doesn't mean it's a
>> good thing to do for the health of the web (particularly as it makes it
>> nigh on impossible to ever get that stuff OUT of the web platform).
>>
>
> I don't feel good about this sort of compromise. But it also doesn't feel
> good to have one vendor ship and evangelize prematurely, then reap the
> benefits of being compatible with Web content while other vendors eschew
> compatibility to try to fix the Web.
>

Hmm.  I'm not sure what to say.  Webkit shipped a prefixed implementation,
because that was the way non-fully-standardized things were shipped back
then; Chrome evangelized it, because it was very cool technology (and FWIW,
we're more cautious about evangelizing such things now), and we wanted web
developers to hear about it; now we're making changes that will be
incompatible, and expecting that we need to re-do a bunch of evangelism,
because it's the right thing to do.  I'm not sure we're coming out so far
ahead as you think we are.

The best thing that will happen to web audio will be for us to hammer out
the last few issues, Mozilla to ship unprefixed, Webkit and Blink to also
ship compatible implementations with that, us all collectively to
evangelize the heck out of that, and in a year, this will not be a problem.
 I absolutely, 100.00% want Mozilla to get the credit you deserve for
building an implementation; if that's backing up the answers to Mozilla
bugs that say "web audio doesn't work" then fine.

There is another option we could take, which is to very closely follow what
> Chrome has (or will have): a webkitAudioContext with all the compatibility
> stuff (except for data races!), and a standard AudioContext without the
> compatibility stuff. That might be the way to go. At some point in the
> future we can agree to drop webkitAudioContext together (or not).
>

As in many other areas that we've had this discussion over the past year
and a half - if Mozilla ships a webkit-prefixed property, I think it's game
over, and that prefix (and any associated oddities) are going to be part of
the standard forever.  It's not a question of eventually removing it then.

-C