- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Tue, 12 Feb 2013 09:46:42 +1100
- To: Dean Jackson <dino@apple.com>
- CC: Shane Stephens <shans@google.com>, "public-fx@w3.org" <public-fx@w3.org>
Hi Dean, (2013/02/10 23:37), Dean Jackson wrote: > Brian, Shane, > > Sorry for the exceptionally late notice, but I cannot attend on Monday. I *might* be available at some times by phone, but I can't be sure. Ok, thanks for letting us know. If there's something you particularly want to call in for, let us know. I'll send out the minutes of what we discussed yesterday in a moment so you can have an idea of what's on the agenda for the week. > My recollection of what we vaguely decided on Thursday was: > > - Split the model description into its own document for now. [This may not have to be a permanent situation, but I think it is good to separate something we can all agree on] > > - Continue work on the JS API alongside the "compatibility" specs. That was my recollection too, but before committing to any particular course we revisited this issue today and recognised a number of advantages and disadvantages with it. On the positive side splitting the specification would provide a clear boundary for user agents that do not support scripting. Also, it would allow the model specification to progress more quickly without being gated on API details being resolved. However, a number of us are concerned about the specifications growing out of sync. In particular, adding new features would often require editing both specifications which could become even more complicated down the recommendation track. In summary, if feels like they should be together. Currently we are considering other options such as putting the API later in the specification or having separate chapters in separate files but in one specification. We would be particularly interested to hear from other members of the CSS WG and SVG WG on their thoughts on this matter. > Meanwhile, I've set aside some time the week of Feb 17 for a my colleagues and I to write up a proposal of what I was suggesting. I think it would be easy enough to make it compatible with the existing work you've done. That would be great. Thanks Dean. You may be interested to know that we discussed some of the timesheet-like use cases today with Silvia. We are already expecting to add the following to SVG: <par> <seq> <animate select="p.myClass"> <mediaRef href="videoElem"> As such, I think many of the timesheet use cases could already be realised with the current feature set. If SVG animations are allowed to target HTML content (this already works to some extent in Gecko) then this could also be applied to HTML pages by simply wrapping the elements in <svg>. Allowing <link rel="stylesheet" src="timesheet.svg"> would also be possible but I know Silvia had some reservations about this approach. > It would be fantastic if, on the API level, we could split out timing (TimedItem and below) from animation (most other stuff). As I said on Thursday, I worry that any API of this size faces a huge battle for adoption, no matter how useful or excellent it is [*], so I think it's important to set aside anything that is not essential (as long as it could be added in backwards compatible way later). > > As an example of separating Timing from Animation, I'm wondering why Document and Element expose only this API: > > sequence<Animation> getCurrentAnimations (); > > In my model, an Animation is just one example of a TimedItem. The ability to simply apply timing to Elements is extremely powerful if we expose CSS selectors and DOM events for these situations. For example, I should be able to say that a particular Element is "active" (need a name that doesn't conflict with the existing use) for a given time range. Then I could do: > > #myelement::active(foo) { > color: red; > } > > Or: > > document.getElementById("myelement").addEventListener("active", function (event) { > if (event.timingName == "foo") { > event.target.style.color = "red"; > } > }, false); We think you could already achieve this using the following approach: <set select="p" attributeName="class" to="active" additive="sum"> This obviously requires defining animation of the classList such that it can be additive. However, that is something we already intend to do. The advantage of this approach is that no changes are required to CSS. If it is important to add #myelement::active() for other reasons, we think this can already be built on top of the current model by defining animations with a null animation effect. > Obviously that's just off-the-cuff code, but you get the idea that I've associated timing without any mention of animations. And I could still link animations to this model by writing them in CSS. > > One place where we do need an API as soon as possible is being able to test the current state of Animations and Transitions. But I think if that was just TimedItem, with the ability to write to currentTime, then it's a great start. I'm a little concerned that doing that would pull in most of the rest of the API. That said, we will certainly go through the API and see what we can possibly drop from the API in the first version. Thanks again Dean, Best regards, Brian
Received on Monday, 11 February 2013 22:47:14 UTC