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

Re: ISSUE-102: CSS selectors for namespace prefixes

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 15 Nov 2006 17:16:26 -0800
Message-Id: <8C469E43-7502-459F-9906-36DDE479F647@apple.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-webapi@w3.org
To: Bjoern Hoehrmann <derhoermi@gmx.net>

On Nov 15, 2006, at 7:31 AM, Bjoern Hoehrmann wrote:

> * Boris Zbarsky wrote:
>> Anne van Kesteren wrote:
>>> FWIW, the current editor's draft says that user agents must pass the
>>> prefix argument lowercased (A-Z becomes a-z) to the  
>>> lookupNamespaceURI
>>> method of the NSResolver object or ECMAScript function. This should
>>> solve this issue.
>> Doesn't that make it impossible to match an uppercase prefix?  Or  
>> am I missing
>> something?
> As it stands, prefixes in a Selector do not have a case, "x|y" and  
> "X|y"
> are the same selector and the draft just defines that for both you get
> "x" as parameter to your lookup function.

I don't think the Selectors spec actually says that. It does say "the  
tokenizer is case-insensitive", but Bert Bos clarified that this  
doesn't mean selectors with different case are always identical, but  
rather that all rules with specific strings stated in lowercase form  
should be taken as using classes including both upper and lowercase  
versions of each letter (whew!). In fact, selectors x|y and x|Y are  
required to be different.

As far as interpreting a namespace prefix, Selectors says resolution  
is entirely up to the embedding language. It might be nice in any  
case to align with the CSS Namespaces draft and do something to case- 
fold, as described above, but it is in no way required by the  
Selectors spec.

I actually think it's a bit silly to make prefixes case insensitive  
even when declared in CSS, since the most likely use case is to match  
the prefix names in an XML document where they will be case- 
sensitive. But that is up to the CSS WG to work out.

Received on Thursday, 16 November 2006 02:50:47 UTC

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