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

Updating subject since we're really talking about beforescroll here.


On Fri, Sep 19, 2014 at 9:32 PM, Robert O'Callahan <robert@ocallahan.org>
 wrote:

> On Sat, Sep 20, 2014 at 3:00 AM, Rick Byers <rbyers@chromium.org> wrote:
>
>> On Thu, Sep 18, 2014 at 6:06 PM, Robert O'Callahan <robert@ocallahan.org>
>>  wrote:
>>
>>> On Fri, Sep 19, 2014 at 6:35 AM, Rick Byers <rbyers@chromium.org>
>>>  wrote:
>>>
>>
>> Native div scrolling will ignore beforescroll events that have passed
>>>> through an absolutely positioned element
>>>> <http://www.w3.org/TR/CSS2/visuren.html#absolute-positioning>. This
>>>> explains why scrolling will chain up only
>>>> <http://jsbin.com/larapi/2/edit> to fixed or absolutely positioned
>>>> elements, and then chain directly to the document (not impacting any other
>>>> ancestor scrollers).
>>>>
>>>
>>> I don't understand this. Is this emulating some Blink-specific
>>> Blink-native scrolling behavior? Firefox scrolling doesn't have any
>>> behavior like this.
>>>
>>
>> Sorry, I didn't word this clearly.  What I see on Chrome, Safari and
>> Firefox (probably more easily observed with http://jsbin.com/larapi/3)
>> is if you attempt to scroll a positioned element beyond it's scroll limit,
>> it will cause the document to scroll (not any intervening scrollable
>> elements in the DOM).  In blink this is because scrolling propagates up
>> via the containing block
>> <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/EventHandler.cpp&q=EventHandler::scroll&sq=package:chromium&type=cs&l=887>.
>> I just tested this on Firefox 32.0 for Ubuntu.
>>
>
> Ah right. Yes, I think scrolling should propagate up the containing block
> chain. This doesn't imply you go directly from an fixed-pos or abs-pos
> element to the document, since a fixed-pos or abs-pos element can have a
> containing-block parent that's not the viewport or the canvas.
>

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?  The containing block is
always defined by an ancestor in the DOM, right?  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?  It's not inconceivable that some custom
scroller might want a different rule here (eg. to match IE's behavior).

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?

Note that one motivation for this approach (but certainly not our only one)
>>>> is Google's material design (
>>>> http://www.google.com/design/spec/material-design/introduction.html).
>>>> There are a number of scroll-linked effects that will be shipping in mobile
>>>> apps which are currently impossible to do properly on the web.
>>>>
>>>
>>> Do you have something that describes what they are?
>>>
>>
>> The most sophisticated effects we're working on are unfortunately not
>> shipping yet.  But some of the components and simpler examples are.
>> There's the core-scroll-header example from Polymer
>> <http://www.polymer-project.org/docs/elements/core-elements.html#core-scroll-header-panel> for
>> a start.  Note how the header motion often doesn't stay quite in sync with
>> the content motion (since it's positioned in response to async scroll
>> events) - to me this ruins the "material" effect they're trying to
>> achieve.  Also the spec
>> <http://www.google.com/design/spec/patterns/gestures.html#gestures-gestures> briefly
>> describes "reveal upon scroll" (which we've been calling "hidey bars" in
>> this discussion).  To work at all we've found these have to be synchronized
>> perfectly the content scrolling (see the top controls on Chrome Android on
>> a phone).  I'll be working on publishing some more sophisticated examples
>> soon, and we'll have some shipping products to point to eventually too.
>>
>
> I see, thanks.
>
> <soapbox>
>> Most importantly to me here is that a number of Google product teams are
>> working on interesting but unique material-like effects in their Android
>> and iOS apps (not relying on some single gold list of a few permitted
>> effects).  Very few of them are even _trying_ to achieve these sorts of
>> rich effects on the web anymore. They're not even complaining it's not
>> possible because they've largely given up on the web - telling me things
>> like "its so much nicer to feel like I'm not fighting the platform anymore
>> now that I work exclusively on native mobile apps"!
>>
>> This of course isn't limited at all to Google products and Google's
>> material design (that's just where I personally get the most insight -
>> pressure I can't continue to treat without serious urgency).  Just compare
>> the native and web versions of Facebook, Twitter, Yelp, etc.  This should
>> be terrifying for all of us who believe in the value of an open and
>> interoperable web.  This is the main reason many of us on the blink team
>> aren't content with a solution along the lines of "scrolling through time
>> <http://lists.w3.org/Archives/Public/www-style/2012Nov/0496.html>"
>> (including Apple's proposal from last week
>> <http://lists.w3.org/Archives/Public/www-style/2014Sep/0135.html>).
>> That addresses a big chunk of the currently unsolved use cases today, but
>> it continues to play the game of blocking UI innovation on the long browser
>> development and consensus process.  If the web is to remain relevant we
>> need to give developers the power <http://extensiblewebmanifesto.org/> to
>> innovate on their own without trying to continue to be the UI gate
>> keepers...
>> </soapbox>
>>
>
> I agree and I'm glad you're tackling this.
>

Thanks!  Is CSSWG the right group to focus on this do you think (even
though it likely involves a new DOM event)?  Any suggestion on how best to
move forward in standardizing something like this?  If it would help to be
able to brainstorm about this in person, we could probably arrange to fly
out to TPAC.

I think solutions like animation-timebase are important too, assuming that
> developers will hit their performance targets more easily with those than
> when using a main-thread-scripting solution.
>

 On Sat Sep 20 2014 at 7:59:23 AM Robert O'Callahan <robert@ocallahan.org>
wrote:

> BTW, a while back the Blink team produced a proto-proposal which involved
> using a JS worker to process input off the main thread. Why did you end up
> not pursuing that path?
>
> 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.  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).

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.  Would folks here be interested in a CSS
property that gives web developers more explicitly control over when
threaded scrolling is permitted?  Eg. here's some brainstorming on a
"scroll-delay" proposal
<https://docs.google.com/a/chromium.org/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit>
which we could add "beforescroll" to (and also simplify to remove
non-essential parts).  We've discussed this a bit
<http://lists.w3.org/Archives/Public/public-touchevents/2014Aug/0011.html>
with the IE team over on public-touchevents.

On Sat, Sep 20, 2014 at 3:41 PM, Florian Rivoal <florian@rivoal.net> wrote:

>  On Wed, 26 Feb 2014 23:25:01 +0100, Rick Byers <rbyers@chromium.org>
> wrote:
>
> We realized that there hasn't been much involvement from the blink team on
> this proposal.  I just wanted to send a quick note to communicate our
> position (especially since I was so enthusiastic about this in initial
> discussions with Microsoft immediately after it was announced in IE).
>
> We're currently focused (eg. see [1]) on low-level mechanisms that give
> framework developers more flexibility to customize the behavior while
> scrolling.  We imagine a world where frameworks can implement a wide
> variety of effects like snap points without needing any new APIs and the
> associated web-standards efforts.
>
>
> I've run into articles from the New York Times filled with excellent use
> cases for customizable scrolling. They've made a number of interesting
> effects, from simple snap scroll or sticky positioning, to parallax
> effects, fading in and out, videos sync with scrolling, and many others
> things.
>
>
> http://www.nytimes.com/interactive/2014/09/19/travel/reif-larsen-norway.html
> (fading, snap points, video/animation sync)
>
> http://www.nytimes.com/projects/2013/gun-country/
> (snap points, video sync)
>
> http://www.nytimes.com/projects/2013/the-jockey/
> (fading, snap points, video/animation sync, sticky positioning...)
> Note the interesting pull quotes that combine it all.
>
> http://www.nytimes.com/projects/2013/tomato-can-blues/
> (parallax, sticky positioning, progressively-insert-and-move-things,
>
> http://www.nytimes.com/projects/2012/snow-fall/
> (automatic scrolling, fading, video/animation sync, sticky positioning)
>
> If you haven't seen these articles before and are working on a
> customizable scrolling proposal, I think they're well worth looking at.
>

Thanks Florian!  These are all great examples.  When we publish our
beforescroll samples I'll be sure to show or describe how each of these
would be implemented with beforescroll.  I see these current
implementations also suffer from synchronization issues.


>
>  - Florian
>