- From: François REMY <francois.remy.dev@outlook.com>
- Date: Fri, 30 Nov 2012 17:47:55 +0100
- To: "Tobie Langel" <tobie@fb.com>, "Dean Jackson" <dino@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "Simon Fraser" <smfr@me.com>, "Rik Cabanier" <cabanier@gmail.com>, "www-style list" <www-style@w3.org>
| From: Tobie Langel | Currently, the lack of events on which to prefetch and append new content | while scrolling makes it impossible to implement infinite scrolling | without re-implementing everything in JavaScript. Other UI refinements | (pull to refresh, etc.) suffer from similar issues. Re-implementing | scrolling in JavaScript prevents the browsers from carrying adequate perf | optimization, yields sub-optimal experiences for the users and is | extremely costly in engineering resources. Unfortunately, this proposal is not aimed at all at solving the 'normal' scrolling performance, but rather at solving a popular hack around scrolling where you want to run 'scrolling animations' (for example a cartoon bullet enters the page from the left as you scroll further). Implementing this specification will do nothing to improve general scrolling performance (however, I don't understand either why people think it could degrade the normal case performance, this is simply not true: in the worst case the scrolling performance will stay the same (the feature will be disabled and will not trigger any slow down) and in the best it will become way better (it's enabled and replace traditionnal scroll behavior with a slower one, but which is way faster than using some JavaScript code). Tab Atkins and I (and probably other people at Google) already discussed solutions to improve the scrolling experience in the general case using staged layout and (display: viewport). I think there are maybe cases where using a staged layout and a scrolling animation may make sense to optimize the scrolling even further, but I'm not completely convinced (any algorithm implementable by a CSS-scrolling-animation-hook, like "display: none when not in range" or "reuse/cycle through elements and modify their content via scripting later" could be implemeted in an even faster way by the UA itself as a fast path). BTW, I've a few remarks on this proposal (a generalization from Florian's analysis) but I'll leave this for another mail. Best regards, François
Received on Friday, 30 November 2012 16:48:25 UTC