Re: [CSS Transitions] Review comments on Editor's Draft Feb 10, 2009

Hej Erik!

On 27/02/2009, at 7:54 PM, Erik Dahlström wrote:

> == 5.2 "Properties from SVG" ==
>
> The list of properties here is incomplete, and incompatible with the  
> SVG CSS properties that are defined to be animatable. E.g audio- 
> level, line-increment, and a bunch of properties that aren't  
> naturally interpolable, e.g fill-rule.
>
> Why not simply refer to the SVG specifications for which such  
> properties are animatable?

Partially answered elsewhere, but the summary is that we only wanted  
properties that could be smoothly interpolated (unlike SMIL, we don't  
have step animation... yet).

But I will revisit this suggestion. I'd like to remain compatible if  
possible.

>
> == 2.1 The ‘transition-property’ Property ==
>
> What happens when there's a mismatch between the number of  
> 'transition-property' values and the number of 'transition-duration'  
> values?

Tab answered correctly, and it's been asked before - I just need to  
update the specification.

The lists repeat (as a whole, not just the last value). You don't use  
the values you have no need for.

> == 2.2 The ‘transition-duration’ Property ==
>
> The property uses <time> values, which is different from  
> <Clockvalue> used for specifying time in SVG[3] and SMIL. The  
> grammar of <time> is undefined, though a guess is that it's from CSS  
> 2.1 [2]. If that is the case, there are a few incompatibilies, e.g  
> the ability to specify time in minutes and hours, or a full  
> timevalue with semicolon separators.
>
> What's the rationale for not using the <Clockvalue> syntax?

Yes, <time> is defined in CSS already, so we didn't repeat it. There  
is no good reason either way here - <time> is easier to implement and  
it doesn't rule out large values.

>
> == 3 Transition Events ==
>
> Would one always get a 'transitionend' event, even if the duration  
> was 0?

No. A zero duration means there is no transition. That allows the  
default value of transition-property to be "all". Just set the  
transition-duration and things start to animate.

Without a transition there will be no event.

> How about if a duration was close to 0 and the implementation was  
> too busy to actually apply the transition, and there was another  
> transition on the same property starting at some minor timedelta  
> ahead? Would you still get the 'transitionend' event on the first one?

If a transition interrupts another transition, then the interrupted  
transition will not get an end event. The duration or efficiency of  
the implementation shouldn't matter.

> What's the rationale for not using (extending if need be) the  
> TimeEvent interface[4]?

You're right - they probably should extend the TimeEvent interface.  
Although, it's a remarkably bare interface, which doesn't have much to  
do with time, so I'm not sure what the benefit is. We'd obviously need  
new event names, and extra properties.

Is there a strong use case for being able to identify them as  
TimeEvents?

> == 4 Animation of property types ==
>
> What happens if you want to interpolate two values that have  
> different units? Is that something that can never happen?

You can certainly interpolate between "3em" and "50px", for example.  
The trick is, and this has been covered elsewhere, animating between  
percentages and values like "auto".

> Color interpolation in svg takes into account the 'color- 
> interpolation' property[5], why does transitions not use that as well?

It should, for SVG content at least. Having said that, the 'color- 
interpolation' property isn't that useful - it doesn't really give you  
much control over what the intermediate values should be, just a  
choice between two constant equations. More use would be the ability  
to interpolate in HSL, for example (which would allow brightness to  
remain the same but to rotate the hue). Even then, we played around  
with this for a bit and you still get unexpected intermediate values.

Turning the request around, I suggest the SVG WG look at enhancing the  
'color-interpolation' property to be more powerful.

> What's the rationale for wanting to interpolate HSL color values in  
> RGB space?

I said it above, but suppose you are animating between a color at 100%  
saturation and the same color at 0% saturation, or similarly for hue  
and brightness. Doing this in RGB gives a different result than HSL,  
and can sometimes give weird intermediate values. Actually, they can  
be weird in both RGB and HSL, but only the author can decide which  
they think is less weird.

Having said this, we (Apple) decided to stick with only RGB for now.  
I'd be interested if anyone thinks it is useful to allow HSL.

Dean

Received on Wednesday, 4 March 2009 01:24:59 UTC