- From: Simon Pieters <zcorpan@gmail.com>
- Date: Fri, 15 Jun 2007 09:33:11 +0200
- To: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, "Bjoern Hoehrmann" <derhoermi@gmx.net>, www-style@w3.org
On Tue, 31 Oct 2006 00:48:03 +1100, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote: > Bjoern Hoehrmann wrote: > > * XBL 2.0 [...] does not explain how to resolve conflicts between > > namespace prefixes in selectors being case-insensitive, and > prefixes > > in Namespaces in XML being case-sensitive. >> * "Selectors API" [...] does not define how to handle case diferences > > either, >I think the best way to handle this would be for the Selectors spec to > define that the case sensitivity of the namespace prefix depends uponthe > mechanism used to declare it. >I think it could possibly be handled by adding a statement like the > following to the Case sensitivity section [1]: > The case sensitivity of namespace prefixes in selectors depends on the > mechanism used to declare them. For example, prefixes declared using > @namespace in CSS are case-insensitive, whereas prefixes declared > using xmlns are case-sensitive. >[1] http://www.w3.org/TR/2005/WD-css3-selectors-20051215/#casesens I just drafted the following text that I was about to propose for inclusion in the Selectors spec: Specifications using Selectors must define how namespace prefixes in selectors map to namespace prefix declarations. Namespace prefixes in selectors should be defined to have the same case-(in)sensitivity as the namespace declarations. Specifications may refer to a case-sensitivity definition from the table below: Case-sensitive Don't alter the case of the characters. ASCII case-insensitive For each character that is in the range [A-Z], add 0x0020 to the character's code point. ...however, now that I read through this thread again I found your proposal that I think is perhaps better than mine. In any case, it would be nice if the Selectors spec could address this issue in one way or the other. :-) -- Simon Pieters
Received on Friday, 15 June 2007 07:33:30 UTC