Where do we find "visible" candidates? scrollport or optimal viewing region? #29

frivoal · 2018-02-16T07:30:54Z

In the https://wicg.github.io/spatial-navigation/#find-candidates section, we try to limit the list of candidates to visible focusable elements. Should we limit the search to the optimal viewing region (taking the scroll-padding property into account)?

Given that the next step uses hit testing to further narrow the list, that may not be necessary. But maybe.

The text was updated successfully, but these errors were encountered:

hugoholgersson · 2018-02-21T08:35:10Z

Taking scroll-padding into account adds more complexity to the algorithm, doesn't it?

frivoal · 2018-02-21T10:06:02Z

I guess so, but not by much, this is just using one rectangle instead of another rectangle.

For now, scroll-padding is new, so people have relatively few expectations linked to it, and we have relatively little experience about how it is typically used. A major anticipated use to to declare "off limits" the sides of a scroller that are overlapped (possibly partially) by something. In which case, scroll-padding is acting as a proxy for (some cases of) hit testing.

If we have actual hit testing (which the spec currently calls for), then it may not be useful to account for scroll-padding as well.

However:

Maybe hit testing isn't actually practical. We're not asking for "can this point be hit", but "can any point be hit". I do not know how performantly this can be implemented. If it turns out we cannot have it, the scroll-padding can take care of a range of cases where visibility on the sides is impeded.
Maybe people will use scroll-padding for reasons other than visibility, to give things breathing room. In that case, it sounds like taking it into account would be nice as well.

However, it is meant to

I am thinking that:

