Re: Web Audio API uses British spelling

Also, I would like to highlight again that the only reason why the amount
of current usage in the wild matters is because that affects the
WebKit/Blink decision on whether to update their implementation according
to changes in the spec.  If that was not a concern, it wouldn't make any
difference how popular a particular API was in a prefixed implementation --
otherwise we'd just be designing by committee.  :-)

Cheers,

--
Ehsan
<http://ehsanakhgari.org/>


On Wed, Jun 5, 2013 at 8:40 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

>
> On Wed, Jun 5, 2013 at 6:44 PM, Olivier Thereaux <
> Olivier.Thereaux@bbc.co.uk> wrote:
>
>> Ehsan,
>>
>> On 06/06/2013 06:17, "Ehsan Akhgari" <ehsan.akhgari@gmail.com> wrote:
>>
>> >I would be more than happy to change Gecko here, but given our past
>> >experience, it seems impossible to change WebKit/Blink, so this ship has
>> >probably sailed already. :(
>>
>>
>> Wait, let's not make this our default response. While we have been
>> struggling to make some changes, I think our baseline should be "these are
>> draft features which may or may not have been used by developers yet, and
>> probably were used behind the webkitAudioContext prefixed context.
>>
>> Until/unless Chris gets back to the group with data for significant usage
>> and a case for the difficulty of changing the interface, I'd rather we
>> considered the interface names fair game by default - at least for now.
>>
>
> I don't like to use this as the default response to these kinds of
> problems.  These types of issues seem to keep coming up every few days on
> this list, and I also hear a lot of complaints that are unfortunately not
> reflected on this mailing list.  But I actually think that these issues are
> very similar to the "alternate names" issue which has been heavily
> discussed in the past, and I don't see why we would want to address one but
> not the other.
>
> Currently I believe the only way to get to multiple interoperable
> implementations given WebKit/Blink's position is to not accept changes to
> the spec which those engines will not adopt.  This doesn't mean that I
> think it's a good decision to not fix these types of problems in the spec,
> but I still think we need to move within the boundaries of what's possible
> in practice.
>
> Cheers,
> --
> Ehsan
> <http://ehsanakhgari.org/>
>