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

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.

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

For beforescroll it probably does have to be specified.


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

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.

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.