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". -ChrisReceived on Thursday, 20 June 2013 14:40:36 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:18 UTC