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

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

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

I think it's also possible that we won't come up with a design that we're
happy with (or at least not one we feel we can implement in the near
future).  At that point I'll be very glad that we can fall back to
implementing your design first :-).  I think we all agree that the scenario
is very important.


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