W3C home > Mailing lists > Public > www-style@w3.org > April 2012

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

From: James Robinson <jamesr@google.com>
Date: Tue, 17 Apr 2012 18:32:28 -0700
Message-ID: <CAD73mdK0K1sXZ3+8nuaX328xGd6urEmRjayawVmeNJa-QXLvcw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Sylvain Galineau <sylvaing@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
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:
#e:transitioning { background-color: green }
function checkForTransitionInSameScriptBlock() {
  e.style.color = "blue";
  return getComputedStyle(e).backgroundColor == "green"; // or rgb(0, 255,
0) or however it's supposed to serialize

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
Received on Wednesday, 18 April 2012 01:32:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:14 UTC