Re: [XBL] Animation element targetting

On Sat, 13 Jan 2007, Cameron McCormack wrote:
> 
> As it stands, XBL 2.0 does not afford any special treatment for SMIL 
> animation element in SVG.  We wish to have animation element targetting 
> (in case xlink:href is omitted) behave differently than would otherwise 
> fall out of the model.
> 
> There are three use cases we want to support for animation implicit 
> targets.  The first is using an animation element at the top of a shadow 
> tree to target the parent of the bound element:
> 
>   <xbl:binding element="ex|wobble">
>     <xbl:template>
>       <animateMotion d="M0,0 L10,0 z" begin="0s" dur="0.5s"
>                      repeatDur="indefinite"/>
>     </xbl:template>
>   </xbl:binding>
> 
>   <text x="50" y="50">
>     Some wobbling text
>     <ex:wobble/>
>   </text>
> 
> This use case is described in the last public SVG 1.2 Full draft’s 
> Binding chapter in section 3.6 [1].
>
> This defines an ex:wobble element that can be used in the same way as 
> other animation elements.  One way to achieve this is to define 
> animation elements as targetting the flattened tree parent, unless that 
> parent is the bound element that owns the shadow tree the animation 
> element resides in, in which case it targets flattened tree parent of 
> the bound element.  Such a definition is reasonably simple.

This seems like a generic problem with SMIL animation's extensibility, not 
just an XBL problem. Before this problem can be solved in XBL, we would 
need to know exactly what it is about <svg:animateMotion> that makes it 
special in terms of performing animations? Is there some DOM interface 
that it supports that hooks into animation? Is it UA-specific knowledge 
that means that <svg:animateMotion> elements perform animations on their 
parent elements?

If the latter (i.e. if the knowledge of what is an animation element is 
hardcoded into the UA) then what would need to happen is for XBL to have a 
feature that allows the UA to know that it is itself an animation element. 
For example, the <implementation> could define a new set of APIs that the 
UA invokes like the XBLImplementation APIs to do animation, or a new 
element as a child to <binding> could be defined to say what animations 
the binding applies to the bound element's parent, or to the bound element 
itself.

In both cases, this would seem to be better served by SMIL- or 
SVG-specific extensions to XBL, rather than as a general feature in XBL 
itself. In this, it is similar to the <traitDef> idea mentioned earlier.


> The second use case is where you want to target the actual bound
> element, for example if that bound element is a custom element with
> some traitDefs on it to respond to the animation.  For example:
> 
>   <xbl:binding element="ex|spiral">
>     <xbl:template>
>       <path …/>
>       <animate attributeName="turns" values="5;10;5" begin="0s" dur="5s"
>                repeatCount="indefinite"/>
>     </xbl:template>
>     <traitDef name="turns" namespace=""
>               valueType="http://www.w3.org/2000/svg#SVGNumber"/>
>   </xbl:binding>
> 
>   <ex:spiral/>
> 
> This needs a simpler definition: animation elements always target their 
> flattened tree parent.  It would also be the behaviour under XBL without 
> needing a special definition, AIUI.

This behaviour could indeed either be defined as the default behaviour of 
<svg:animate> and family, or it could be implemented using one of the 
mechanisms discussed above. Again, however, this seems to be specific to 
SVG or SMIL, and not necessarily an XBL issue.


> The third use case is where an animation element is a proper child of a 
> bound element, and the animation should target that bound element.
> 
>   <xbl:definition element="ex|diamond">
>     <xbl:template>
>       <path …/>
>     </xbl:template>
>   </xbl:definition>
> 
>   <ex:diamond>
>     <animate …/>
>   </ex:diamond>
> 
> It makes sense for this animation to target the ex:diamond element. 
> However, the standard XBL semantics would be for this element not to 
> have any effect since it is not selected for inclusion into the shadow 
> tree with an xbl:content element.

On the contrary, any element in the DOM retains its semantics in the XBL 
model and thus this case would work automatically if you define (as I 
assume, in the absence of a shadow tree concept, has already been done) 
the <animate> element to work on its DOM parent.



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


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


> Thus, to handle these three use cases, we suggest that the following 
> text (or other text that supports the same functionality) be inserted 
> into section 4.9.6:

I recommend that these new features be added directly to SVG rather than 
adding them to XBL. As with traits, they are language-specific and it does 
not necessarily make sense to add language-specific features to the XBL 
core. Indeed, XBL at the moment is markup-language agnostic; the markup- 
level features, such as xbl:attr, are designed to work with any language.


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

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.

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.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'