W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2019

Re: [csswg-drafts] [css-nav-1] Revise selecting best candidate policy (#3386)

From: Jihye Hong via GitHub <sysbot+gh@w3.org>
Date: Thu, 29 Aug 2019 05:48:36 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-526033969-1567057714-sysbot+gh@w3.org>
The remaining issue here is the focusable element inside the search origin(currently focused element) is unreachable via spatial navigation.

This can be divided into two cases:

Case 1.  The search origin is the general focusable element
Case 2.  The search origin generates the fragmented elements
     (Elaborated in https://github.com/w3c/csswg-drafts/issues/3386#issuecomment-443619274)

I think Case 2 is already covered in the spec because the spec mentions that the focus will move to each fragment separately.
(Step 1 in https://drafts.csswg.org/css-nav-1/#find-focusable-areas )

However, Case 1 isn't considered in the current spec.
While selecting the candidate, the focusable elements are filtered if its geometric center is outside of the half-plane whose boundary goes through the geometric center of the search origin and is perpendicular to the navigation direction.

For example, A, B, and C are the focusable elements.
![image](https://user-images.githubusercontent.com/6636090/63909223-d9b79580-ca5c-11e9-966e-687539c69ad2.png)
Let the focus is on the C. If up arrow key is pressed, B isn't selected as a candidate.
Also, even if both A and B are selected as candidates, it's unclear to decide which one will take higher priority because the values of [distance function](https://drafts.csswg.org/css-nav-1/#find-the-shortest-distance) are the same.

Therefore I think the spec should add description such as:
* Select the focusable element as a candidate depending on the edge of element.
   * If the navigation direction is up, the candidate would be the element which bottom edge is on the upper-side of the bottom edge of the search origin.
   * If the navigation direction is right, the candidate would be the element which left edge is on the right side of the left edge of the search origin.
   * Similar rules when the direction is down or left
* If there is any visually full-overlapped element with the search origin, it will take higher priority than the element which is outside of the search origin.

-- 
GitHub Notification of comment by jihyerish
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3386#issuecomment-526033969 using your GitHub account
Received on Thursday, 29 August 2019 05:48:38 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:13 UTC