W3C home > Mailing lists > Public > www-style@w3.org > July 2015

RE: [css-snappoints] Always snapping to a mandatory point

From: Matt Rakow <marakow@microsoft.com>
Date: Fri, 31 Jul 2015 19:52:02 +0000
To: "robert@ocallahan.org" <robert@ocallahan.org>
CC: "www-style@w3.org" <www-style@w3.org>, Majid Valipour <majidvp@chromium.org>
Message-ID: <BY2PR03MB3615F974AB3DAE11DB5395AAD8A0@BY2PR03MB361.namprd03.prod.outlook.com>
> What happens if that snap point ceases to exist?

In the case of mandatory snap points it will need to be resnapped to a valid location.  I'm inclined to leave it to the UA for exact selection mechanism (in the same way that a snap point selection is not specified for scrolling), but "snap to closest" or "snap to next" is probably a recommendable approach.  Likely scenarios might include deleting a center-snapped photo from a filmstrip view.

For proximity the requirement is lightened from "must" to "may".  I expect UAs may want to consider other factors (e.g. distance) when deciding whether resnapping is appropriate.

> When does this auto-snapping occur? On every layout? Including layouts that occur during script execution?

No need to resnap synchronously during script execution; this requirement is intended to ensure the user isn't left long-term with an invalid view, not to eliminate transient states.  Resnapping should be done after OM/layout/display completes, as long as there's also not a scroll currently underway for that scroller or any descendent scroller.

> What happens if layout changes to that the current snap point can't be snapped to anymore because the container can't be scrolled far enough?

Same as for deleting the point.  If the snap type is mandatory then the scroller must be snapped to some point to ensure a valid view, so if its currently snapped point becomes invalid for any reason then resnapping must occur.

Received on Friday, 31 July 2015 19:52:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC