- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 23 Mar 2006 19:04:57 -0800
- 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