Re: [css-snappoints] Blink team position on snap points

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:
>
>> To follow up from this old thread, we've just started a discussion over
>> on www-dom ("Enabling scroll customization") for one approach to allow
>> frameworks to implement effects like snap points in JavaScript:
>> http://lists.w3.org/Archives/Public/www-dom/2014JulSep/0134.html.
>>
>
> Apologies for following up here, but it's more of a CSS issue:
>

Sure, I'm happy to discuss this with whatever WG is interested.

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.  IE is apparently different
in that the scrolling chains up the DOM.

I don't think how this should behave is specified anywhere, right?  Should
it be?

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.

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

Rick



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