if it turns out we cannot use hit-testing to include / exclude elements (maybe it's too expensive), then taking scroll-padding into account gives an OK approximation for some situations

anawhj · 2018-03-16T00:25:30Z

It seems that scroll-padding would be working only if snapping is on. I think we can access an element using SpatNav, even if the element is on the scroll-padding area.

BTW, both SpatNav and snapping are enabled in a web page, which one gets a higher priority? I found that one of default behavior of arrow keys would be snapping (scrolling as a unit of specified offset), so we should care this situation. I think, in this case, snapping has a higher priority than SpatNav.

Back to this issue, visible candidates might be able to be found in the scrollport.

hugoholgersson · 2018-03-16T09:46:52Z

If one arrow-key scroll step, no matter how big/small that step is, reveals focusables - then those focusables should be considered reachable = "navigable" = candidates, right?

(The fact that arrow-key scrolling will stop at or continue until a scroll snap point shouldn't matter?).

anawhj · 2018-03-19T08:42:19Z

When you use the scroll snap feature, the one arrow-key scroll step doesn't change the focus. For that reason, I think it would be one of the arrow keys' default behavior, unlike just a change of the scroll offset by arrow keys. You can see the behavior where the focus is always in a document(<body>), though when snapping(=changing scroll offset as a snap unit) in the following example. (preferably run it on FF)
https://hospodarets.com/demos/scroll-snap-full-screen

On second thought, we could manage the focus using SpatNav in a single snap unit. If the focus is about to go outside of scrollport, the snap operation is executed at the moment, but it would have to be more investigated later. (probably level 2)

FYI, Snap Points design document (Chromium)
https://docs.google.com/document/d/1xbc9W_Ac-ve0gE_ppT9y8aydVJJ7NXUL-9MVq0yPhsE

frivoal · 2018-03-20T03:14:08Z

scroll-padding works even when snapping is not turned on. The goal of srcoll-padding is for the author to show that there is an area at the edge of the scroller that is not good to place elements in when you try to interact with them or read them.

For example, if there is an absolutely positioned / sticky positioned banner that hides the first 50px of the scroll port, then the author should set scroll-padding-top to 50px. That way, if someone focuses something that would be hidden by that banner (using script or the tab key), or if someone navigates to the #anchor of an element that would be hidden by the banner, then the browser will scroll to move it past the 50px, and make it visible.

So, with spatnav, if the element becomes focused, it will cause the scroller to scroll, in order to move it past the 50px as well. The question is: instead of focusing it while it was hidden, and scroll to make it not hidden, should the "move up" request by the user have scrolled (without focusing) instead when it was hidden, and the next "move up" would then have focused it, because it is now visible?

When it is outside of the scrollport, that's what happens. I think it should probably be what happens when it is inside the scrollport but outside the optimal viewing region.

If one arrow-key scroll step, no matter how big/small that step is, reveals focusables - then those focusables should be considered reachable = "navigable" = candidates, right?

Yes, but the question is what do we mean by "reveals". Should we do it strictly on visibility? scroll-padding is meant to allow the author to say: "even if this is in the scrollport, this area is a bad place". That seems worth listening to.

If it turns out that the "Remove from visibles items are obscured by other parts of the page" step cannot be efficiently implemented (and I think there's a real risk that that's the case, and will discuss with the csswg at the next F2F), I think it is pretty important to respect scroll-padding. If it can, then I am less sure.

Instead, navigating down (resp. up, left, right) when a scroller is focused will automatically chose between * focusing the child nearest from the edge in that direction if there is any focusable child * scrolling otherwise This also removes much of the special casing needed for the root. Some ambiguities / inacuracies were resolved along the way. Closes WICG#15 Closes WICG#18 Partly relates to WICG#29

Instead, navigating down (resp. up, left, right) when a scroller is focused will automatically chose between * focusing the child nearest from the edge in that direction if there is any focusable child * scrolling otherwise This also removes much of the special casing needed for the root. Some ambiguities / inacuracies were resolved along the way. Closes WICG#15 Closes WICG#18 Partly relates to WICG#29 Includes an example script showing how to do focus delegation

Instead, navigating down (resp. up, left, right) when a scroller is focused will automatically chose between * focusing the child nearest from the edge in that direction if there is any focusable child * scrolling otherwise This also removes much of the special casing needed for the root. Some ambiguities / inacuracies were resolved along the way. Closes WICG#15 Closes WICG#18 Partly relates to WICG#29

frivoal · 2018-04-03T07:20:56Z

Putting this on the CSSWG's F2F agenda. The key question for the CSSWG and browser implementors is:

Hit testing, where you check which a element/box would be hit if you click at a certain position, or whether a particular element would be hit by clicking at a position is an existing part of the web platform. However, is the following related-but-different check is practical to implement:

can a particular element/box be hit (in the sense of hit-testing) at any point, or is it entirely obscured by other elements?

The context for wanting this check is that we would like to exclude from spatial navigation elements that are hidden behind other things (like pop-over, dialogs, etc), because it is quite likely both of the following statements are true:

It is not rare for authors to forget about disabling (e.g. by setting the inert attribute) elements that are obscured by temporary dialogs
It is not rare for authors to implicitly assume that elements which cannot be clicked on (because they are obscured) will not be activated, and application logic may break if this assumption is violated.

Stated differently, we would like to make the same elements reachable by spatnav as those that are reachable by clicking (and only those), without requiring the author to do anything in particular.

If this is not possible, it seems that relying on the optimal viewing region (i.e. taking the scroll-padding property into account) will give us an approximation for the full solution in some of the the cases, and that authors will need to manually disable things in other cases.

frivoal mentioned this issue Mar 23, 2018

Remove using the enter key to navigate inside scrollers #39

Merged

frivoal added type:question Known unknows: things we need to investigate topic:spec needs:feedback The editors would like feedback from more people before resolving needs:liaison Coordination with another WG/CG/etc needed to be able to close this issue. labels Apr 2, 2018

frivoal closed this as completed in 0c8822d Apr 27, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Where do we find "visible" candidates? scrollport or optimal viewing region? #29

Where do we find "visible" candidates? scrollport or optimal viewing region? #29

frivoal commented Feb 16, 2018

hugoholgersson commented Feb 21, 2018

frivoal commented Feb 21, 2018

anawhj commented Mar 16, 2018

hugoholgersson commented Mar 16, 2018

anawhj commented Mar 19, 2018 •

edited

Loading

frivoal commented Mar 20, 2018

frivoal commented Apr 3, 2018

Where do we find "visible" candidates? scrollport or optimal viewing region? #29

Where do we find "visible" candidates? scrollport or optimal viewing region? #29

Comments

frivoal commented Feb 16, 2018

hugoholgersson commented Feb 21, 2018

frivoal commented Feb 21, 2018

anawhj commented Mar 16, 2018

hugoholgersson commented Mar 16, 2018

anawhj commented Mar 19, 2018 • edited Loading

frivoal commented Mar 20, 2018

frivoal commented Apr 3, 2018

anawhj commented Mar 19, 2018 •

edited

Loading