- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 30 Apr 2010 02:01:38 +0000 (UTC)
- To: Jonas Sicking <jonas@sicking.cc>, Simon Pieters <simonp@opera.com>
- Cc: Darin Fisher <darin@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
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