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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 13 Jan 2012 11:34:03 -0800
Message-ID: <CAAWBYDAXHnS5NWRk08jsYEQ+-PYqVYHBCVUGgtY=YOvE29=Nfw@mail.gmail.com>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "www-style@w3.org" <www-style@w3.org>
On Fri, Jan 13, 2012 at 11:15 AM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
> [Boris Zbarsky:]
>> On 12/14/11 1:49 PM, Tab Atkins Jr. wrote:
>> > Yup, which is a good reason why Transitions should act like Animations
>> > and not start if the start-state was display:none.
>> My point is that the not-computing behavior may not be limited to
>> display:none.
>> Again, nothing in the spec currently says when styles are actually
>> computed.  Transition starts depend on changes to computed style, so
>> transitions can only start if the style changes after the first time
>> it's computed.
>> If we seriously wanted to define this somehow, we would need to define
>> _exactly_ when styles are computed.  Doing this and getting UA vendors
>> to agree to the definition could be exciting.
> This definitely seems challenging. Given something like:
> E { display:none; color:red; transition: color 0.25s; }
> ...then script such as:
> e.style.color = "blue";
> e.style.display = "block";
> The expectation is that no transition occurs because the element was
> display:none when the color property was updated.
> But if we now did:
> e.style.display = "block";
> e.style.color = "blue";
> ..then the expectation is that A transition should occur as the color update occurs after
> the element is told to generate visible boxes again. Which puts pretty stringent requirement
> on browsers with respect to when styles are computed. Today only Opera and IE10 seem to align
> with this expectation though I haven't done anywhere enough testing to establish that can be
> relied on.

Actually, I'd expect both of those to act the same, since the style
wasn't flushed between the two declarations.  Either the engine notes
that the start state was 'display:none' and prevents the color
transition, or it recognizes that the style diff it's applying changes
the 'display' to 'block', and so it allows a transition to happen.

I'd prefer the latter behavior, though I recognize that it is more
complex, as it would probably require doing a double layout (once with
the display changed, then once with the rest of the properties
applied).  I suppose the UA could be smart by noticing whether any of
the properties in the style diff are subject to a transition, and act
normally (with a single layout) if not.

WebKit and Firefox should both align with this "you haven't flushed
the styles yet" behavior, though I don't know how they interpret
things when they apply the diff.  I know that Opera is unpredictable,
as it will interrupt the script at arbitrary points to do a style
flush and layout (which, I believe, violates run-to-completion
semantics). I don't know how IE10 works.

Received on Friday, 13 January 2012 19:34:58 UTC

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