W3C home > Mailing lists > Public > www-style@w3.org > February 2009

Re: Comments on CSS Transitions

From: David Hyatt <hyatt@apple.com>
Date: Fri, 27 Feb 2009 13:28:48 -0600
Cc: Giovanni Campagna <scampa.giovanni@gmail.com>, www-style@w3.org, www-svg@w3.org
Message-id: <18C1FB93-A33D-4AA6-A077-FAAC15138E0A@apple.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
On Feb 27, 2009, at 12:24 PM, Tab Atkins Jr. wrote:

> See, I'm not liking that either.  I want transitions to fire *only*
> when an actual rule change occurs.  Any incidental changes, such as
> from the user resizing the window, are completely out of my control.

I'd be fine with this additional restriction, i.e., you transition on  
computed values but require a rule change to have occurred.  That  
could be tricky to specify though.  Aside from viewport units, I'm  
hard-pressed to think of any case where the computed value changes  
without a rule change occurring.  I suppose the new grid unit would be  
like that also if it ever comes into existence.

> The user probably doesn't want such changes to animate, either - when
> I resize a window, I expect everything to resize in sync.

I agree.

> In my mental model of transitions, animations only get triggered when
> the specified value changes, but *operate on* the used values.  This
> means that transitioning from a percentage to a px value is completely
> possible.  Is there anything fundamentally wrong with this?

The implementation issue we ran into is that used values can require  
significant time to determine... to use browser terminology you  
basically have to "lay out" your page before you really have an  
accurate idea of what your used values are.

This problem gets compounded by the fact that other transitions could  
already be running that affect your used value.

For example changing width from non-auto to auto could have a pretty  
dramatic impact on your page (and affect the used values of  
descendants that could also be running transitions, etc.)

>  I think
> it's how us authors are generally going to think of it - it's
> difficult to consider the inability to animate from 50% to 100px as
> being anything other than a bug.

I think transitioning on used values also creates situations that a  
user would perceive as bugs as well.

For example let's say I have a transition to go from width:50% to  
width:100%.  At the time the transition starts I determine for a 600px  
window that the beginning width is 300px and the ending width is  
600px.  The transition starts, but now the user resizes the window so  
that it is 800 pixels.  What happens?  If you use the computed value,  
the transition will adapt and do what the author intended... the  
object will finish by filling the width of the viewport.

If you transition on used values, then you either are using a snapshot  
model of the used value taken at the time the transition started, in  
which case you finish at 600px instead of 800px, or you expect all  
transitions to have to dynamically recompute what's going on every  
time any used value in your page changes... this gets insane really  
fast if you think about it.

Put another way, computed values allow transitions to be purely based  
off style information.  Used values force transitions to be dependent  
on layout geometry information.  The former is computable easily by  
just looking at style rules.  The latter involves knowing where  
everything is placed.  Even just computing an ending snapshot value  
could take a large amount of time.

Even though I agree that the width case seems like a bug in the  
computed values case, I think the alternative is just too complex to  

Received on Friday, 27 February 2009 19:30:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:24 UTC