- From: Doug Schepers <doug.schepers@vectoreal.com>
- Date: Mon, 15 Jan 2007 09:51:28 -0500
- To: Arthur Barstow <art.barstow@nokia.com>
- Cc: Ian Hickson <ian@hixie.ch>, Cameron McCormack <cam@mcc.id.au>, public-appformats@w3.org
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
Received on Monday, 15 January 2007 14:51:46 UTC