Re: Sites using webkitAudioContext only

On Fri, Jun 14, 2013 at 4:17 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Sat, Jun 15, 2013 at 9:45 AM, Chris Wilson <cwilso@google.com> wrote:
>
>> We are open to removing the old names from Blink; however, I expect we
>> will begin by offering a clean unprefixed version, and work hard at
>> evangelizing to move developers over to that standards implementation; we
>> can then remove the prefixed version at some point in the future (after
>> doing console warnings, etc., to deprecate its usage).
>>
>
> The problem is that this all needs to be done very soon.
>

Indeed, I can understand why this is time-critical for Mozilla, as you need
to make decisions before shipping.  That's why I'm even MORE concerned
about the introduction of the possibility of "more drastic changes",
because any even medium-sized changes (and definitely something as major as
changing the constructor pattern) is going to change this discussion.

Mozilla needs to ship something soon; we're hoping to ship in a release in
> about 14 weeks. If we ship only the new names then a lot of existing
> content won't work, even content that authors expect should work since they
> used AudioContext || webkitAudioContext, or similar. People will complain
> that our implementation is broken and get the impression Web Audio doesn't
> work properly in Firefox. That is very damaging and takes a long time to
> recover from.
>

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.  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.  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.  I believe
we (me, in particular) owe a responsibility to get that content migrating
to the proper, standards-specified implementation, and I CERTAINLY am
responsible for getting the guidance on HTML5Rocks to show proper usage,
but we have not been able to start that yet - 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).


> So, I'm adamant that whatever we ship needs to be compatible with where
> Chrome is going to be in 3 months, at least for authors who've done
> AudioContext || webkItAudioContext. So if Google can't commit to removing
> the old names from AudioContext in a Chrome release by then, I think we
> need to keep them. (Retaining them in webkitAudioContext may be OK.)
>

So, I think around the time Mozilla releases (or at least, not too long
thereafter), I'd like for Chrome to release unprefixed as well.  I'd like
that unprefixed implementation to follow the specification, and to not have
the old property names in that unprefixed implementation.  However, I don't
believe in three months we will have removed the old property names from
webkitAudioContext, nor removed webkitAudioContext altogether - that will
take longer.  This overlap may cause some compatibility issues;  however,
I'd point out that even shipping an unprefixed clean implementation
alongside webkitAudioContext is going to break a fair bit of content for
us.  There's a subtle but important difference between
    var ctx = AudioContext || webkitAudioContext;
and
    var ctx = webkitAudioContext || AudioContext;

At the same time - BEFORE that time - I will edit the articles in
HTML5Rocks to show proper guidance on prefixing, and use proper (new)
naming for things like noteOn/noteOff.  In fact, it would probably be good
to write an article that gives direct guidance on how to write content for
the best compatibility and future-proof-ness.  I haven't gotten to that
yet, but I will.

-Chris

Received on Saturday, 15 June 2013 16:45:59 UTC