Re: [css-snappoints] [css-scroll-snap] Summary of latest updates 1/13

On Sat, Jan 16, 2016 at 7:37 AM, Florian Rivoal <florian@rivoal.net> wrote:
>> On Jan 16, 2016, at 08:26, Matt Rakow <marakow@microsoft.com> wrote:
>>> Going over this section, however, we've noticed that it's not really correctly specified overall. We made the following changes to clarify:
>>>  https://hg.csswg.org/drafts/diff/c6492e849001/css-scroll-snap/Overview.bs
>>> which you can see at:
>>>  https://drafts.csswg.org/css-scroll-snap/#snap-type
>>
>> Yeah, I think that area still needs further scrutiny too.  E.g. probably also needs to account for when the type is toggled and a few other things.  I'll put some more time into it.
>>
>> I'd generally favor going more-strict here, must for both sounds fine to me.  I've updated the ED to specify that prox/mand MAY/MUST resnap and it MUST/MUST be the same position as before.  I see your updates put it at MUST/MUST resnap and it MUST/MUST be the same position as before.  I'm fine with that too -- any strong preference between those?
>
> I'm in favor. The only case I think should be excluded is when you were snapped to a proximity snap point, and it stops existing. Then unless you happen to be in proximity of another snap-point, there's no reason to resnap.

That's covered. The language is tricky, but I think we got it right in
the css-scroll-snap document - act as if the user scrolled to the
current position, and snap accordingly.  (Which means nothing special
happens if the previous snap position disappears and there's nothing
else nearby.)  We'll be suggesting that Matt steal that in a bit.

> But if you are snapped to a proximity snap point and it moves, there's no reason not to track it, and the user experience becomes worse if you don't.
>
> One example: the page is a series of articles/sections/chapters, with proximity snapping at the beginning of each article. You load it on a slow network, so a bunch of images haven't loaded yet. You scroll down (or follow a link with an #anchor) to an article in somewhere in the middle of the page,  and snap to its beginning. Then images load, reflow happen, and push the article whose beginning you're snapped to further down. The UX is so much better of you track it. Having your reading interrupted by assets loading in a part of the document you're not looking at is terrible (and unfortunately common in the absence of scroll snapping).

Yup, exactly.  The argument for tracking a still-existing snap
position is exactly as strong whether you're proximity or mandatory.

~TJ

Received on Tuesday, 19 January 2016 18:59:01 UTC