- From: Tobie Langel <tobie@fb.com>
- Date: Wed, 19 Sep 2012 14:12:06 +0000
- To: Kenneth Auchenberg <kenneth@auchenberg.dk>
- CC: Wes Johnston <wjohnston@mozilla.com>, "public-coremob@w3.org" <public-coremob@w3.org>
On 9/19/12 3:47 PM, "Kenneth Auchenberg" <kenneth@auchenberg.dk> wrote: >Hi Tobie, >I think it's a great addition to consider scroll-performance, but it >sounds to me more like you are setting requirements for a specific UI >component, than generic behavior. Possibly. What I'm really trying to do here is describe a use case so we can define what's missing to enable it. >It reminds me of some of the UI components out there, like AirBNB's >Inifinity.js (http://airbnb.github.com/infinity/), that encapsulates some >of the requirements you describe (fast rendering and smooth scrolling for >large data-sets by doing partial rendering). Agreed, this is probably best left to library authors, especially with Web components around the corner. >We could bring this behavior to any element that has overflow, but how do >you imagine it to fit into the current element model? A CSS rule to to enable momentum scrolling + events triggered during scrolling. >Specially thinking about the triggering of events to pre-fetch/render >(lazy loading) content, before end of scrolling occurs. The prefetching feels app-specific to me and doesn't belong in a generic solution, imho. The hooks (events) to enable it need to be there, however. >I could imagine an new element to encapsulates this logic and to expose >the new events, but it feels a bit of our scope.. Where would such an >element belong? Yes, that's would be work for the HTML WG, not Coremob. Still, I think it's best addressed by Web Components and left out of spec for now. I'm more interested in making sure we have the primitives on which to build such components (such as being able to opt-in to momentum scrolling, having events triggered as the user scrolls, etc.) --tobie
Received on Wednesday, 19 September 2012 14:12:40 UTC