On Fri, Mar 18, 2011 at 9:28 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 3/18/11 12:13 PM, Tab Atkins Jr. wrote:
>> The biggest problem with SMIL is that it's not CSS. ^_^ It's a
>> different animation model that's only applicable to SVG (plus maybe
>> other languages that aren't really part of the web). It won't ever be
>> applicable to HTML. CSS Transitions/Animations are already usable
>> across HTML, and on the handful of SVG attributes that are currently
>> mapped to properties (the list of which is pretty arbitrary). It
>> appears that CSS T/A is the most reasonable way forward if we want a
>> single animation model for the web (which seems like a desirable
>> goal).
>
> It's a desirable goal if the resulting model is sane. If you have to come up
> with a franken-model of some sort to do it, because you're animating totally
> different things conceptually but trying to shoehorn them into the same
> model, then it may not be a desirable goal.
Agreed. Do you see anything in particular that's a problem, though?
The current goal is just to make a bunch of SVG attributes into
animatable properties.
Higher-level SMIL abilities might be introducable into CSS's model,
but I'm wary to try and make this too declarative. Complex animation
manipulation should be done in javascript, imo.
(The one thing I really want in the declarative model that doesn't
have an obvious path toward it is the ability to animate something's
position directly, so that, for example, if the window size changes
and causes things to lay out differently, you can declare that the
elements should animate to their new positions. This is
*substantially* different from the current Transitions model, as it
operates on a higher-level "layout position" concept rather than
property values, but it's pretty valuable, as evidence by how many
javascript libraries and complex webapps do it.)
>> Basically, it would suck if authors have to learn two vaguely similar
>> animation models just so they can use SVG and HTML together.
>
> It would also suck if they have to learn two vaguely similar animation
> models just to use transitions...
Agreed, but that's not actually a problem so far. There's a really
simple model underlying T/A that's obscured by the way the specs are
split. I'll get into this shortly in another thread.
>> It would also suck if the two animation models had different capabilities.
>
> Why?
Well, I should say "greatly different capabilities". If each
animation model has substantial distinct strengths, then I still have
to learn both of them.
>> While we won't ever get rid of SMIL, given the weight of SVG 1.1
>> content on the web, we can at least make it unimportant for new
>> authors to learn.
>
> Is the cost in terms of resulting complexity in CSS Transitions/Animations
> worth it?
My personal explorations of the subject make me believe the added
complexity to make T/A sufficiently powerful is actually rather small.
~TJ