Re: Sites using webkitAudioContext only

On Fri, Jun 14, 2013 at 2:38 PM, Chris Rogers <crogers@google.com> wrote:

>
>
>
> On Thu, Jun 13, 2013 at 2:07 AM, Chris Lowis <chris.lowis@bbc.co.uk>wrote:
>
>>
>> Chris Wilson writes:
>> > Chris is absolutely correct that there are some critical apps out there
>> today
>> > that use the API as it is.  I would not, for example, like to be the
>> one who
>> > breaks the sound in Angry Birds
>>
>> I don't want to go to far off-topic, but Angry Birds is specifically
>> marketed as a Chrome application in their URL
>> (http://chrome.angrybirds.com/). Couldn't Chrome continue to support the
>> interfaces that Rovio have coded to if you were worried about breaking
>> the sound in that game, while still allowing us to make changes to the
>> spec?
>>
>
> Just to put things in perspective, this isn't specifically about Angry
> Birds, since that's just one example of all the content out there, large
> and small.
>

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.


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

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

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!


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