- From: David Hyatt <hyatt@apple.com>
- Date: Fri, 27 Feb 2009 13:28:48 -0600
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Giovanni Campagna <scampa.giovanni@gmail.com>, www-style@w3.org, www-svg@w3.org
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 implement. dave (hyatt@apple.com)
Received on Friday, 27 February 2009 19:29:31 UTC