W3C home > Mailing lists > Public > public-coremob@w3.org > September 2012

Re: Inclusion of overflowScrolling in coremob specification

From: Kenneth Auchenberg <kenneth@auchenberg.dk>
Date: Wed, 19 Sep 2012 15:47:39 +0200
Message-ID: <CADYWSV2uA4hMOvgRyqPwejJTFMZa=tzNMNWen_JXEt0E5LJgZQ@mail.gmail.com>
To: Tobie Langel <tobie@fb.com>
Cc: Wes Johnston <wjohnston@mozilla.com>, "public-coremob@w3.org" <public-coremob@w3.org>
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.

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

We could bring this behavior to any element that has overflow, but how do
you imagine it to fit into the current element model? Specially thinking
about the triggering of events to pre-fetch/render (lazy loading) content,
before end of scrolling occurs.

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?


-
Kenneth Auchenberg
+45 53 22 22 33


On Fri, Sep 14, 2012 at 7:39 PM, Tobie Langel <tobie@fb.com> wrote:

> On 9/14/12 7:25 PM, "Wes Johnston" <wjohnston@mozilla.com> wrote:
>
> >On 09/14/2012 10:22 AM, Tobie Langel wrote:
> >> On 9/13/12 2:41 AM, "Wes Johnston" <wjohnston@mozilla.com> wrote:
> >>
> >>> As far as i can tell, overflowScrolling was included in the coremob
> >>>spec
> >>> and in the current rng.io test suite because of a desire from web
> >>> developers to have some means of specifying whether or not elements
> >>>that
> >>> overflowed allowed scrolling or not. AFAICT, its only implemented on
> >>>iOS
> >>> Webkit as a way of switching from requiring two-fingers to scroll this
> >>> content, to only requiring one. There's also some bits in there about
> >>> kinetic panning that aren't well specified.
> >> I realized I missed your comment about rng.io.
> >>
> >> rng.io is a Facebook product. You should file issues[1] against it
> >> directly.
> >>
> >> Note that there's a related issue[2] that has already been opened on the
> >> bug tracker.
> >>
> >> --tobie
> >>
> >> ---
> >> [1]: https://github.com/facebook/rng.io/issues/
> >> [2]: https://github.com/facebook/rng.io/issues/27
> >>
> >Ahh. Thanks. I'll file something there. I'm still concerned about what
> >coremob is supprting though. What are you proposing to bring for
> >standardization?
>
> I've started discussing this in the WebPerf group[webperf-minutes]. I'm
> not sure how to best tackle the standardization aspect of this as a lot of
> it are QoI issues. Here are some of the requirements we have:
>
> - Scrolling must be fast and smooth.
> - It must trigger a given set of events so content can be prefetched,
> computed and appended as the user scrolls towards the bottom of the loaded
> content.
> - It must allow i/o and computation in the background (without affecting
> the smoothness).
> - It must allow appending fresh content to the main content while
> scrolling (again, without affecting the smoothness).
> - It must reliably handle scrolling though a lot of content, including
> lots of images.
> - It must be possible to capture touch events during scrolling.
>
> I'll post more soon. Comments welcomed.
>
>
> --tobie
> ---
> [webperf-minutes]: http://www.w3.org/2012/09/12-webperf-minutes.html
>
>
>
>
>
>
Received on Wednesday, 19 September 2012 13:48:34 UTC

This archive was generated by hypermail 2.3.1 : Friday, 19 April 2013 17:36:47 UTC