[css-nav-1] Starting point can be off-screen

[frivoal]

---

Migrated from WICG/spatial-navigation#129
Originally created by @hugoholgersson on Fri, 02 Nov 2018 07:26:42 GMT

---

Even when the focused element F is off the screen, for example after F.focus({preventScroll: true}), spatnav uses F as starting point for distance calculations.

Why is this a problem? It gives an unpredictable user experience:

Imagine F being off-screen, above the visual viewport. If the user goes up, she probably wants to search the viewport for candidates from the bottom-most edge. (This is how spatnav would search a focused scroller.) Instead, the current spec calculates distances from the scrolled out F. The closest candidate is the focusable closest to F's position - a position the user can't see.

In Chrome we've solved this by skipping off-screen starting points: when F is off-screen, we search from an edge of the first visible enclosing container of F. I've updated https://bit.ly/snav2, my vision for spatnav in Chrome, to cover this case.

[frivoal]

---

Migrated from WICG/spatial-navigation#129 (comment)
Originally created by @jihyerish on Thu, 08 Nov 2018 09:19:06 GMT

---

In current spec, (let AD is the distance between A and D, AC is between A and C)
if AD < AC, then the focus will move to D.
For now, I'm more inclined to this behavior, but I agree that your opinion also makes sense.
@frivoal, what do you think?

[frivoal]

---

Migrated from WICG/spatial-navigation#129 (comment)
Originally created by @jihyerish on Tue, 06 Nov 2018 06:03:56 GMT

---

Instead, the current spec calculates distances from the scrolled out F. The closest candidate is the focusable closest to F's position - a position the user can't see.

By default, the best candidate which will gain the focus from the focused element (starting point) is selected among the visible focusable elements, and invisible elements aren't considered as the candidates.
It means that if the starting point becomes off-screen, the focus will always move to the element which the user can see.
For example,

• Step 1: Initial status
  ( A gains the focus.)
• Step 2: After scrolling down
• Step 3: After the down arrow button is pressed
  ( B is not considered as the candidate because it is invisible.)

You can see the result described above in here:
https://wicg.github.io/spatial-navigation/demo/sample/heuristic_scrollable.html

I think this approach can solve your concern.

[frivoal]

---

Migrated from WICG/spatial-navigation#129 (comment)
Originally created by @hugoholgersson on Tue, 06 Nov 2018 09:35:18 GMT

---

That was not my concern (I do understand that spatnav only considers visible candidates).

Look at this example:

On Down, where do you expect focus to go? C or D? As a user who cannot see A and who is completely unaware of A, I'd expect focus to go to first element in the direction, C.