Re: Enabling scroll customization - beforescroll (was: Blink team position on snap points)

On Mon, Sep 22, 2014 at 11:05 AM, Rick Byers <rbyers@chromium.org> wrote:

> Thanks.  I've improved the language in the doc a bit.  It's temping to
> define beforescroll events as explicitly bubbling up the containing block
> chain, but I thought it was best if these were really just normal DOM
> events - not magic in any way.  Do you agree?
>

Yes.


> The containing block is always defined by an ancestor in the DOM, right?
>

Yes.


> So it's still correct to model this in terms of beforescroll bubbling up
> the DOM, but native scrollers ignoring events when they're not part of the
> containing block chain of the target, right?
>

Yeah I think that works.


> I don't think how this should behave is specified anywhere, right?  Should
>>> it be?
>>>
>>
>> For beforescroll it probably does have to be specified.
>>
>
> Yes.  Sorry what I meant was even in the absence of beforescroll, is there
> interest in trying to more completely specify scrolling behavior?  Is CSS
> OM View the right spec for that sort of thing?
>

So far I have not observed Web authors depending on the order in which
scrolling gets delegated, but I could have missed it.

But 'beforescroll' makes the native scrolling behavior much more observable
by Web authors so I think it would be a good idea to converge browser
behavior if we can get consensus.

Thanks!  Is CSSWG the right group to focus on this do you think (even
> though it likely involves a new DOM event)?
>

I think so.


> Any suggestion on how best to move forward in standardizing something like
> this?
>

I think we are moving forward! We're having some discussions within Mozilla
as we speak and we should be able to give more feedback soon. I think right
now the most important thing is actually to get feedback from other vendors
especially Microsoft and Apple --- especially Apple, since they have
presented animation-timebase and their developers also have plenty of
knowledge regarding a native mobile platform...

On Sat, Sep 20, 2014 at 11:12 AM, Adam Barth <abarth@chromium.org> wrote:
>
>> The reason we process input events off the main thread is because our
>> rendering engines are required to render content designed for desktop on
>> mobile.  These sites are not engineered for the requirements of mobile
>> devices and therefore do not have sufficiently low latency to process input
>> events on the main thread.
>>
>> To create highly interactive, bespoke visual effects, apps that run on
>> other platforms (e.g., Cocoa and the Android framework) process input
>> events on the main thread.  In order to create the breadth and quality of
>> visual effects, we anticipate needing to let web developers also process
>> input events on the main thread.
>>
> Introducing a JS worker to process input events off the main thread might
>> help web apps that aren't engineered for mobile produce better visual
>> effects, but it's not a path that leads to a web platform that competes on
>> an equal footing with apps written to the Cocoa and Android frameworks.
>>
>
> Agreed.  The blink team's focus is on enabling mobile web apps which are
> competitive with native iOS and Android apps.  That said, we recognize the
> other browser vendors have somewhat different priorities.
>

It's important to us too.

I think the main place for discussion here is how we can best advance both
> philosophies together (there's no reason the web platform as a whole needs
> to choose one philosophy or the other, even if the individual
> implementations have some bias).
>

I'm not sure we have competing philosophies here.

A standard trope is that APIs should make simple things easy and complex
things possible. Declarative approaches like animation-timebase make simple
things easy. ("Easy" includes maintaining responsiveness when a Web page
hasn't tuned its main-thread latency.) "beforescroll" makes complex things
possible.

BTW one interesting issue is encapsulation. Declarative syntax or a
worker-based approach have the nice property that you can wrap the
functionality in a library and it will work and probably hit performance
targets regardless of what else the app does. You can wrap beforescroll
behaviors in a library but the library can't stop other parts of the app
from causing jank so there's less encapsulation.

For example, there's been some discussion that disabling threaded scrolling
> just to the presence of an event handler is bad, and we should have some
> more explicit opt-in mechanism.
>

Is this the "my framework adds event handlers for everything to every
element even if I'm not using them" problem?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.