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

Re: [XBL] Namespace prefixes in Selectors

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 6 Oct 2006 22:50:21 +0000 (UTC)
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Simon Pieters <zcorpan@hotmail.com>, public-appformats@w3.org
Message-ID: <Pine.LNX.4.62.0610062238260.19875@dhalsim.dreamhost.com>

On Fri, 6 Oct 2006, Bjoern Hoehrmann 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.

Well, as it stands the paragraph has no normative weight, but you're 
right. Changed.

> 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?

Yeah that might work. Let me know when I can switch this over. (Doesn't 
matter if XBL is in CR or whatever when we do the change.)

>> 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.

I agree, but until I have something better to point to, I have to define 
this. Again, I'll change this when the other specs have caught up.

> 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.

I really need implementation experience on this before I can really 
specify it. I don't know what's easiest for UAs and the actual definition 
doesn't much matter (since it's really an edge case).

> 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.

Why is there a problem if they don't 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.

Depends very much on the implementation.

Really I want implementations to implement this however they find best, 
and then we can adjust the spec to match the most common implementation.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 6 October 2006 22:50:36 UTC

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