Re: [XBL] Animation element targetting

Hi Ian.

Sorry for the delay in getting back to this.

Cameron McCormack:
> > 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.

Ian Hickson:
> 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.

It is UA-specific knowledge, yes.  For SVG without XBL, there is a
defined set of elements that are animation elements (that all happen to
implement a particular interface, but it’s not that interface the allows
the animation to happen).

I agree, the suggestions I made do seem a little out of scope for XBL.
But changes to other languages are made in XBL (e.g. defining how CSS
works across shadow scope boundaries).

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

I agree, if there is to be a default behaviour for animation targetting,
this would be it.  Even aside from this discussion about different
styles of animation targetting, I think the section on SVG specific
behaviour of XBL would benefit from mentioning this.

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

Unless the default behaviour I mention above were included. :)  So yes
it is currently defined to animate the target of the animation element.

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

Ok.

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

I don’t have one, really.  But the parallels are there: you write an
xbl:content element to conditionally include some rendered content, so I
can imagine the possibility for wanting to conditionally include some
rendering control content (the animation elements).  If I think of a
concrete use case I’ll let you know.

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

Ok.

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

Right, but the animation elements that are children of the animations
element would need to be cloned as with the template element, because
each animation element will need to have separate timing.  Would it
be OK though for SVG (or a separate specification) to define where these
would fit in to the flattened tree?

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

Sure.

I will discuss this further with the SVG WG later this week and follow
up.

Thanks,

Cameron

-- 
Cameron McCormack, http://mcc.id.au/
 xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

Received on Monday, 22 January 2007 11:56:53 UTC