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:47:38 -0800
Message-ID: <CAAWBYDDRGRK=by4fHjNXi+0mhWCwN3_=qw7MAdOz_icUt-cfQA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
On Fri, Jan 13, 2012 at 11:41 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 1/13/12 2:34 PM, Tab Atkins Jr. wrote:
>> Actually, I'd expect both of those to act the same, since the style
>> wasn't flushed between the two declarations.
> Aaaand here we go.  ;)
> The fact that style computation is lazy and might need flushing is an
> implementation detail.  It's neither required nor forbidden by the spec at
> the moment, and until the introduction of transitions wasn't observable.
> But transitions punch a big hole through and make it all observable, of
> course...  In particular it makes it possible to tell apart eager and lazy
> computation, to tell when lazy computation does or does not take place, etc.

It was observable before, by timing.  It's just *more* observable when
transitions are used, to the point where we do indeed need to define

>> 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'm not sure I follow.  Why would it need that?

Sorry, misspoke.  It'd have to do two computed-value runs, not layouts.

>> WebKit and Firefox should both align with this "you haven't flushed
>> the styles yet" behavior
> Why would they?  There's no spec for it, and at least in Gecko there are
> various things that may involve style flushes which may not be obvious to a
> casual observer.  For example, getting or setting the .value of an
> HTMLInputElement involved flushing styles for a while.  I don't know whether
> it still does or not.
> I fully expect that it's trivial to write testcases in which some operation
> has the side effect of flushing styles in WebKit but not Gecko, and vice
> versa.

Sorry, that "should" was about what I thought they did, not what I
thought they *should* do.

Yes, our flushing behavior probably differs somewhat from yours.  I
expect we're fairly close, though - close enough that defining it and
aligning wouldn't be a huge deal.  Deciding whether an operation
should or shouldn't flush styles is fairly easy, after all.  (Getting
or setting .value on an <input> shouldn't flush, for example.  ^_^)

Received on Friday, 13 January 2012 19:48:33 UTC

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