On Apr 3, 2010, at 1:06 AM, HÃ¥kon Wium Lie wrote:
> ...Finally, I'd like to show what the proposal looks like with the
> property name changed from 'effect' to 'animation':
>
> [example 11]
>
> .blue-box:hover {
> left: 700px;
> animation: on-entry left 1s, on-exit left 1s,
> on-entry play(bounce) 1s, on-exit play(bounce) 1s;
> }
>
> [example 12]
>
> .blue-box:hover {
> left: 700px;
> animation: left 1s, on-exit left, play(bounce), on-exit play(bounce);
> }
>
> [example 13]
>
> .blue-box:hover {
> left: 700px;
> animation-on-entry: left 1s, play(bounce) 1s;
> animation-on-exit: left 1s, play(bounce) 1s;
> }
>
> Also, the 'keyframe' name may be changed. Perhaps to:
>
> [example 14]
>
> @animation bounce {
> from { top: 0; }
> 33% { top: -20px; }
> 66% { top: 20px; }
> to { top: 0; }
> }
>
> In sum, I think this unified model is worth considering. But I may
> have missed something. Naturally, comments are welcome.
You're trying to come up with a single syntax that encompasses the functionality of transitions and animations. But in doing so you are introducing a confusing mix of specifying property values in two places: in the style rule, and in the @animation rule. You're also introducing a functional notation simply to solve a problem caused by putting to much information in the shorthand property. I know you're trying to simplify things in doing all this, but I think it only makes things more confusing and complicated. It also points out another advantage of separating transitions and animations. Sure, there are shared concepts between transitions and animations, and where there are we chose similarly named properties (e.g., transition-duration, animation duration) to make it easier on authors. But trying to combine the concepts entirely just results in a more confusing syntax that is harder on both implementors and authors.
-----
~Chris
cmarrin@apple.com