Re: [XBL] Animation element targetting

Hi again.

This is a response from the SVG WG.

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

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

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

After discussions in the group we resolved that we would like the
animation targetting control features, whatever they end up being, to be
included in the XBL specification.  XBL has descriptions of how
processing of CSS changes in the presence of XBL, and CSS is optional,
so it should be no more difficult or an impediment for implementors to
have similar specification of how animation targetting works in the
presence of XBL.

Thanks,

Cameron
-for the SVG WG

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

Received on Thursday, 8 February 2007 02:38:29 UTC