W3C home > Mailing lists > Public > public-appformats@w3.org > March 2007

Two more XBL2 Comments

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 27 Mar 2007 14:00:35 -0300
Message-ID: <46094DB3.5070800@sicking.cc>
To: public-appformats@w3.org

Hi XBL2 geeks!

Here are a couple of more comments on the XBL2 spec.

First thing is fairly simple:
The interaction between :root and orphaned nodes is undefined. This 
should arguably be fixed in the selectors spec, but XBL is the first 
case where matching can be done on orphaned nodes.

The second things is bigger though:
It is undefined if -xbl-binding bindings are applied if the element or 
one of its ancestors is display:none. From an implementation point of 
view it is really desirable that such bindings are not applied since at 
least gecko does not normally do style resolution on such nodes. We in 
fact don't resolve style on even the nodes itself other than to get the 
display value.

We also need to decide is if we should not apply -xbl-binding bindings 
when the element itself is display:none, or only when a parent is 
display:none. From an implementation point of view it probably works 
fine either way, however it feels more consistent and logical from a 
user point of view if this applies when the node itself is display:none, 
that way we never apply -xbl-binding bindings whenever an element isn't 
displayed, be it due to an ancestor or not.


A followup issue to this is if such -xbl-binding bindings are not 
applied sometimes, it may appear erratic to the author that properties 
are missing, potentially due to user stylesheets hiding part of the 
page. This is actually partially a problem already since such bindings 
won't be applied until the page is restyled.

We could deal with this several ways
A)
We could accept this and discourage authors to put API in -xbl-binding 
bindings.

B)
We could ignore the <implementation> in such bindings. However this may 
be a problem since it's likely that <handlers> would still be useful for 
the author to do hover effects and the like, but such handlers wouldn't 
have an <implementation> to interact with which would severely limit them.

C)
We could stop forwarding properties to <implementation>s of such 
bindings and hide the implementation objects from the 
.xblImplementations list.

I think C is preferable. But if we do that we should change the implicit 
inheritance order such that CSS bindings are last in the chain (section 
3.7.2). I think this is something that would be a good idea anyway since 
it seems like CSS bindings are more likely to be attached and detached 
often than DOM bindings.


Best Regards,
Jonas Sicking
Received on Tuesday, 27 March 2007 17:00:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:21 GMT