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

Re: XBL2 Comments

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 02 Apr 2007 16:06:55 -0700
Message-ID: <46118C8F.1050503@sicking.cc>
To: public-appformats@w3.org

A couple of notes just so I don't forget.

Jonas Sicking wrote:
>  >> 4.7.3
>  >> The dual meaning of the :bound-element pseudo class seems like a bad
>  >> idea from a usability point of view. It also makes it impossible to
>  >> match a bound element inside a shadow tree. Why not split it up into 
>  >> two selectors?
>  >> What is the usecase for matching all xbl-bound elements in general?
>  >
>  > It isn't clear that matching a bound element in general is a useful
>  > thing. That this is possible at all is mostly the result of defining
>  > what should happen in the absense of a bound element, rather than the
>  > result of an actual use case.
> 
> I suggest we remove that feature since it seems just to add unnecessary 
> bloat to implementations. Additionally, it seems harder for authors to 
> use the selector since something like
> :bound-element{border: red}
> would not only add a border to the bound element that the current 
> binding is attached to, but also add borders to all bound elements in 
> the bindings shadow tree.

Hixie pointed out to me that there is no dual meaning. :bound-element 
simply means one thing when used in a bindings <style> and another thing 
elsewhere. However I still don't see the use for the "other" use and I 
think it should simply not match anything when used somewhere else.

Even if it was useful to match all elements with bindings, the current 
solution isn't good since it can't be used inside bindings (to match all 
elements in the shadow tree that have bindings) since :bound-element 
means something else there.

Simply, I think the current solution is mostly confusing and adds little 
to no value.

>  >> And does the includes attribute have any effect when locked is true?
>  >
>  > Yes. See later in the spec, where this is covered in detail.
> 
> What is the use case for the includes attribute on locked insertion 
> points? It seems confusing to the user that children can be removed even 
> though the element is locked. Granted, we have to define something, but 
> it seems to me that the simplest solution, i.e. locked means locked and 
> the user is fully in charge of managing the list of inserted children, 
> works just as well.

As a side note, I don't really feel strongly about this.

>  >> 3.5)
>  >> It is unclear to me if it currently is allowed to call the
>  >> xblBindingAttached/xblEnteredDocument functions after all bindings have
>  >> been constructed and attached for a subtree. This is vital for styling
>  >> performance since we don't want to have to return to the main event 
>  >> loop for each bound element during layout.
>  >
>  > I wouldn't attach during layout. I would just make a note of what
>  > bindings need to be applied, and when you have finished your style
>  > pass, apply those bindings and then do layout again.
> 
> But then it would only be possible to style up to the bound element 
> since before bindings are attached it is impossible to know what 
> children the flattened tree will have. In XUL practically every element 
> has a binding so this would render one element at a time, which of 
> course is unacceptable.

I *think* with the current spec it is possible for the implementation to 
create all shadow trees for a document during styling, but only create 
the implementations and call xblBindingAttached/xblEnteredDocument after 
styling is fully done. If this is not possible though we need to fix the 
spec since this is critical for performance.

>  >> Why does setting the [xml:base] not cause a mutation event?
>  >
>  > No mutation events must be fired at all during the entire cloning
>  > process, because there didn't seem like a good reason to have them
>  > fire and it would allow performance improvements to block them.
> 
> Hmm.. Saying that no mutation events at all fire during the above is an 
> interesting idea. However it's only taking us part of the way. At the 
> very least you should say that userdata handlers are not notified of the 
> cloning either. I'm worried that there are other events or notifications 
> that would normally fire that you'd want to avoid firing too. I don't 
> see any other solution than that the spec contain a comprehensive list 
> of which notifications are blocked, but that seems hard or impossible 
> considering future specs.
> 
> This seems like it could be hard to implement if existing APIs always 
> fire mutation events. It turns out in mozilla that we currently have a 
> flag for not firing them when performing certain mutations, however this 
> is a recent flag, and it's one that I've been wanting to remove.
> 
> I wonder if this is an optimization that is really doable, though it 
> would be really nice if it was.

I take it the optimization that you're trying to allow here is to allow 
the implementation to lazily create the shadowtree only if an explicit 
copy is needed, such as when the .shadowTree property is accessed. And 
before then render the same shadowtree DOM (but with different styling) 
every place where the shadow tree is rendered.

Allowing this optimization would be great (though gecko wouldn't be able 
to do that quite yet due to limitations in the layout code). But I think 
we need to find a different way to allow it since the above have too 
many problems.

First of all it requires that the implementation is able to clone a DOM 
without firing mutation events, weather it performs the optimization or 
not, which is bad.

Second, it doesn't take into account other specs, like UserData. And it 
couldn't possibly take into account future specs.

In order to fix this we could either say nothing and leave it up to the 
implementation to do the best it can. It would have to detect if there 
are mutation event listeners and simply not perform the optimization in 
that case. This would take care of the problem of other specs since the 
implementation knows what other specs it implements and would know what 
types of listeners to look for.

The other solution is to explicitly say that the implementation is 
allowed to clone the shadow tree later than it renders it. We'd need to 
state that when the .shadowTree property is accessed the tree must be 
cloned at that point if it hasn't been by then.

/ Jonas
Received on Monday, 2 April 2007 23:07:30 GMT

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