- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 28 Jun 2010 15:20:45 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Eric Uhrhane <ericu@google.com>, arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
On Mon, Jun 28, 2010 at 3:06 PM, Anne van Kesteren <annevk@opera.com> wrote: > On Tue, 29 Jun 2010 00:01:14 +0200, Jonas Sicking <jonas@sicking.cc> wrote: >> >> I certainly agree that anyone shipping an implementation before a spec >> is an official Recommendation is always running the risk of running in >> to incompatible changes. However in the past we have avoided to break >> existing implementations, and I certainly can't think of a time we've >> decided to do it over what is essentially a bikeshed issue. > > Recently on your account a bunch of attributes named URL became url while > they were already deployed in browsers based on WebKit. ;-) First of all, iirc there was already internal inconsistency in that webkit shipped properties named both .url and .URL. And so if the webkit devs wanted consistent naming, which seemed like a priority for everyone. Second, the "url"/"URL" name is much less likely to be used by existing content than the the "FileReader"/"BlobReader" name. It is quite possible to use EventSource and WebSockets without ever using the "url"/"URL" name, however it is impossible to use a FileReader without using the "FileReader" name. Third, I don't believe anyone raised the concern that there was likely content out there depending on the existing name. / Jonas
Received on Monday, 28 June 2010 22:21:38 UTC