W3C home > Mailing lists > Public > www-tag@w3.org > June 2013

Re: Sites using webkitAudioContext only

From: Chris Rogers <crogers@google.com>
Date: Wed, 12 Jun 2013 10:43:29 -0700
Message-ID: <CA+EzO0mxkXuY1=XcaxhqEaW5VbDG=k-Ca331RhpKD3SD_hNWKA@mail.gmail.com>
To: Alex Russell <slightlyoff@google.com>
Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, Chris Wilson <cwilso@google.com>, Chris Lowis <chris.lowis@bbc.co.uk>, "Robert O'Callahan" <robert@ocallahan.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, "public-audio@w3.org" <public-audio@w3.org>, Dimitri Glazkov <dglazkov@chromium.org>, Anne van Kesteren <annevk@annevk.nl>, Yehuda Katz <wycats@gmail.com>, "www-tag@w3.org List" <www-tag@w3.org>
On Wed, Jun 12, 2013 at 8:53 AM, Alex Russell <slightlyoff@google.com>wrote:

> On Wed, Jun 12, 2013 at 1:01 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>> On Tue, Jun 11, 2013 at 7:44 PM, Chris Wilson <cwilso@google.com> wrote:
>>> On Tue, Jun 11, 2013 at 4:08 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>>> On Mon, Jun 10, 2013 at 12:23 PM, Chris Wilson <cwilso@google.com>wrote:
>>>>> I would actually strongly suggest that developers use a monkey patch
>>>>> library, like my paired set:
>>>>> https://github.com/cwilso/AudioContext-MonkeyPatch: This library
>>>>> should be used for new projects, which are written to the official Web
>>>>> Audio specification, and it should monkey-patch the calls on systems that
>>>>> may not support the most modern definitions (e.g. patching AudioContext to
>>>>> webkitAudioContext, and start() calls get patched to call noteOn()).  You
>>>>> could use this, for example, to get a properly written Web Audio app to
>>>>> work on iOS today.
>>>> I'm not sure how useful this is for the Safari problem, but as far as
>>>> Gecko is concerned, we fully support all of the alternate names mandated by
>>>> the spec, so if you just switch to using AudioContext, then everything
>>>> should work (including noteOn/noteOff, setTargetAtTime, etc.)
>>>> Can you please modify this library so that it doesn't touch
>>>> AudioContext?  I don't believe any of the AudioContext monkey-patching is
>>>> necessary any more.
>>> Umm, no, that's the point of the library - otherwise, you CAN just do
>>> audioctx = AudioContext || webkitAudioContext.  But read on...
>>>>  https://github.com/cwilso/webkitAudioContext-MonkeyPatch: This
>>>>> library can be used for old apps, written to webkitAudioContext
>>>>> implementations, to get them working on proper spec-compliant
>>>>> implementations of AudioContext (e.g. Firefox), without having to rewrite
>>>>> all your code.  This is kind of a cheap way to do this (obviously, for any
>>>>> significant app you should likely revise your code), but it makes it quick
>>>>> and easy to get old code working on Firefox if nothing else.
>>>> Given the above, all you have to do is to use the AudioContext
>>>> constructor, and fall back to webkitAudioContext if that's not available.
>>> I'm afraid I'm confused by what you want.  I'm going to share my
>>> personal thinking here, but understand that Chris Rogers and I disagree
>>> somewhat on some of the finer points, so this is not "the Google opinion".
>>> I personally think long-term, having "alternate names" is significant
>>> badness.  If they're important enough to implement everywhere, just use
>>> them; if your concern is just that your standard-following implementation
>>> doesn't "work" for all those webkitAudioContext, noteOn()-using apps out
>>> there right now, let's attack that problem together with some monkeypatch
>>> libraries and some evangelism.  If you're just going to implement them all
>>> anyway, then why do we change names and confuse developers by giving them
>>> two methods to do the same thing, that differ only in name?  The
>>> monkeypatch libraries, on the other hand, let us make these kind of changes
>>> and fix it up in the short term, letting developers be "clean".
>>> My personal belief is the "alternate names" should be removed from the
>>> spec long-term, as we migrate all the implementations out there to support
>>> the new names (obviously, iOS Safari is the least-known quantity here).  In
>>> the meantime, we can use evangelism of monkeypatching libraries to hide the
>>> implementation complexities across different browsers, and as we roll
>>> Chrome into unprefixed AudioContext, I would hope we could start removing
>>> some old stuff.  (Yes, this is where Chris and I disagree, I believe.)  I
>>> had not realized you were just implementing all the old names in Firefox.
>>> We have the unfortunate and difficult task of having multiple browsers
>>> implement the old names, under prefix, and a fair bit of legacy content
>>> that we do not wish to break, as well as the task of good stewardship for
>>> the long term.  I still think we have the opportunity to fix the long term
>>> without destroying the short term, but if I'm the only one who believes
>>> that's the approach we should take, I'll just delete those two monkeypatch
>>> repos and developers can use the || approach.
>> No, you're not the only person thinking that.  I agree that having
>> "alternate names" is significant badness.  Really, Web Audio in its current
>> form is not a great web spec.  It should probably use constructors instead
>> of creator functions, have a better interface for recording playback rather
>> than OfflineAudioContext, and probably have a singleton "context" object,
>> etc.
> I agree with all of this, and that's coming from someone who respects and
> enjoys the overall current design. The block processing system is
> fantastic, but the API is not. We can make it better backwards compatibly
> too, should compatibility be shown to be a huge issue with real-world data
> (which these discussions do not seem to have included to date).
>> The reason that we are stuck with "alternate names" and all of the rest
>> of the API badness in Web Audio _is_ Blink/WebKit resisting changing most
>> of the APIs.  (Actually most of this discussion was before Blink was
>> publicly announced, and from what I know resisting this is actually in
>> contrast to the new Blink policy, but Chris Rogers probably knows those
>> rules better than I do...)
> ...that's incredibly frustrating to hear. The WebKit world was different
> than the Blink world; Chris: do you think we have the ability to make these
> changes now?

