On Mon, Jun 17, 2013 at 7:05 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
> For whatever that's worth, I'm fairly strongly opposed to Mozilla (or any
> other engine for that matter) to ship webkitAudioContext, because firstly
> it will make it impossible to finally get rid of the long tail of small web
> applications that depend on it, and it will be a point at which we will
> have a harder time resisting implementing all of the existing WebKit/Blink
> bugs where they don't fully adhere to the spec. I also believe that it's
> damaging to the Web for an engine to ship a prefixed implementation of
> another engine, since doing that has the potential of setting that into
> stone for an extended period of time, once web developers realize that
> their content using webkitAudioContext suddenly starts to work in Firefox
> without modifications.
>
Good. I agree with you on all these points. :)
> I'm less opposed to implementing the alternate names behind a pref, if
> that pref is set to off by default.
>
I'm less opposed, too, although frankly I think I don't see a ton of end
user value in it. But go for it if you do; as long as it's off by default,
I think it's under the rubric of "developer feature".
> Also, I'm still quite hesitant to believe that there is a lot of important
> Web content (that is, not Chrome apps, or content that depends on other
> Chrome specific features) out there that uses Web Audio. We don't really
> have any evidence to believe that, and it seems like we have no data to
> prove me wrong. :(
>
OK. But we keep going back and forth here - not a lot of important web
content using web audio, vs "we need compatibility with the web content out
there that works in webkit".
-Chris