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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 3 Aug 2015 11:27:41 -0700
Message-ID: <CAAWBYDAu8GfLxciT-RNsV5Z7x8KaCK4SaitPNSCkyuok-Ofxzw@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Matt Rakow <marakow@microsoft.com>, "www-style@w3.org" <www-style@w3.org>, Majid Valipour <majidvp@chromium.org>
On Fri, Jul 31, 2015 at 6:00 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Sat, Aug 1, 2015 at 7:52 AM, Matt Rakow <marakow@microsoft.com> wrote:
>>
>> > 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.
>
>
> That sounds reasonable, but it also sounds like a potential interop
> minefield.

Yes, if we did this it would need to be specified.

>> > 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.
>
>
> Is this what IE actually does? It sounds like it could lead to very bad user
> experiences, where an element that the user was looking at suddenly
> disappears because the browser had to scroll to snap to another element.

Is the context here some situation like "the element that's currently
snapped to moves slightly too far in the start direction, thus putting
its snap point in the unscrollable area"?

~TJ
Received on Monday, 3 August 2015 18:28:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 3 August 2015 18:28:29 UTC