Re: Sites using webkitAudioContext only

On Fri, Jun 14, 2013 at 2:10 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> What are the other examples?  It's really hard for us to have a concrete
> conversation about this without having data, so it would be tremendously
> helpful if you could share data on some high-profile web apps/libraries
> that are currently shipping code using Web Audio, and are not merely tech
> demos or old Web Audio tutorials.  The way that we should handle this
> question would be a lot different if we knew there is only a handful of
> those, versus hundreds of thousands.
>

To be clear - right now, I don't believe we have concrete, broad data about
specific Web Audio API usage across a broad segment.  We do know there are
a significant number of sites (and Chrome apps, of course) that use the
API; we don't know specifically which parts of the changes might break them
(although, of course, the changes like noteOn() are pretty incompatible).
 We've looked at how to possibly collect meaningful data, but I think I'm
safe in saying it's not a handful of *user* instances, but it is probably
not hundreds of thousands of separate applications, either.

In short; we're not willing to yank the rug out from under developers who
have built applications on Chrome's webkit-prefixed Web Audio
implementation, but we do want to migrate everyone to a clean, unprefixed
implementation of the same standard implemented by everyone else.


> But yes, we can certainly work on making these names non-normative while
>> still maintaining backward compatibility in Chrome.  I have never been
>> against different ways of handling this in the spec.  I started out
>> mentioning these old APIs as "recommended", meaning they were not
>> normative, and the section was simply there in an appendix to show how the
>> API has changed, an informational section which seems very useful for
>> developers to know about.
>>
>
> I'm very happy to have WebKit on board with removing this support, and I
> am planning to remove it from Gecko as well.  For the prospect of
> interoperability, it would be really great if we had Blink on board as
> well.  Can you please share your plans on whether you're open to remove
> these names from Blink, and whether you're considering doing that at the
> same time as unprefixing, or before then?
>

We are open to removing the old names from Blink; however, I expect we will
begin by offering a clean unprefixed version, and work hard at evangelizing
to move developers over to that standards implementation; we can then
remove the prefixed version at some point in the future (after doing
console warnings, etc., to deprecate its usage).

Regarding the spec, I think it's better to remove all mentions of these
> names.  It feels very weird for the spec to prescript non-normative APIs,
> just because they were included in an early draft.  Even if Blink decides
> to not remove these methods, this should be handled as a Blink specific
> spec non-compliance (but I do hope that will not be the case.)
>

Then I think that's the path we should go down.  I think that we should be
moving to a clean, unprefixed version, hopefully in concert with the
implementation in Mozilla and with a release of Safari as well, and the
only non-compliance we would have in Blink is an additional webkit-prefix
implementation that persists for a while for compatibility reasons, until
we are comfortable removing it.  Clearly, though, we will be evangelizing
developers to use the standard unprefixed implementation (including
approaching developers to update their old code) - it is better for
developers to build on the standard anyway, as they will have broader
compatibility.


> Also, given the interest expressed over this thread and others on
> public-audio regarding the quality of the Web Audio API, I'd like to open a
> discussion about more drastic changes to the spec at some point very soon.
> But I think we should first settle on a solution for this problem, as it's
> probably going to be the easiest to deal with!
>

That statement really concerns me, as if there are going to be any drastic
changes - any breaking changes, in fact - we should have them on the table
now, particularly prior to shipping any unprefixed version.  I don't think
we can discuss these issues separately.

Perhaps we should have all the issues on the table that are significant
name changes, and go through them, in the very near future.

-Chris