W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: ISSUE-46: DOM3EV: createEvent case-(in)sensitive?

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 23 Mar 2006 19:04:57 -0800
Message-ID: <442361D9.2080200@sicking.cc>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Web APIs WG <public-webapi@w3.org>

Bjoern Hoehrmann wrote:
> * Web APIs Issue Tracker wrote:
>> We don't say whether createEvent performs case-(in)sensitive comparison
>> with its argument. It should be case-sensitive but some implementations
>> disagree. I can't remember seeing a script that uses other spelling than
>> what we have in the document, and we don't disallow (or discuss in any
>> other way) proprietary extensions relative to createEvent(...), so it's
>> fairly save to specify that it's case-sensitive.
>> If other disagree and want case-insensitive comparison, we need to de-
>> fine the algorithm for that. In Unicode there are several ways to do
>> that, assuming that we do not prohibit proprietary extensions that use
>> non-ASCII characters. I guess we should use simple case folding then,
>> but let's rather make it case-sensitive...
> A probably yet more backwards-compatible way to do this would be to say
> that the DOM Level 2 names are case-insensitive and the new DOM Level 3
> names are case-sensitive.

I'm not very exited about that idea, that seems to make things more 
complicated then necessary. Perhaps not from an implementation point of 
view, but from an author point of view.

Honestly, I don't care much what we do either way on this. While this 
feels like it should be case sensitive since we're talking about 
interface/class names which in most languages are case sensitive, I 
don't see a whole lot of disadvantage with making it case insensitive.

Ideally all names should have been lowercase and then everyone would 
have been happy.

/ Jonas
Received on Friday, 24 March 2006 03:20:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC