[css-nav-1] Consider candidates revealed after one scroll step?

[frivoal]

---

Migrated from WICG/spatial-navigation#56
Originally created by @hugoholgersson on Fri, 27 Apr 2018 14:26:33 GMT

---

When finding the candidate set, Chrome's spatnav includes focusables that would become visible after one (document*) scroll step in the navigated direction.

* We don't do this for scrollable divs but I consider that a bug. I believe spatnav should treat both document scrolling and element scrolling in the same way.

This behavior is not spec'ed. Should we?

Downsides:

• Trickier implementation.

Upsides:

• Better UX.

1. One keystroke instead of two: [scroll + focus] instead of [scroll] + [focus].
2. Focused element (and its "focus ring", if enabled) is always visible (it cannot be scrolled out).

[frivoal]

---

Migrated from WICG/spatial-navigation#56 (comment)
Originally created by @hugoholgersson on Fri, 11 May 2018 14:01:21 GMT

---

I think [scroll + focus] is better for users, yes :) I also think scrolling should be consistent; element scrolling (such as div scrolls) shouldn't be different from body scrolls. It is now in Chrome.

In current Chrome, when spatnav scrolls body, spatnav can [scroll + focus], but spatnav cannot when it scrolls an element.

[frivoal]

---

Migrated from WICG/spatial-navigation#56 (comment)
Originally created by @frivoal on Mon, 10 Sep 2018 05:59:13 GMT

---

With spatnav however, can that happen given we do scrolling in line-height:ish big steps?

It currently cannot, since spatnav will not focus something that was out of the screen before scrolling.

If something was not visible before scrolling, and is fully visible after scrolling, then we could change the spec to focus it, and we would not lose the benefit.

But if we focus partially visible things, then we get that problem.

[frivoal]

---

Migrated from WICG/spatial-navigation#56 (comment)
Originally created by @hugoholgersson on Wed, 05 Sep 2018 12:41:30 GMT

---

If spatnav does element.scrollIntoView(alignToTop=true), we're safe?

[frivoal]

---

Migrated from WICG/spatial-navigation#56 (comment)
Originally created by @hugoholgersson on Fri, 07 Sep 2018 13:22:32 GMT

---

But if the first step immediately focused that big button and brought it into view, then part of the text would be skipped, and never readable to the user.

I agree. That's a problem of seqnav...

With spatnav however, can that happen given we do scrolling in line-height:ish big steps?

If it actually can happen... let's make the focus of [scroll + focus] a "non-scrolling focus"?

[frivoal]

---

Migrated from WICG/spatial-navigation#56 (comment)
Originally created by @hugoholgersson on Tue, 04 Sep 2018 15:12:03 GMT

---

snav-stay-in-overflow-div.html shows that sequential navigation, at least in Chrome and Firefox, also does [scroll + focus], when a focusable is entirely revealed by the scroll step.

I am less sure when only part of it would be visible ...

What does sequential navigation do in this case?

[frivoal]

---

Migrated from WICG/spatial-navigation#56 (comment)
Originally created by @frivoal on Thu, 21 Jun 2018 08:06:50 GMT

---

If the focusable element entirely fits within the area that would be revealed by the scrool, then this makes sense to me.

I am less sure when only part of it would be visible, because focusing it would in turn cause a bigger scroll, possibly in some rare cases causing the scroll to be so large that some content that is between the previous focused element and the new one is skipped and unreachable.

[frivoal]

---

Migrated from WICG/spatial-navigation#56 (comment)
Originally created by @frivoal on Wed, 05 Sep 2018 08:12:31 GMT

---

sequential navigation always just focuses things, which can, as a side effect when the thing is hidden, cause scrolling to make it visible. It never does scrolling only, so the question doesn't really arise.

[frivoal]

---

Migrated from WICG/spatial-navigation#56 (comment)
Originally created by @jihyerish on Mon, 30 Apr 2018 05:53:01 GMT

---

In the current spec, one arrow key pressing works for scrolling or moving focus.
That description is in Example 1 of Overview section.

I agree that one keystroke works for [scroll] + [focus] may be better UX, but it depends on the situation.
Do you think that this behavior is better for spatial navigation?

[frivoal]

---

Migrated from WICG/spatial-navigation#56 (comment)
Originally created by @hugoholgersson on Mon, 10 Sep 2018 12:46:35 GMT

---

But not with partially_visible_element_after_scroll.focus({preventScroll:true}) ... right?

[frivoal]

---

Migrated from WICG/spatial-navigation#56 (comment)
Originally created by @frivoal on Fri, 07 Sep 2018 06:58:18 GMT

---

I don't think so. take this case, for example:
http://jsbin.com/xuxesazilu/edit?html,css,output

If you have the first button focused and you're at the top of the scroller, you cannot read the whole text. If you scroll one step down, you reveal the reminder of the text, and the top of the second large button.

If a second step focuses the big button, no problem.

But if the first step immediately focused that big button and brought it into view, then part of the text would be skipped, and never readable to the user.