Re: XMLHttpRequest.responseBlob

On Thu, Apr 29, 2010 at 7:01 PM, Ian Hickson <ian@hixie.ch> wrote:
> 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.

Again, I think this is a very weird definition of "consistent". I
think it's more consistent to follow the hundreds of other properties
which use camelCase, than the one that is upper case. Despite the fact
that the one uppercase one has the same name.

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

The point is that once you've learned it, you'll be going off of your
memory. For cases where the casing isn't intuitive it can be hard to
remember the exact right casing. I know people have had trouble with
getElementById (vs. getElementByID) and XMLHttpRequest (vs.
XmlHttpRequest, or XMLHTTPRequest). I've personally had to remind
people of the correct casing of these on several occasions.

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

Given this, if we go with .url Opera will have to change one property,
webkit three and Gecko none. If we go with .URL Opera will still have
to change one property, webkit one and Gecko two. So equally many
changes in both cases.

So I think we should go with what's most memorable and most
consistent, which I argue is using lower case.

(Granted, I think counting property changes is pretty silly. Changing
browsers is significantly easier at this early stage than having
developers deal with in consistencies. So arguments about not changing
browsers doesn't sway me much, arguments as to what is more consistent
does).

/ Jonas

Received on Friday, 30 April 2010 03:44:30 UTC