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
