Re: [css-transitions]: Lacking satisfying specification interrupted transitions

On Tuesday 2015-03-17 15:09 +0100, Axel Dahmen wrote:
> I've been trying to implement smooth scrolling by means of CSS3 transitions.
> 
> Doing so I noticed that the current specification lacks specifying a
> satisfying path on how interrupted transitions should be implemented to
> provide a smooth segue from transition to transition.
> 
> In the development edition of the specification a suggestion has been
> introduced to cope with this situation. However, the solution presented
> therein doesn't seem comprehensive nor satisfying.

Rather than trying to define a single correct behavior that works
for everybody's needs, I think we should have some reasonable
default in the spec that works for the most common cases (e.g.,
simple transitions between a :hover and non-:hover style), but then
have a mechanism for authors who want to do particular other things
to override that.  I think that override mechanism probably needs to
involve script, and I'd hope that the work going on on Web
Animations and in the houdini task force will be able to provide
that.

What matters is having UI that works the way people want it to.
Things that look nice mathematically don't necessarily produce good
results; I definitely found that while experimenting with the
transition reversing behavior for Gecko.  And that, in turn,
requires that people experiment with the behavior.

> I'd like to suggest a different approach to interrupted transitions.
> 
> Given transition #1 will change property value (a) to property value (b) and
> the adjoining transition will change the currently transitioned value (c) to
> (d), my approach will apply to any kind of interrupted transitions:
> 
>   *  Reversed Transitions
>       { (d) between (c) and (a) or (d) beyond (a) }
> 
>   *  Continued Transitions
>       { (d) near or beyond (b) }
> 
>   *  Interrupted Transitions
>       { (d) near (c) }

I think one of the big obstacles to this is that it requires a
distance metric for all animatable value types.  For example, how
far apart are 'yellow' and 'green', and how does that distance
compare to the distance between 'yellow' and 'blue'?  (It's actually
not that hard for colors, but it's harder for transforms.)

Gecko's initial approach to implementing shortened transition
reversing did solve it for cases more general than just reversing,
using a distance metric of this form.  But it ended up doing
somewhat silly things for a number of the value types, and when I
brought the issue up, other implementors weren't interested in
implementing (and specifying) a distance metric for all animatable
value types.  I think they were probably right in rejecting it, as I
explain above.

> A documentation to my suggestion can be found here:
> 
>      https://youtu.be/ssiQYof5YLQ

Videos are actually rather hard to comment on; it's hard to reread
sections, hard to skim one part and read another part carefully,
etc.

That said, doing this seems quite complicated, which means it's
going to take a long time to get it all right, specified, and
interoperably implemented.  We'd be better off making tools that
give authors the ability to iterate quickly on varying animation
behaviors than trying to put something perfect in the spec.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)