On Thu, 29 Apr 2010 05:27:44 +0200, Jonas Sicking <jo...@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
