Re: [css3-transitions] Transitions from display:none

On Tue, Apr 17, 2012 at 5:22 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 4/17/12 7:40 PM, James Robinson wrote:
>
>> Have you had a chance to think about this yet?
>>
>
> Somewhat.
>
> If I remember the context here, the proposal was effectively some sort of
> synchronization barrier after every single inline style set or something.
>  That doesn't seem very feasible to me, honestly, and I think I said so at
> the time....
>
>
I don't think my proposal is nearly that heavyweight.  Here it is again,
see http://lists.w3.org/Archives/Public/www-style/2012Jan/0816.html for the
fuller context:

Whenever the browser notices a change in the computed style of a property
that would result in an animation/transition, it queues a task. When the
task runs, it checks if a CSS box exists for that element and if the
computed value is something that triggers an animation/transition.  Then
and only then would the animation/transition actually start - all start
events fire, :animating/:transition pseudo-classes start matching, etc etc.
 If the element doesn't have a CSS box when the task runs, or if the
computed style has changed back such that the animation/transition would be
a no-op, then the animation/transition silently does not happen.

The advantage of doing this off a task is that the only work that needs to
happen if/when the browser flushes styles is queueing a task.  The behavior
is still somewhat racy in the sense that the author can race setTimeout()s
against the task and have the animation/transition start or not depending
on who wins the race, but I don't think that is any different from any
other setTimeout()-based wackiness.

Concretely with this proposal in Sylvain's example the transition would not
occur in either of the scenarios he mentions:

e.style.color = "blue";
e.style.display = "block";

e.style.display = "block";
e.style.color = "blue";

or in this slightly trickier one:

e.style.color = "blue";
document.body.offsetTop; // forces a style flush, at least in WebKit
e.style.display = "none";

This also means that the following would always return false:
<style>
#e:transitioning { background-color: green }
</style>
<script>
function checkForTransitionInSameScriptBlock() {
  e.style.color = "blue";
  return getComputedStyle(e).backgroundColor == "green"; // or rgb(0, 255,
0) or however it's supposed to serialize
}
</script>

If the style flush happens totally asynchronously with respect to script,
say at requestAnimationFrame time, the browser can go ahead and start the
animation/transition right then and there since there won't be any
script-observable difference in behavior between that and queuing a
separate task.

- James



> I agree that this causes issues with transitions.  I don't really know
> what we can do about that: the triggering mechanism for transitions is
> fundamentally broken for a lot of things people seem to want to do with
> them.  :(
>
> -Boris
>