W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: [css-display]? Compositing, expensive things, and laziness

From: François REMY <francois.remy.dev@outlook.com>
Date: Fri, 21 Jun 2013 23:55:13 +0200
Message-ID: <DUB120-DS41934F88991BA5E0CC4A3A58F0@phx.gbl>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "Ali Juma" <ajuma@chromium.org>, "Robert O'Callahan" <robert@ocallahan.org>, "www-style list" <www-style@w3.org>
> Okay, so you're just proposing a different name for the current
> proposed "optionalElementRendered" event, more or less.

Approximately, yes. Except that "requestAnimationFrame" already has an issue 
[1] to support element-rendering-tied calls in the spec, so why not just 
ping the editors and say we have an use case for this ;-) As I said, the 
advantage is that we can optimize more than just this very specific scenario 
of hide/unhide element but also more general non-rendering optimizations 
(plus, it works for free in all modern browsers). I think we should at least 
ping the editors to see what they think about it, and what their current 
plans are; after all, this falls under their charter (web performance).



> This lacks the "optionalElementNonRendered" case, and has the "fails
> in older browsers" behavior that roc wants to avoid.

Yes, you've no way to know an element becomes non-rendered (except that it 
would not handle the rAF queue). That's the negative point I stated.

However, it does not fail in old browsers because "requestAnimationFrame" 
already works in those browsers, and it will just ignore the HTMLElement 
target (which will be okay, since the browser will also not support lazy 
rendering of any element so the next global AF will be the one that would 
end up being used in the case the HTMLElement target was supported). This 
contrats with an event because you can perfectly register a non-supported 
event and you don't get any error, so you may actually wait for an event 
that will never fire.



________________
[1] http://www.w3.org/2010/webperf/track/issues/4 
Received on Friday, 21 June 2013 21:55:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC