Re: Sites using webkitAudioContext only

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

> On Tue, Jun 18, 2013 at 10:39 AM, Chris Wilson <cwilso@google.com> wrote:
>
>> Hmm.  I'm not sure what to say.
>>
>
> I'm not sure what to say either.
>
>
>> I'm not sure we're coming out so far ahead as you think we are.
>>
>
> It's stark enough. Existing content (of which there is a fair bit) works
> in Chrome and not Firefox.
>

"Of which there is a fair bit" does not seem compatible with Ehsan's
statement.  If you think the usage of webkitAudioContext, etc is like usage
of XMLHTTPRequest, then by all means implement it as-is.  If not, let's fix
it and we'll move everyone to the standard one.

We can't choose to be incompatible with Web content for another year.
>

If you're demanding that we remove webkitAudioContext on your defined
timeline, then we can just stop now and you can implement
webkitAudioContext.  I'm sad that it took so long to get others interested
in building Web Audio implementations, but I will hardly apologize for
Chrome's investment and success in building a great useful API.

We owe it to those who built early code to not just shoot them in the head,
and be responsible.  We are also completely invested in defining and
standardizing on one specification, and not only evangelizing for the
future but helping get current code changed.

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.
>>
>
> If this matters to you, then drop webkitAudioContext from Chrome.
>

And indeed, I've said (multiple times now) that we intend to do so, in a
responsible manner prefaced with heavy evangelism to developers to write
standards-compliant code.  If you (or anyone else) had been implementing
Web Audio a year (or two) ago, then such a mass of content wouldn't have
been developed- we'd all have unprefixed implementations that were
interoperable.  The long incubation of the prefixed Web Audio (and the
number of places webkit ships), and the developer demand for such an API
have also contributed to this.

In the future, I believe Blink's commitment to using channels rather than
prefixes will help avoid this problem, but that doesn't mean we should just
blow webkitAudioContext away with an elephant gun today.

-Chris