On Sun, Jun 16, 2013 at 4:45 AM, Chris Wilson <cwilso@google.com> wrote: > If you ship only the new names, a lot of existing content won't work. If > you ship the old names, but not webkitAudioContext, still a lot of existing > content won't work. > Hence this thread. > That content was developed to a prefixed, potentially non-standard > implementation, by definition. Unless your goal is to exactly replicate > the webkit-prefixed platform that content was written on, it's not all > going to work. > Having some things not work is OK. Having lots of important things not work is not OK. There are tradeoffs here and it's rational to choose a non-end-point. > We need to be realistic - today, there is no shipping implementation that > even uses the correct unprefixed name, so anyone who writes var ctx = > AudioContext is just being hopeful. > Web developers tend to do that. Which is one reason why prefixing fails. > - but we need to be realistic that on day one, all the content developed > to the nascent webkit/blink implementation is not going to work on a > standards implementation, and some of it never will (if it's never > maintained). > We might be able to get close without much work. I think we (Mozilla) should put the non-standard names behind a pref and put webkitAudioContext behind another pref. Then as our Web Audio implementation marches through our release process, users and developers can easily experiment to see how much compatibility we get by turning on those features. If we get valuable compatibility, the argument for defaulting on the necessary prefs is strong. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Received on Monday, 17 June 2013 22:03:50 UTC