The example commits the perennial sin of using 100vw, so that it’s somewhat broken on all platforms where scrollbars take width. There is unfortunately probably no way of getting this specific case correct without JavaScript.<p>You may have heard of new viewport units in the pipeline to fix the problems with viewport units, but <i>ugh</i>, they’re only interested in fixing the problems caused by retractable UI chrome, common in <i>mobile</i> browsers, and are still frustratingly utterly broken by design for most desktop platforms. <a href="https://github.com/w3c/csswg-drafts/issues/6551" rel="nofollow">https://github.com/w3c/csswg-drafts/issues/6551</a>, <a href="https://github.com/w3c/csswg-drafts/issues/6026" rel="nofollow">https://github.com/w3c/csswg-drafts/issues/6026</a>. Until all of this stuff gets sorted out, I continue to advise against at least viewport width units in <i>any</i> capacity.<p>I would also add that scroll snapping in general is a misguided feature, enabling functionality that is almost never actually desirable. My observation is that places that use it are almost universally frustrating in some way. Browsers’ implementations are definitely getting better, so that the viewport units problem is almost all that’s left for this example, though accidentally swiping/scrolling past more than one slide is still a problem.
I'd love to use scroll-snap more since horizontal snapping is such a common use case and the alternatives are all JS-heavy, but it straight up doesn't work for me on most of the devices I've tried it on (even the MDN docs)