Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-nav-1] Searching within element can cause unintuitive behavior. #3989

Open
bokand opened this issue May 30, 2019 · 3 comments
Open

[css-nav-1] Searching within element can cause unintuitive behavior. #3989

bokand opened this issue May 30, 2019 · 3 comments
Assignees

Comments

@bokand
Copy link
Contributor

bokand commented May 30, 2019

Sorry, I can't find where in the spec is responsible but this pertains to changes landed in Chrome in https://chromium-review.googlesource.com/c/chromium/src/+/1587559

(This change JunHo mentioned on the review this change conforms to the spec)

However, this can lead to issues when clickable items are contained inside other clickable items. For example, it's a common pattern to do something like this:

<a>
<button>Menu Item</button>
</a>

Both the and the are considered for Spat Nav but they're the same size. The practical effect is that it requires multiple navigations to move between menu items. e.g. See https://m.youtube.com/watch?v=eKhv9CnA6A0 using mobile emulation.

Another pattern I'm told is common is to wrap a common action in an ancestor click handler:

<a onclick="dismissPopup();">
<button>Confirm</button>
<button>Cancel</button>
</a>

This leads navigation to select an invisible wrapper around both buttons which looks awkward.

Not sure how much we can do about the latter in particular but we may want to investigate some heuristics to prevent, e.g. selecting multiple candidates that overlap almost exactly.

@jihyerish jihyerish self-assigned this May 30, 2019
@jihyerish
Copy link
Contributor

Defining the focusable element which contains another focusable element as a spatial navigation container by default could be the solution for this.
Then the focus can move inside the element and the focusable elements inside it can be reachable.

FYI, in the current spec, spatial-navigation-contain: contain has to be specified if the element needs to work as a container.
We can skip this step exceptional for this case.

@bokand
Copy link
Contributor Author

bokand commented Jun 4, 2019

Does spatial-navigation-contain: contain prevent navigation to the container itself? Based on my reading of the navigation algorithm, it seems like we'd still navigate first to the container, than to its inner element.

@jihyerish
Copy link
Contributor

Yeah, it doesn't prevent navigation. But if we want to solve the issue of unreachability first, this could be a solution.
On top of that, there is a proposal for "focus delegation".
If we combining these two approaches, it may solve this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants