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

Re: [csswg-drafts] [css-nav-1] Consider candidates on the navigation direction. (#4483)

From: hyojin via GitHub <sysbot+gh@w3.org>
Date: Fri, 08 Nov 2019 04:26:20 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-551379331-1573187179-sysbot+gh@w3.org>
I simplify the problem and propose the candidate solution via the following example.
https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=7345
<img src="https://raw.githubusercontent.com/lgewst/images/master/partially_overlapped_issue.png">

The example above shows the current(As Is) behavior of SpatNav (polyfill and Chromium) as follows:

- As Is: A-B-E (pressing the right arrow key from A to E)
- To Be: A-B-C-D-E (pressing the right arrow key from A to E)

In the figure above, B is considered to be on the right of A, if **the left and right edges** of B are on the right of the respective ones of A as a rule specified in css-nav spec. For partially overlapping elements, D can't be a candidate if users press a right arrow key from B now. The reason is that the right edge of D isn't on the right of the right edge of B.

For securing D's reachability in a right direction from B, Jeonghee would suggest that we could modify the rule to ways only considering **the left edge** on partially overlapping elements when pressing a right arrow key.

It's definitely a heuristic rule that doesn't means a clear solution satisfying all people, but it definitely solves several abnormal behavior(e.g. unreachable element by arrow keys) in several general web sites such as espn.com and naver.com.

-- 
GitHub Notification of comment by anawhj
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4483#issuecomment-551379331 using your GitHub account
Received on Friday, 8 November 2019 04:26:22 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:56 UTC