- 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