Re: [XBL] Animation element targetting

Hi, Ian, WAF WG-

Ian Hickson wrote:
<snip />

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

<snip />

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

I personally think this is a very sensible suggestion.  There are ups 
and downs to the idea of creating a separate spec, though.  You've 
listed the major advantages, all of which I agree with.

Additional advantages:
* allows experts in a particular technology (in this case, the SYMM & 
SVG WGs) to more directly satisfy the needs for that technology

* limitations of XBL with a particular technology can be discovered by 
the many eyes of authors working in the wild, on actual implementations, 
who might find workarounds or optimal solutions that could be 
incorporated into "XBL extension" specs.  No matter how well a spec is 
designed, the creators of that spec can't anticipate every common use 
case, and rapid feedback will be really valuable

* in theory, any such "XBL extensions" that prove particularly effective 
and generically useful could be folded into future "standard" versions 
of the XBL spec


Disadvantage:
* as with "profiles", there's a risk that "XBL extensions" aren't widely 
implemented, decreasing the likelihood that authors can rely on that 
capability

* dramatically increases the "time to market" for that particular 
technology's use of XBL

* languages must conform to and special-case for XBL, rather than vice 
versa (I see this as a fair trade off, since I think that XBL will be 
one of the fundamental Web technologies, and it's reasonable for 
languages to have to take it into account)

The first couple disadvantages are big ones, though.

I'm honestly torn here.  XBL as it stands *is* usable with most SVG, 
including some declarative animations.  You've outlined a suggested 
approach to how SMIL/SVG might solve the problem, and it would likely be 
a very short spec, meaning it would be quick and relatively easy to 
implement.  But on the other hand, if it's such a short spec, maybe some 
solution could be worked into this current spec with only a little 
effort, offsetting those 2 disadvantages.

I guess my question would be, how likely is it that those disadvantages 
will occur?  And what is the conceptual timeframe for an XBL2.1?  I 
don't reckon anyone knows the answers to those questions, but I'd be 
interested in opinions.

Regards-
-Doug

Research and Standards Engineer
6th Sense Analytics
www.6thsenseanalytics.com
mobile: 919.824.5482

Received on Saturday, 13 January 2007 23:52:01 UTC