Re: Animation element targetting

dhalsim.dreamhost.com" type="cite">

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.
  

dhalsim.dreamhost.com" type="cite">

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&gt;
With what is currently suggested, this wouldn't be possible.

 

dhalsim.dreamhost.com" type="cite">

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.
  

dhalsim.dreamhost.com" type="cite">

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.

  

dhalsim.dreamhost.com" type="cite">

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.