Re: [css-transitions] Formal definition of canceling and interrupting

On Tuesday 2014-12-09 16:04 -0800, L. David Baron wrote:
> Today I made some substantive edits to the transitions spec to fix
> the remaining substantive issue listed in the body of the spec, on
> defining canceling of transitions.
> 
> In particular, I rewrote much of the section on starting of
> transitions at http://dev.w3.org/csswg/css-transitions/#starting to
> define when transitions are canceled mid-run.  This required
> introducing a new concept (the after-transition style) and making
> the after-change style depend on the after-transition style from the
> parent.  I believe this concept is needed to properly cancel
> transitions running simultaneously on both ancestors and
> descendants.  However, it means that transition starting is (again,
> I think) required to be interleaved with the process of doing style
> change computation over a tree, since the starting of transitions on
> a child depends on a style from the parent that in turn depends on
> which transitions on the parent were canceled.

So while trying to implement the after-transition style concept, I
realized that it doesn't solve the problem that it was attempting to
solve (which was actually only in my head; the problem didn't
exist), while making other things worse.  So I removed it.  This
makes the spec rather more like it was prior to those December edits
(though still better defined than it was before).

(The problem I was trying to solve was making sure that if a
transition is running on both an ancestor and its descendant, that a
change to the current state of the transition (often the initial
state, if there's a transition-delay) would cancel the transition on
the ancestor without canceling the transition on the descendant.)

However, I kept the change (made at the same time) that the
after-change style excludes all styles from CSS Transitions.  This
is needed for canceling of transitions (even in simple cases).


That said, there is one real problem I've found with the current
wording, as a result of trying to implement it.  This is shown in
the testcase:
  http://dbaron.org/css/test/2015/transition-starting-1
This testcase has a 4s text-indent transition on an ancestor and a
1s text-indent transition on a descendant, both triggered by the
:hover state on the ancestor.  It also has a timer that makes
unrelated style changes to the body every second.

The problem here is that with the wording in the current spec, at
some time between 1s and 4s (after the child transition has finished
but the parent transition has not), the unrelated style changes
trigger a *new* 1s transition on the child, from the current
in-progress value on the parent to the final value.

I'm inclined to fix this by saying that implementations must
remember the most recent transition destination for each
element-property pair that has had a transition, for as long as the
property value remains at that destination and the property remains
in 'transition-property', and must not start a second transition to
the remembered value.

I believe this restores the invariant that transitions aren't
triggered by unrelated style changes.

I realize it might be a bit of an additional cost in memory use, at
least in a naive implementation.  But I think that:
 (a) it's probably worth the cost to maintain that invariant (even
     though it is a bit of an edge case), and
 (b) assuming that this sort of case is the only thing it changes
     (which I hope it is), much of the storage could be optimized
     away in a better implementation.

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