Re: [csswg-drafts] [css-scroll-snap-1] Compat between webkit and blink/gecko regarding "implicit" scroll boundary snap positions (#4037)

Paging in spec editors @fantasai @tabatkins

I agree that this is an interop issue.

Per current spec adding implicit start/end snap position is not correct. This is what Blink/Gecko implemented but safari does add implicit snap position at start/end of scrolling content.

Here is some initial thoughts:

- I agree that if we don't add implicit snap points at start/end then we should not load scroller at offset 0. Rather the initial load should be at "nearest snap points to 0". So I consider that an implementation bug for Blink/Gecko. We need to better understand web compat impact.

- I personally like the current model (assuming we fix the above issues). Since it is easy to add these start/end if one needs them. 

- If we ended up deciding we want to have the implicit start/end snap offset I think it is important to have a way to disable them for some use cases. @justingrant  has made a compelling argument for one such usecase so I won't rehash it. Another one is to enable a cheap way to create that bounce-back effect which is desired in some cases.

- I think the implicit start/end snap points where more needed in the old snap points model where they were being specified as specific offsets. In that world it was much easier to make a mistake of not having those even if you content was starting at position 0. In the new model where you specify snap alignments on content itself I think they are less useful.

In any case, I think we should drive to a consensus here since if we don't remove the existing load at 0 behavior the issue will get harder to deal with over time.




-- 
GitHub Notification of comment by majido
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4037#issuecomment-538060075 using your GitHub account

Received on Thursday, 3 October 2019 18:07:14 UTC