[web-anim] Re: regrets for Monday

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