Hi-
Arthur Barstow wrote:
On Jan 13, 2007, at 6:51 PM, ext Doug Schepers wrote:
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
Even if the extensions were included in the XBL2 spec there is no
guarantee they would be [completely] implemented.
The chances are higher that they would, at least for those UAs that
support SVG (and I think that most UAs that will be implementing XBL2
will also support SVG to some degree).
* dramatically increases the "time to market" for that particular
technology's use of XBL
I don't understand this; surely those interested in the extension could
closely track the XBL2 spec's progression.
Sorry, I wasn't clear. I was referring to real-world use of XBL+SVG,
not status of the document.
To elaborate, if the XBL2 spec goes to Rec status without this animation
consideration, implementations will first do the core spec. Even if
these "extensions" were published in their own spec very soon after,
odds are that it would take a UA some time to get around to implementing
them, as they would be focusing on optimizing the core spec. Also, I'd
outlined a scenario where XBL2 "core" is published and implemented, and
where its limits and peccadilloes are more fully explored before
publishing the "extension" spec... that'd be great for making sure edge
cases are covered, but it would also mean that it would likely be a year
or two before authors would be able to use it, optimistically assuming
that implementation momentum follows through on these "extensions".
Another downside I didn't mention before is that some UAs might be
reluctant to implement these "extensions" because they've already
optimized their XBL2 architecture to work without them and would be
afraid of a performance hit. To illustrate, when implementing SVG you
really have to plan in declarative animation from the beginning... it's
difficult to bolt on later and not get stung. I'm afraid that any XBL2
"extension" would face considerable reluctance, which it would not do if
part of the core spec.
Ideally, if there is a simple, generic way to handle this use case that
could cover similar cases down the line, it should be designed into XBL2
from the beginning, and other specs could then describe how to use this
core functionality with respect to their particular processing model,
without having to introduce new features into XBL2.
I agree with Ian that special-casing XBL2 for particular languages is
not a good idea. And I don't necessarily think that the particular
mechanism the SVG WG suggested is the only way to go. Maybe there could
simply be a way in XBL2 to indicate in the template what the binding
hierarchy or targeting is handled, and SVG/SMIL could say which elements
follow which behavior?
Regards-
-Doug
Research and Standards Engineer
6th Sense Analytics
www.6thsenseanalytics.com
mobile: 919.824.5482
