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

On Fri, Feb 28, 2014 at 11:15 AM, Adam Barth <w3c@adambarth.com> wrote:

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

Generally I try to discourage WGs from pursuing features I don't think
should be part of the Web platform, and I still don't know why you
wouldn't, but I guess that's up to you.

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 don't think it's always possible to just "improve the Web platform" so
that authors have ultimate low-level control and are also future-proof
(which is a special case of being cross-platform). As Rick said above:
"there's a fundamental trade-off here between control and future-proofing".

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

I'm not interested in that. I want to expose low-level primitives wherever
that results in solid, future-proof solutions. I suspect that many of your
scrolling features are amenable to that, but I'm skeptical about
scroll-snapping for the specific reasons I cited above. I'm willing to be
corrected if you come up with a design that proves it's possible.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w