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 16:40:59 -0700
Message-ID: <CAD73md+mcV0dKWLpmCzuSn4sXFO-7vbQ=TAVGDRNXy3biPYrhg@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, Jan 17, 2012 at 11:06 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 1/18/12 1:14 AM, James Robinson wrote:
>
>> This is problematic if the page is in a background tab, since that turns
>> off the requestAnimationFrame mechanism.
>>
>
> Why is that a problem?  Do transitions actually start immediately in
> WebKit in background tabs?  In Gecko they start whenever the style is
> recomputed, which happens on either flushes or precisely when the
> requestAnimationFrame timer would fire, fwiw.
>
>
>  it sounds like he's proposing each script assignment to Element.style be
>> treated atomically and changes resolved against each of those.  That
>> would be very difficult to implement in WebKit and I believe in gecko as
>> well because we treat larger blocks as atomic.  Roughly speaking WebKit
>> treats all changes between style flushes within a given document as
>> atomic.
>>
>
> Yep.
>
>
>  There's not total consistency here either - WebKit flushes
>> styles on documents independently of each other, but it seems Gecko
>> flushes across documents in some cases - compare:
>> http://webstuff.nfshost.com/**tests/outer.html<http://webstuff.nfshost.com/tests/outer.html>
>> http://webstuff.nfshost.com/**tests/outer2.html<http://webstuff.nfshost.com/tests/outer2.html>
>>
>
> Yeah, the Gecko behavior here is sort of required if you really want to
> get meaningful answers out of APIs that return layout data (or even style
> data: the styles in a subframe depend on media queries, which depend on the
> size of the CSS viewport, which depends on the layout of the parent
> document).  What WebKit is doing is sort of racy.  But maybe web pages
> aren't depending on this in practice.
>
> But the larger point that the flushing mechanism is not identical is
> absolutely true.  I expect there are other differences as well.
>
> Need to think a bit about the proposal.


Have you had a chance to think about this yet?  This is still a serious
problem with animations and transitions that authors are hitting.

- James

>
>
> -Boris
>
Received on Tuesday, 17 April 2012 23:41:39 GMT

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