Re: Inclusion of overflowScrolling in coremob specification

On Wed, Sep 19, 2012 at 4:12 PM, Tobie Langel <tobie@fb.com> wrote:

> 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.

Apple already implemented -webkit-overflow-scrolling for momentum scrolling
in iOS5+.

Is some standardization work going on with this in the CSS group? Anyone?

I guess we need more than a few events to en sure good performance.
 Non-visible DOM elements needs to be removed/disable from/in the DOM when
scrolling. This could ether be done within the browser, so it's completely
abstracted away, or by the application binding to scroll events.

Ideally we would add some additional scroll events, when boundaries has
been hit, beforeScroll, scrolling, scrollEnd, etc.

Should be sit down and try to define an interace for this?


/K

> >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
>