« Zakim, Trackbot and Rrsagent
- Colin Powell »
By glazou on Monday 20 October 2008, 15:58 - CSS and style
Les solutions actuelles en JS sont effectivement suffisantes pour créer aisément ce genre d'animations (et bien plus naturellement), mais pouvoir les réaliser en CSS apporte un confort indéniable (sans compter la réduction de poids!).
But yes, yes I would like to see it as part of CSS. In fact I originally proposed it :).
Oh, sorry, it is about animations, not transitions! In that case, meh, I do not care for it much. Might as well use SMIL. Can I still change my vote?
I'd like to see this feature, but I don't know which solution is the best. No option for this answer in the poll.
You can only use SVG / SMIL to animate markup, not CSS. And vice versa for CSS animations.
Therefore the two solutions are not really competing, they do different things, and you need both.
Oui. Indispensable si on veut en finir avec Flash et autres clones propriétaires comme Air et Silverlight. Ce sont de petites “briques” simples qui permettront de construire beaucoup…
Looks like <blink> on steroids :p
You can use SMIL to animate CSS.
We already incorporated some bits stolen from "transforms" and the "transitions" subset into zml.
I'm not a big fan of the coumpound syntax, but the ideas are good, this is clearly useful, and seems to me in line with the spirit of css.
On the other hand, the whole "CSSAnimations" shebang doesn't look right to me:
1. "selectors", IMHO a key css concept, is badly twisted. That "looks" like CSS, right, but also looks like shoehorning something that doesn't fit into a grammar not meant for that. I'm aware at-rules are not style rules, but still, that hurts the eyes
2. Keyframes declarations as a whole are overkill: can't a more compact, possibly functional notation be used instead?
3. Transitions are ok. They express the way an object morphes when changing from a specific style state to another - fair.
Animations on the other hand completely override computed style from which they are entirely disconnected (meaning they will prove hard to use, or be purely gratuitous cycling bling bling).
4. doesn't look sane to implement (am I a sissy on this?): quote "In the case of multiple animations specifying behavior for the same property, the animation defined last will override the previously defined animations. " <- so, selector specificity is not the way to go for these, or is this bad phrasing assuming the case discussed is "with same specificity"? Headache ahead.
All in all: I'm probably too conservative with CSS "spirit" (I can live with that ;)), but I think the syntax is globally bad, and the idea not so much a good one, for a somewhat questionable result: if we are still talking about styling *documents*, then transitions *are good* (describing a path between two different style states, likely following user interaction), while animations looks to me like, yeah (useless) "<blink> on steroids".
I hope this was constructive - despite not being supportive.
Bahh, that's just me... bitching first, then just implement it next time I feel bored and got used to it
I'm not sure there is an "ideal" way of defining animations. So at the moment, I think that CSS based proposal is the best we've got (and possibly the best we're going to see for quite awhile). But either way, animation should stay separate from the semantic markup. And the best way of doing that, while keeping things nice and organized, is to put it in CSS.
There's something about this that makes me feel uneasy. I think it's because it looks like a new data format. First XML, then JSON, now CSSON?
The solution is tempting but conceptually the CSS Transitions and Animations are an ugly hack. They need a procedural more than a declarative language and forcing them into CSS makes the cascade a hindrance more than a property. Nothing is said about the synchronization between animations nor about the interactions with incremental reflow (should the browser restart the animations each time?) or cascade and scripts (which one takes precedence in calculating the computed values?). It also has the potential to mark the beginning of CSS as a kitchen sink of disparate protocols hidden under custom @rules and to delay the development of a better and proper solution for the animation of objects. Smells like a CSS <blink> tag to me.
I think CSS transitions makes a lot of sense and is something we'll want to implement in Gecko. I'm much less sure about CSS animations.
I want correct table support before : http://dascritch.net/blog.php/post/...
RoC: Well, that’s often a slightly confusing argument about SMIL; yes, SMIL can animate CSS properties. CSS transitions however allow you to specify styles in CSS in a declarative manner, as you would usually do, and indicate that the browser should move between them when they change. To my knowledge SMIL can not do that. CSS animations are a different beast though, and SMIL seems just fine for those.
Co-chairman of the W3C CSS Working Group, entrepreneur, software engineer, geek, father of two, polyglot, unashamed French, duck lover. Nah.
Powered by Dotclear