- From: François REMY <francois.remy.dev@outlook.com>
- Date: Fri, 21 Jun 2013 23:55:13 +0200
- 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