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

> On Mar 10, 2015, at 12:38 PM, Matt Rakow <marakow@microsoft.com> wrote:
> 
> To toggle snapping on the container the author can set the scroll-snap-type to "none" on the container, this avoids modifying all descendants.

Ah right, sounds good.

> 
> The overflow:auto scenario is a good point, since the spec as written currently implies that the snap points would be attached to the nearest ancestor that actually has overflowed content.  I think this is most easily avoided/resolved by changing the definition of scroll container to be "An element with a used value for the overflow property other than 'visible'" - what do you think?

Hmm, the problem with that is it prevents elements nested inside overflow:hidden boxes from snapping in their ancestor scrolling container, and I think that’s a pretty common scenario.

Simon

> 
> Thanks,
> -Matt
> 
>> -----Original Message-----
>> From: Simon Fraser [mailto:smfr@me.com] 
>> Sent: Tuesday, March 10, 2015 12:29 PM
>> To: Matt Rakow
>> Cc: www-style@w3.org
>> Subject: 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 20:22:08 UTC