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

On Thu, Feb 27, 2014 at 1:21 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Feb 28, 2014 at 10:12 AM, Adam Barth <w3c@adambarth.com> wrote:
>
>> On Thu, Feb 27, 2014 at 1:06 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> On Fri, Feb 28, 2014 at 8:51 AM, Adam Barth <w3c@adambarth.com> wrote:
>>>
>>>> Instead of hard coding snap points into the platform, we'd rather the
>>>> platform was powerful enough that framework authors can implement snap
>>>> points themselves.
>>>>
>>>> As Rick stated, we're not opposed to this working group pursuing snap
>>>> points.
>>>>
>>>
>>> These two positions seem inconsistent to me. If you don't want snapping
>>> hard-coded into the platform, you should be opposed to the working group
>>> pursuing that.
>>>
>>
>> Why's that?
>>
>
> This seems so obvious to me that I find it difficult to explain further,
> but maybe I misunderstood what you said.
>
> Clearly you plan to develop some kind of DOM API giving the control of
> scrolling you want, and let's assume that effort succeeds. If the working
> group standardizes a CSS scroll-snapping API, would you simply refuse to
> implement it forever, or would you wait to see if it gets adopted before
> implementing, or would you happily implement it in addition to your DOM API?
>

If snap-points become widely used among authors, I would expect we'd
implement it to improve compatibility.  There are many APIs that we
implement for compatibility that we wouldn't implement otherwise.

On Thu, Feb 27, 2014 at 1:45 PM, Robert O'Callahan <robert@ocallahan.org>
 wrote:

> OK. I think that's a good goal, but I don't know how reachable it is and I
> guess you don't either yet.
>
> Replicating our implementation of CSS scroll-snapping in script is
> possible, given sufficient new DOM APIs, but it sounds hard to me for a
> couple of reasons.
>
> Our implementation works with all kinds of scroll gestures --- mousewheel,
> keyboard input, scrollbar interaction, touch panning and touch flinging. It
> can be extended to work with any new scroll gestures that emerge in the
> future. To get the same flexibility in script would require completely new
> scrolling events that are gesture-independent. However, the actual behavior
> we implement is specific to each gesture. For example, when pressing the
> down-arrow key, we are willing to scroll somewhat further than a line to
> reach a snap-point. But when pressing the page-down key, we prefer not to
> look for snap-points further than the normal page-scroll distance because
> we don't want to lose context by scrolling more than a full page. So the
> challenge is to ensure that scripts written today can produce ideal
> snapping behavior for all scroll gestures on all platforms, including those
> that haven't been invented yet. One approach would be to devise a
> vocabulary of logical scroll operations (e.g., "scroll by N lines, scroll
> by page, continuous pan", etc) and try to map all current and future scroll
> gestures onto it, but that introduces a risk that the approach may break
> down in the future because the vocabulary is inadequate, and CSS
> scroll-snapping avoids such a risk.
>
> Another issue is that our implementation snaps to the edges of CSS
> fragments, e.g. the border-box edges of elements with "scroll-snap-edges:
> border-box" and the margin-box edges of elements with "scroll-snap-edges:
> margin-box". To implement this properly in script can't even be done with
> CSSOM APIs implemented today, and even with new APIs like getBoxQuads it
> will be tricky. Performance will be an issue since you potentially have to
> examine the geometry of a very large number of elements.
>

>From my perspective, those all point to things that are worth improving
about the platform.  If the platform hasn't explained itself sufficiently
to let framework authors implement snap-points well, then we've let authors
down.

I understand that other implementors are likely to have a different
perspective and are interested in tiling the space of scroll-related
effects with a series of declarative mechanisms.  My perspective after
having studied scroll-related effects in mobile apps is that there is a
wide variety of these effects because iOS and Android let apps customize
scrolling in bespoke ways.  If the web is going to compete with those
platforms, we need to provide authors the same power.

Adam