- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 18 Jan 2012 02:06:23 -0500
- 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. 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/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. -Boris
Received on Wednesday, 18 January 2012 07:06:53 UTC