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 20:10:49 -0700
Message-ID: <CAD73mdKxWYMrCJEp27Wnm7OStUZVujn-7ZOmu7YQD4HDNOsM8g@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 7:31 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 4/17/12 10:23 PM, James Robinson wrote:
>
>> More specifically when queueing the task the browser has to store the
>> "before" computed value of the animatable/transitionable property and
>> then keep that around until the task runs.
>>
>
> Yeah, ok.
>
>
>         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";
>>
>>
>>    Why would there be no transition in this case?
>>
>>
>> As a reminder, the initial state here is:
>> E { display:none; color:red; transition: color 0.25s; }
>>
>> and I'm assuming that after each statement the browser may or may not
>> resolve styles.  Regardless of when that happens, at some point the
>> browser queues a task.  When the task runs it evaluates that the
>> computed value for "color" is "blue" and was previously not specified,
>> since there was no CSS box.
>>
>
> That's certainly not the case universally in UAs.  As a trivial example,
> no CSS box might still mean there was a known computed _display_ style
> ("none", to be precise).  Depending on the UA, other styles might have been
> computed too.
>
> We could get this behavior if we _required_ that the "before" value be
> stored as "not computed" if there is no CSS box, but it's not obvious a
> priori that this would be the behavior.
>

Yes, I'm assuming that a UA can tell if an element is inside a display:none
subtree or not and that this has some predictable impact on the computed
style.  Looking around at existing specs it seems that perhaps this is a
novel part of the proposal (although it seems pretty fundamental to me).


> But even that wouldn't guarantee the behavior you want in this case: the
> UA might flush out recomputation of display, discover that a box is needed
> and create one before it ever computes a color for that box. Gecko doesn't
> do this right now, but nothing currently prevents it.


That's perfectly fine.  The only requirement is that whenever the UA does
update the computed value of the "color" property it record the "before"
value at that time and it be able to distinguish a "before" value of
"inside a display:none subtree".

There's also the question if when exactly the transition or animation
property "takes effect".  In other words, what happens when you do:

e.style.color="blue";
e.style.transition="color 0.25s";

vs

e.style.transition="color 0.25s";
e.style.color="blue";

vs the more indirect mechanisms of changing DOM structure / class names /
etc to cause selectors to match having the same effect.

- James


>
>  A similar argument applies for an initial state of display:block; color:
>> blue and the JS
>>
>> e.style.color = "red";
>> e.style.display = "none";
>>
>> when the task runs the element has no CSS box, so no transition.
>>
>
> Again, that's not obvious to me; I think you're assuming details of style
> system implementation here....
>
> -Boris
>
Received on Wednesday, 18 April 2012 03:11:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:52 GMT