Re: Comments on CSS Transitions

On Fri, Feb 27, 2009 at 1:28 PM, David Hyatt <hyatt@apple.com> wrote:
> On Feb 27, 2009, at 12:24 PM, Tab Atkins Jr. wrote:
>> 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 is true.  How much of this impact is already felt by
transitioning on percentages, though?  Presumably they have to
actually work on used values, correct?

> 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.)

It seems that both of these are problems we are already facing,
though.  Transitioning on percentages makes things sensitive to
ancestors animating their values, correct?  I may be completely wrong
on this - if so, I would love a correction.

>>  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.

I'm confused by this.  If we make transitions work on computed values,
they still need to perform used-value calculations to actually
display.  Wouldn't this be the same amount of work?  The only way I
can rationalize this is if you mean that working in computed values
and converting down to used values when trying to display is easy, but
working solely in used values and trying to keep track of the effects
of other used values changing is hard.  Is this roughly correct, or
did you mean something else?

> 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 implement.

If absolutely necessary, I consider it a worthwhile tradeoff to have
the ability to transition between px and % (and the multitude of other
units we may move between), but occasionally run into an issue where a
transition running while the user resizes their window doesn't quite
complete 'normally', and then snaps into correctness at the end.
However, I'm skeptical of the necessity of this given a rational spec.

~TJ

Received on Saturday, 28 February 2009 20:48:19 UTC