W3C home > Mailing lists > Public > public-appformats@w3.org > October 2006

Re: [XBL] Namespace prefixes in Selectors

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Fri, 06 Oct 2006 09:28:26 +0200
To: Ian Hickson <ian@hixie.ch>
Cc: Simon Pieters <zcorpan@hotmail.com>, public-appformats@w3.org
Message-ID: <qvsbi25og7t131pq8jnm8f8bdqpj5uel2t@hive.bjoern.hoehrmann.de>

* Ian Hickson wrote:
>I've now explicitly mentioned that the "xml" prefix is always declared.

>xmlns is also now defined to be always declared. (Technically both of 
>these facts -- that xml and xmlns are always declared -- are already 
>stated in [XMLNS], but it makes no harm to say it again in the XBL spec.)

Then this text should be a non-normative note. You currently have

  Namespace prefixes can be used with selectors. In XBL attributes that
  take selectors, the namespace prefixes that may be used are the
  prefixes that are in scope using the xmlns:* syntax. User agents must
  use the XML namespace prefixes in scope on the attribute's element
  when parsing selectors with namespace prefixes. The default namespace
  in selectors in XBL attributes is always unbound ("*"). [XMLNS]

  The "xml" prefix is defined to always be declared (and bound to the
  http://www.w3.org/XML/1998/namespace namespace). The "xmlns" prefix is
  also defined to always be declared (and bound to
  http://www.w3.org/2000/xmlns/), but there really is no good reason to
  use that prefix in selectors, so authors are encouraged to avoid doing
  so.

I think DOM Level 3 Core should change Node::lookupNamespaceURI(...)
such that 'xml' and 'xmlns' are defaulted, and then define that the
set of prefixes considered in scope of a Node is the set of strings x
for which y.lookupNamespaceURI(x) is not null. You could then refer
to DOM Level 3 Core for what is in scope and simply point out that as
a result of the definition in DOM Level 3 Core 'xml' and 'xmlns' are
always in scope. Does that sound reasonable?

The reference to lookupNamespaceURI is somewhat necessary to handle
certain anomalies in the DOM, neither "the xmlns:* syntax" nor any
"xmlns:" is necessary to have a namespace declaration in the DOM, and
the DOM may internally not be namespace-wellformed; refer to e.g.
<http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0117>.

>Woops. This is actually a problem. Selectors are case-insensitive and 
>XMLNS prefixes are case-sensitive, so I need to declare how you map from 
>one to the other.
>
>I've tried writing some text for this.

As per http://lists.w3.org/Archives/Public/www-style/2006Oct/0025.html
I disagree with this resolution. As is evident here, this really belongs
to the Selectors specification to avoid having the problem in similar
specifications and to avoid different requirements in similar specs.

You fail to point out in the relevant section when implementations
determine the bindings and/or what happens if the bindings change. You
added this for xbl:inherits some time ago, but only for xbl:inherits.

And you say

  User agents must act as if all namespace prefixes in scope were
  lexically sorted by Unicode codepoint, with the first namespace
  prefix of each group of namespace prefixes differing only by case
  being the one assumed to be in scope for the purposes of selector
  matching.

This fails to account for the case where the two prefixes do not differ
in case. I would also prefer if sorting applied only if the conflicting
declarations are on the same element, and that implementations take the
closest declaration that matches case-insensitively otherwise. So for

  <foo xmlns:X='a'>
    <foo xmlns:x='b'>
      <foo selector='X|*'>

you get 'b' not 'a' (assuming you have ascending order, the text does
not say). Finding all declarations that match case-insensitively is
a lot slower in unoptimized implementations.
-- 
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 Friday, 6 October 2006 07:28:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC