Re: XMLHttpRequest.responseBlob

On Wed, 28 Apr 2010, Jonas Sicking wrote:
> >
> > I really think we should make sure we end up with a consistent naming 
> > scheme here. 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?

It doesn't, hence why I think we should be consistent and call them all 
"URL". My point is that while I can understand that we can't change 
Document.URL, if we decide that consistency with something else is more 
important for one API, e.g. "File.url", then we really have no excuse for 
being inconsistent with new APIs as well.


> 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?

I would have assumed uppercase, but I knew of Document.URL.

In practice, though, the vast majority of APIs are learnt through 
tutorials and documentation and visual presentations, surely. I don't 
remember ever learning one aurally (notwithstanding someone telling me 
what to type over my shoulder, but then they'd specify the case). So I'm 
not convinced this is a convincing argument either way.


On Thu, 29 Apr 2010, Simon Pieters 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

That doesn't really answer the question.


> > 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

These results seem inaccurate.

I used these two test files to test the 'storage' event:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/464
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/465

It seems WebKit has a 'uri' attribute, and Opera has a 'url' attribute.

Firefox doesn't support <body onstorage>, but using 
window.addEventListener() shows it has a 'url' attribute also:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/466

So we have

  Opera:
   Document.URL
   WebSocket.URL
   StorageEvent.url

  WebKit:
   Document.URL
   EventSource.URL
   WebSocket.URL
   StorageEvent.uri

  Gecko:
   Document.URL
   File.url
   StorageEvent.url

I don't know where to go from here. WebKit or Opera implementing File.URL 
or renaming StorageEvent's attribute to URL would be a clincher. Right 
now, Jonas does have a convincing argument in saying that, short of 
Document.URL, Gecko's platform offering is more consistent.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 30 April 2010 02:02:08 UTC