Re: Sites using webkitAudioContext only

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