- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 28 Jun 2010 15:37:01 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Anne van Kesteren <annevk@opera.com>, 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>, Alexey Proskuryakov <ap@webkit.org>
On Mon, Jun 28, 2010 at 3:20 PM, Jonas Sicking <jonas@sicking.cc> wrote: > 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. I believe Alexey Proskuryakov has strong feelings on this topic. Adam
Received on Monday, 28 June 2010 22:37:52 UTC