Re: [css-snappoints] 3/5 Updated ED

On Mar 10, 2015, at 12:05 PM, Matt Rakow <marakow@microsoft.com> wrote:
> 
> Yes, snapping to elements is still possible.
> 
> The previous design required the elements keyword to be used to "activate" the element snap points, otherwise they had no effect.  This was done to ensure mutual exclusivity between element snap points, snap interval, and snap list syntax.
> 
> Feedback from the WG was that the mutual exclusivity seemed like an arbitrary restriction, so it was removed.  Without this restriction there's no more need for the elements keyword -- setting a scroll-snap-coordinate implicitly "activates" the snap point.


I’m not sure I like this, for a couple of reasons.

First, it means that to toggle snapping on some container, the web author has to find all the descendant elements with snap coordinates, and remove those coordinates. This isn't really hard with selectors, but gets slightly annoying if the snap coordinates were computed in script and set on inline style.

Secondly, elements can move between scrolling ancestors as those "overflow: auto” scrolling ancestors are resized (they may get big enough to no longer scroll), or their contents changed. This means that an element with a scroll-snap-coordinate set, which is intended to only snap within its scrolling container, may suddenly start to cause scroll snapping on the document.

As as web author I think of scroll snapping as a property on a specific scrolling container, not a side-effect of having some descendants with a property set. For that reason, I would prefer that we re-instate “elements”.

Simon

Received on Tuesday, 10 March 2015 19:30:18 UTC