W3C home > Mailing lists > Public > www-style@w3.org > October 2006

Re: [css3-selectors] Namespace name lookup mechanisms

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Thu, 19 Oct 2006 19:42:34 +0200
To: Bert Bos <bert@w3.org>
Cc: www-style@w3.org
Message-ID: <q6vej2ldp4v9sg9eia04mldhkhvq495lao@hive.bjoern.hoehrmann.de>

* Bert Bos wrote:
>I think it's a good idea for the Selectors spec to say explicitly that 
>the namespace prefixes are case-insensitive, but it has no business 
>saying anything about canonicalization, APIs or the scope of prefix 
>declarations.

The Selectors specification just notes "The mechanism for declaring a
namespace prefix is left up to the language implementing Selectors".
XBL2 did so, but that did not result in an unambiguous definition of
when an element matches a selector. I think a complete answer to the
question

  What do specifications that wish to use selectors and namespace
  prefixes in selectors have to define in order to achieve an un-
  ambiguous definition of when an element matches a selector that
  contains one or more namespace prefixes?

is perfectly in scope of the Selectors specification. As it stands,
the answer provided in the draft is incomplete. This needs fixing.
I am less concerned about how this is done exactly. My proposal is
a processing model that other specifications can easily normatively
refernce. It may be ...

>Some other technology that uses Selectors can define these aspects any 
>way it likes: case-preserving or not, normalizing or not, lexical or 
>dynamic scope. It would be good if two similar APIs made similar 
>choices, but the Selectors spec doesn't need to say what those choices 
>should be.

... that parts of it do not "need" to be in the specification. What
we have now is a specification claiming that "given an element and a
selector, this specification defines whether that element matches the
selector" which is true only if you don't have namespace in the mix.
My proposal defines, given an element, a selector, and one of

  * a hash with case-sensitive keys
  * a hash with case-insensitive keys
  * an algorithm to resolve prefixes

whether the element matches the selector. Specifications using the
Selectors specification then simply have to define the hash or the
algorithm to be used. I think that this is also in scope of the
specification. Keeping the specification as is would leave us with

  [ mechanism for declaring a namespace prefix ]
                        |
                      magic
                        |
                        v
               [ selector x element -> boolean ]

Do you have some other proposal for how to remove this magic bit?

(I note that some of these problems also apply to default namespace
declarations; the current draft does not even say that the mechanism
for declaring a default namespace is to be defined by other specs.)
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Thursday, 19 October 2006 17:49:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:47 GMT