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

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 18 Jan 2012 02:06:23 -0500
Message-ID: <4F166F6F.6020707@mit.edu>
To: James Robinson <jamesr@google.com>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, Sylvain Galineau <sylvaing@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
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.


> 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/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.

Received on Wednesday, 18 January 2012 07:06:53 UTC

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