Re: Sites using webkitAudioContext only

On Wednesday, 12 June 2013 at 18:43, Chris Rogers wrote:

>  
> 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.
Right, but what that content is needs to be seen in the overall role this API has to the future of the Web - it's an absolutely critical/fundamental API. A couple of Webkit-only demos being broken (even if they are high profile) to make an overall more useful API is a small price to pay in the long run, no?   

Also, i know from first hand experience that lots of content that works in Chrome does not work in iOS - so it's not fair to try to say they compliment each other. The same applies with Chrome and Webkit. Content is broken all over the place across these browsers even with very simple code.   
> 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'm still very confused as to how something behind a webkit prefix can be considered to have wide usage? As with CSS prefixes, it should be largely expected by developers that something that is initiated with:

var x = new webkitAudioContext();  

Is essentially bound to webkit and for the sole purposes of trying out stuff that is not final, stable, or standardized (that's the point of an API prefixing experiment, no? use at your own risk, but let us know if it works!… oh, and no guarantees about your stuff not breaking.). So, by the rationale you are giving, we should also standardize "webkitAudioContext" just because some people are using it.  

I kindly ask that you, as the Editor, to consider the longevity of this API and it's role in the platform - particularly in the long term. If the API can be improved before Last Call, then we should work towards doing that as quickly as possible. I'm certainly not proposing that we start again or anything - as Alex has stated, the components that make up the API make good sense… it's just some parts of the API are a little funky and could be improved.  

--  
Marcos Caceres

Received on Wednesday, 12 June 2013 18:35:43 UTC