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

On Tue, Sep 23, 2014 at 11:16 AM, Robert O'Callahan <robert@ocallahan.org>
wrote:

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

Agreed.

I realize there's some backstory here that I should mention explicitly.  We
discussed this class of problems (but not this specific proposal) at the
web-input face-to-face meeting back in June.  In general, Microsoft and
Apple people expressed opposition to new mechanisms that depend on running
JS every frame, preferring instead only declarative systems.  Matt Brubeck
from Mozilla was there too but (if I recall) didn't weigh in on this
topic.  A brief summary and notes are here:
http://lists.w3.org/Archives/Public/public-touchevents/2014Jul/0000.html.
A more recent debate around this point is here:
http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0083.html

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

Yes sorry - I realize my tone is completely wrong without the context I
mentioned above.  The declarative and threaded vs. imperative and blocking
debate is what I'm referring to 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.
>

+1 I like this framing.

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

Agreed, this is an important concern.

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

Right, and I think it also helps a bit with the encapsulation problem.  Eg.
my framework may add an event handler on the document, even though only
some small component (confined to a small region of the page) is using it -
the framework should be free to implement it's own custom event dispatch
system without radically changing performance.  Also relying only on the
presence of handlers means that synchronized scroll can only ever be
enabled for a subtree of the DOM, not explicitly disabled.  So, for
example, if you have an application where some container needs synchronized
scroll but some descendant scroller does not, there's no way to express
that with event handler registration alone.  Allowing the inner component
to explicitly specify it's scroll synchronization requirements in CSS
solves this and enables UAs to provide fast paths in such a case that we
can prove the scrolling won't reach the ancestor that requires synchronized
scrolling.


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