regrets for Monday

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.

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.

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.

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);

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.

Dean



[*] I was trying to think of examples of big APIs introduced to the Web platform:

- WebGL: it's an extremely large API, but a port of an existing API that's been in development for 20 years.

- Web Audio: mostly the product of one person, maybe too early to call it a success.

- <video>/HTMLMediaElement: this is definitely a success, so might be the exception I'm looking for.

Received on Sunday, 10 February 2013 12:37:34 UTC