- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 15 Nov 2006 17:16:26 -0800
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-webapi@w3.org
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. Regards, Maciej
Received on Thursday, 16 November 2006 02:50:47 UTC