- From: Majid Valipour via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Oct 2019 18:07:12 +0000
- To: public-css-archive@w3.org
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