- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 29 Apr 2010 07:11:06 +0200
- To: "Ian Hickson" <ian@hixie.ch>, "Jonas Sicking" <jonas@sicking.cc>
- Cc: "Darin Fisher" <darin@chromium.org>, "Web Applications Working Group WG" <public-webapps@w3.org>
On Thu, 29 Apr 2010 05:27:44 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>>> Can you change it back? We've implemented and written tests for
>>> WebSocket.URL. WebKit has implemented EventSource.URL and
>>> WebSocket.URL.
>>
>> Do you plan to implement the File API attribute as .URL also?
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0803.html
>> I really think we should make sure we end up with a consistent naming
>> scheme here.
I agree.
>> If Gecko is the only engine that's going to do .url instead
>> of .URL, then I'm happy to change it back (on the assumption that Gecko
>> will eventually be forced to change to match). However, it would be a
>> pretty mess if we ended up developing APIs in the same year that had
>> different cases for the same attributes.
>
> Out of curiosity, why does the year of the API matter?
Indeed. We should be consistent with document.URL also. :-)
> The way I look at it is: if you tell 100 developers that there is a
> property named 'url' on these objects (i.e. tell them, not show them
> in writing), how many of them do you think will envision it written in
> upper case characters, and how many will envision it in lower case
> characters?
1) I think it depends on whether they are familiar with document.URL or
not.
2) I think most developers learn by reading tutorials or view source.
>> Does anyone implement EventStorage.url, by the way? I noticed that one
>> was
>> lowercase in the spec while I was doing the earlier change.
You mean StorageEvent?
javascript:alert('url' in StorageEvent.prototype)
Opera: false
Firefox: true
Chrome: false
--
Simon Pieters
Opera Software
Received on Thursday, 29 April 2010 05:11:48 UTC