Re: Sites using webkitAudioContext only

I'm not sure what data Google has internally, but the vast majority of test
cases that we at Mozilla have heard about so far are small tech demos,
almost all of them explicitly targeting Chrome.  I'm still unconvinced that
the backwards compatibility is a real concern, I'm taking crogers word that
it is a concern for Chrome.  Of course there is one major point where we
disagree, and that is, I think it's OK for Chrome to break those tech demos
by dropping webkitAudioContext, and help the quality of the Web Audio spec
by doing that.  The few big players that are shipping apps/frameworks using
Web Audio targeted at users is a solvable problem through evangelism.

Cheers,

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


On Wed, Jun 19, 2013 at 5:14 PM, Kevin Gadd <kevin.gadd@gmail.com> wrote:

> Ah, I see. I didn't realize the 'long tail' was the problem here. I assume
> my previous suggestion of leveraging search spiders (googlebot, bingbot,
> etc) to find that long tail of web audio content is not feasible for some
> reason? That seems to me like the best way of finding that content; search
> spiders strive to index all content users visit, and to accurately
> represent the content users will actually get, so modern spiders should be
> at least aware of all the .js files that get pulled in (I know googlebot
> definitely runs JS)
>
> -kg
>
>
> On Wed, Jun 19, 2013 at 1:42 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>
>>
>> On Wed, Jun 19, 2013 at 3:47 PM, Kevin Gadd <kevin.gadd@gmail.com> wrote:
>>
>>> I'm a little confused on a detail here, so pardon my request for
>>> clarification:
>>>
>>> It seems like at present, we have effectively 'two different Web Audio
>>> APIs':
>>>
>>> AudioContext (and, to a degree, mozAudioContext), which are both
>>> theoretically implementations that attempt to conform to the
>>> spec-as-published
>>> webkitAudioContext, which conforms to an older version of the spec and
>>> is constrained by unfortunate backwards-compatibility requirements with
>>> existing applications
>>>
>>
>> Small correction, there is no mozAudioContext.  Our implementation is
>> unprefixed, and it follows the spec very closely, much closer than the
>> current WebKit and Blink implementation.
>>
>> But it is the spec itself which is constrained by the backwards-compat
>> requirements of Blink (and perhaps WebKit?).
>>
>>
>>> And then as I understand things, it is very difficult to remove
>>> webkitAudioContext from Webkit (to force use of the non-prefixed name) or
>>> make backwards-compatibility breaking changes, because of existing web
>>> content out there? This is also what's motivating discussions about Gecko
>>> possibly implementing the prefix, right?
>>>
>>
>> Correct.
>>
>>
>>>  Assuming what I stated above is correct:
>>>
>>> Would it be possible to do a 'least possible damage' sort of thing like
>>> MS tried to when they globally disabled plugins (like flash), where we
>>> whitelist known sites that need backwards compat and for whatever reason
>>> can't be updated? This would keep existing big names like Angry Birds or
>>> Turbulenz working in Chrome just like before, while limiting the spread of
>>> broken/old Web Audio to new sites - people would use the broken code and it
>>> wouldn't work (perhaps they'd even get an informative error in the console
>>> telling them why) Whitelisting production domains only would also ensure
>>> that anyone actively doing development against Web Audio would see these
>>> problems in their development environment (since it's not whitelisted).
>>> Even better, the whitelisting could function by loading a user script that
>>> defines webkitAudioContext in terms of spec-compliant AudioContext, and
>>> Firefox and other browsers could load that same user script to become
>>> compatible with busted old content on the whitelist.
>>>
>>
>> The big titles are *not* an issue, since Mozilla, Google, Apple and
>> others can just reach out to them and ask them to fix their stuff.  It is
>> the other content that is an issue, but we don't have data on what those
>> other content are.
>>
>> This is definitely one technique which can be employed to narrow down the
>> backwards-incompatibilty scope, but unless we have a list of such websites,
>> which we don't, it won't be very useful.  Also, it would be a very
>> unfortunate thing to do for the health of the web, but I understand that
>> sometimes pragmatism needs to prevail.
>>
>>
>>> 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.
>>
>> 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.
>>
>> Cheers,
>> --
>> Ehsan
>> <http://ehsanakhgari.org/>
>>
>
>