Re: [XBL] Animation element targetting

[Cyril Concolato]

Hi Ian, Disadvantages of this approach include the fact that it breaks the view that the flattened tree is the only thing that determines the rendering behaviour in the document, This is not intended to be the XBL model; the final flattened tree is merely what is actually rendered, not what affects the rendering. Since animation elements are presumably all display:none, they are not rendered anyway and thus the issue of the final flattened tree is moot for them. This point should be improved in the specification. It is unclear for me how the final flattened tree (FFT) is used in a complete application (not just an XBL processor). I found three sentences about how the FFT is used. Those are: "The final flattened tree determines how CSS properties are inherited. " "The rendering is performed using the final flattened tree." (BTW this sentence should not be in a CSS specific section as it applies to rendering in general, i.e. even for UA not supporting CSS) "Events must flow through the final transformed content model" These sentences describe the behavior for cascading, rendering, interactivity, but clearly the specification is lacking a part a similar sentence for timing/animation behavior. and also that it would be impossible to write a binding that excludes some of the child animation elements (by not including them with an xbl:content). Could you elaborate on the use case for this? If as you suggest, even if an animation element is not assigned to a content element in the binding, it still animate, you have two problems: - first, inconsistency with the general rendering rule. The general rule in XBL for rendering is: if a child element of a bound element is not assigned to content element (i.e. not part of the final flattened tree), it is not rendered. One could expect the similar behavior: if a child element of a bound element is not assigned to a content element, and it is a timed element (animation or media), it is not animated. - second, you wouldn't be able to design a binding that removes an animation. Consider the following example, a rect whose color is animated. Suppose that I apply a binding to all rectangles to remove all sub-animations for whatever reasons (say I don't like animated rectangles ...).  <rect …> <animate/> </rect> With what is currently suggested, this wouldn't be possible. An alternative solution to use cases 1 and 2 (targetting parent or bound element parent) is to introduce an 'animations' element that is a child of the binding element, which holds animations that will target the bound element’s parent. For example: <xbl:binding element="ex|wobbleAndFlash"> <animations> <ex:wobble/> <set …/> </animations> </xbl:binding> <circle …> <ex:wobbleAndFlash/> </circle> The way the animations element would work is to, like the template element, clone its contents when the binding is applied, but its contents would be inserted into the fully flattened tree as (following) siblings of the bound element. A disadvantage with this approach is that it would be difficult to restrict the 'animations' element to have only animation element children. Thus it’s more of a 'followingSiblingTemplate' element. I would recommend following a mechanism similar to this idea but instead modelling it on the <handlers> element -- when looking for animation elements that apply to the bound element, one could look at the direct children of the bound element _and_ at any <svg:animations> elements of any bindings that apply to it. An attribute on this element could also make it possible to use this element with the parents of the bound element. I would remove "the direct children of the bound element", and say that: - only the ones in the <animations> element would apply to the bound element. - and that the ones in the shadow tree appy to the parent of the bound element. By keeping these features in a separate specification, they can be updated independently of the XBL specification itself, enabling faster turnaround and a more modular approach. I don't understand the difference between the handling of events and the handling of animations. Handling of events would be described in the XBL spec while animations would be in a different spec. The <handlers> element and the <animations> elements are very much alike. Keeping the XBL2 specification smaller is also one of our design goals, as we would like to allow more implementations to help XBL2 exit CR, and not all those implementations will necessarily support SVG and animations. Not all will support events either. Cyril