There was nothing in WebKit's policy that controlled what Chrome shipped
with concerning these APIs, so this was not an issue.

The issue is that the names we're talking about (noteOn(), noteOff(), and
others) have been in use for over two years shipping in Chrome, and for
nearly a year in iOS and Safari.  These methods are about the most commonly
used in the whole Web Audio API, so removing support for them would wipe
out two years of content that has been produced.  This represents a set of
work which I consider significant.

Whether or not these names should be a part of the spec and how they're
described in the spec is one matter.  They were previously listed as
"recommended" by me, but others wanted me to make them be normative.

In any case, because these APIs have shipped for a significant amount of
time, it is up to individual browser vendors to decide how to support these
older APIs.


>> I initially resisted implementing the alternate names in Gecko, and I was
>> planning on resisting to implement some of the other bad ideas in the Web
>> Audio spec (such as the synchronous createBuffer override), but I changed
>> my position given the developer feedback of "Web Audio not working in
>> Firefox Nightly", etc.  For better or worse, Google pushed
>> webkitAudioContext as _the_ Web Audio standard to use way before the API
>> was looked at by other browser vendors, and now we're stuck with these
>> issues because WebKit/Blink will not accept "breaking" changes to their
>> implementation, and IIRC Chris Rogers said that even when it's unprefixed,
>> he's planning to maintain backwards compatibility with webkitAudioContext
>> APIs.
> From my perspective on TC39 and the TAG, it seems like unprefixing is the
> final chance to walk these decisions back and make final clean-ups. And
> that's not really related to the spec process except that they are highly
> correlated.
> I urge everyone here to take a second look: *can* the surface area for
> normative names be reduced? *Can* the create*() APIs be walked back in
> favor of constructors? *Can* the iterop story with the <audio> element be
> improved? If the practical answer, based on real-world usage is "yes", then
> now's the time.
>> I still believe that Web Audio is still not nearly as widely used as most
>> other web APIs,
> It's certainly not as widely used as many engine-specifc JS bugs and
> features which we are walking back/change over in TC39 land. As Yehdua
> said, "where's this magical land of compatibility? I build stuff on the
> edge of the platform and it breaks and changes all the time."
> Lets not tie ourselves down based on a promise that nobody is practically
> asking us to keep.
>> and the only engines shipping it have implemented it with a prefix.  We
>> still have time to fix this, but we need buy-in from WebKit/Blink (or at
>> least Blink).  If we get that buy-in, I will work on adoping all changes to
>> the spec in Gecko, even if it means that we would need to delay shipping
>> this in Firefox, since I believe that shipping a better API is better than
>> shipping a bad API sooner,
>> Cheers,
>> --
>> Ehsan
>> <http://ehsanakhgari.org/>
Received on Wednesday, 12 June 2013 17:43:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:56 UTC