W3C home > Mailing lists > Public > www-style@w3.org > January 2016

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

From: Florian Rivoal <florian@rivoal.net>
Date: Sun, 17 Jan 2016 00:37:39 +0900
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, fantasai <fantasai@inkedblade.net>
Message-Id: <5D36F98E-9F41-4B66-9A33-1CAE3249D5DF@rivoal.net>
To: Matt Rakow <marakow@microsoft.com>

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

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

I though we already had a resolution on this, but based on https://lists.w3.org/Archives/Public/www-style/2015Nov/0266.html (see "Do Layout Changes Resnap?"), it looks like we merely had general agreement, and might still have needed to work out some details. (for example: you're snapped to a proximity point, then it gets moved to where you cannot keep snapping to it, then it moves back to where you could. Are you considered snapped to it the whole time, even when you couldn't track it, and therefore follow it back when it becomes reachable again, or does its getting out of range free you from the snap?)

 - Florian
Received on Saturday, 16 January 2016 15:38:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:59 UTC