[css-nav-1] Revise selecting best candidate policy

[frivoal]

---

Migrated from WICG/spatial-navigation#94
Originally created by @junhoseo on Mon, 20 Aug 2018 01:57:40 GMT

---

Currently we consider distance and order in DOM structure. But sometimes these are not sufficient for reasonable choice.

Case 1:

In above case, distance with active element is same each other. So blue element will be selected if it is earlier element in DOM tree, and yellow element will be selected on the contrary.

Case 2:

Sometimes a focusable element can be placed inside another focusable element. In this case, should we allow focus moving to opposite element? Opposite element is not placed in direction, but partially.

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @junhoseo on Thu, 27 Sep 2018 08:28:51 GMT

---

For case #2, and minimizing unreachable case, I suggest an additional step 'internal search' in processing model. Let's see following scenario.

In this scenario, currently red color element is active element. 3 elements are children of a container element(blue color). Meanwhile, there is green element and it is (visually) inside active element. And let it is not child of the container. Usually, such green element never gets focus because it is encapsulated(In this scenario, green element can get focus through yellow element. But it is introduced to show an important case.). And we hit down key.

For now, let's see how 'internal search' step works.

In internal search step, valid rectangle is defined. It is rectangle of active element, and limits focus candidate. Also we define starting point as edge of active element. In this scenario, only green element is candidate for getting focus in internal search step.

Important different point between internal search for active element and finding in container is, in case of internal search, candidate should be 'fully' inside of valid rect. But, in case of finding in container, partially visible element can be candidate. This is why yellow element can't be candidate.

I think we can integrate this step with existing processing model.

For each container from active element's nearest container to root container
    if internal search step finds a candidate
        stop loop

    if normal step finds a candidate or scroll
        stop loop

So, let's see, how integrated processing model works.
In first iteration, container is blue element. In this iteration, we can't any candidate(or scroll) in neither internal search step nor normal step.
In second iteration, container is root element. In this iteration, green element can be candidate in internal search step. So we give focus to the candidate and stop loop.

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @frivoal on Wed, 17 Oct 2018 05:34:33 GMT

---

I think there are several issues being discussed at the same time in this one. Separating them into sub topics:

• case 1 form [css-nav-1] Revise selecting best candidate policy WICG/spatial-navigation#94 (comment) is now here: Change from DOM order to some other criteria when the boxes are at the same distance WICG/spatial-navigation#121

• Prioritizing fully or mostly aligned elements is now here: [css-nav-1] Tweak the distance function to prioritize elements that are aligned WICG/spatial-navigation#122

As for the rest, which I think is best described in WICG/spatial-navigation#94 (comment), I think I was actually confused when I said I agreed. In WICG/spatial-navigation#94 (comment), if the green box is in the same container as the other boxes, the specification already handles that. However, if it is not in the same container, then it seems that skipping it is a feature, not a bug. That is what containers are for. If that's not desired, then making the "blue" box in that example a container seems like a mistake.

Is there any situation where we would want the blue box to be a container, but still go from red to green?

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @junhoseo on Fri, 28 Sep 2018 02:23:22 GMT

---

The problem is that spatnav only looks outside of activeElement's visual box, right?

Yes. Spatnav looks outside of activeElement, also looks partially insersecting element. But never looks inside element.

Perhaps this is all we need to do (no need for an extra "internal" step)?
I wonder if we ever need to use the complete "focus box".... Perhaps edges as search origin give good enough approximations for most (all?) distance calculations?

I think using edge as search origin in common cases can minimize unreachable problem. But it maybe reduce intuitiveness. For example, in above scenario, left(apricot? color) and right(yellow color) can be candidate when we hit down key. It looks like such elements are not placed in direction. Of course, it depends on the person. What do you think?

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @junhoseo on Fri, 28 Sep 2018 08:07:23 GMT

---

:)
OK. So this is more harder example :) :) :)

Focusable elements are placed as grid. And red color element is active element.
We hit down key again.

I think most people expect yellow element will get focus. But actually, green element will get focus because it is placed in direction and closest element with red element. How we can resolve this problem when we use active element's edge as starting point in common cases?

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @hugoholgersson on Thu, 27 Sep 2018 18:00:08 GMT

---

Usually, such green element never gets focus because it is encapsulated

The problem is that spatnav only looks outside of activeElement's visual box, right?

Also we define starting point as edge of active element.

Perhaps this is all we need to do (no need for an extra "internal" step)?

I wonder if we ever need to use the complete "focus box".... Perhaps edges as search origin give good enough approximations for most (all?) distance calculations?

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @hugoholgersson on Fri, 28 Sep 2018 07:18:36 GMT

---

For example, in above scenario, left(apricot? color) and right(yellow color) can be candidate when we hit down key. It looks like such elements are not placed in direction. Of course, it depends on the person. What do you think?

Yes, they can, which is good. All visible focusables in the direction, down, should be considered candidates. The green focusable will anyway win because it's closer to activeElement.

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @jihyerish on Mon, 03 Sep 2018 10:56:58 GMT

---

Case 1.

Yes. The focus will move depending on the DOM order if the candidates have the same distance from the active element.
So far, I think it's a reasonable result. But in some condition, it would be nice to consider the visual inclusion relation among the elements.

Case 2.

In that regard, we need to consider the visual inclusion relation in this case.
If you see the sample below,
https://wicg.github.io/spatial-navigation/demo/sample/heuristic_text_type_elements.html

The content area of the (A)anchor element with "spatial navigation" contains that of the (B)anchor element with "repository".
This causes that the focus cannot move from (A) to (B) nor from (B) to (A).

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @frivoal on Wed, 10 Oct 2018 03:02:04 GMT

---

I think the suggestion in WICG/spatial-navigation#94 (comment) is actually quite good. Should we write it in the spec first, or first try to implement in the polyfill, try it to see if it is nice, and update the spec only if we like it?

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @hugoholgersson on Mon, 01 Oct 2018 09:08:37 GMT

---

I agree. :) I get your point...

One alternative could be to prioritize elements that are fully aligned (i.e. elements that can be [partly] projected onto each other)...?

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @junhoseo on Thu, 18 Oct 2018 10:45:44 GMT

---

I found a case:

Oh, the case is already noticed by @jihyerish at WICG/spatial-navigation#94 (comment) :)

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @frivoal on Wed, 10 Oct 2018 03:04:35 GMT

---

For case 1 in WICG/spatial-navigation#94 (comment), I am much less sure what the order should be if not the DOM. The one most in front? The largest one? The one with the largest visible area? I am not 100% sure how to decide which answer is best.

[frivoal]

---

Migrated from WICG/spatial-navigation#94 (comment)
Originally created by @junhoseo on Thu, 18 Oct 2018 04:57:07 GMT

---

Hi @frivoal,

if the green box is in the same container as the other boxes, the specification already handles that.

Would you please explain how spec handles?

Is there any situation where we would want the blue box to be a container, but still go from red to green?

I found a case:

In above case, a link "arrow keys" is placed in two lines. So the layout box of the element will be red box. Meanwhile, another link "modifier key" is placed in red box. So in this case, we hardly navigate into "modifier key.

[jihyerish]

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 #3386 (comment))

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.

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 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.

@junhoseo, what do you think?

[junhoseo]

Hi @jihyerish ,

As my understand, your suggestion looks similar with previous discussion:
#3386 (comment)

Are there any differences between the discussion and your suggestion?

[jihyerish]

@junhoseo , those aren't different.
My suggestion includes your opinion and I wanted to sum those up!
I think it's a way to resolve this issue in spec point of view.

[jihyerish]

After discussing with @junhoseo, I noticed that the previous suggestion in #3386 (comment) is less convincing because the unnecessary focusable elements are included in the set of the candidate in this way.
In the situation such as below,

when the user presses the down arrow key if A is a focused element, B, C, D, E, F and G are the candidates. But focus moving to B is the rare case and this will confuse the user because B is on the right side rather than the downside.

There are other ways to selecting the candidates and I'd like to suggest it to resolve this issue:

• Set the element as a candidate
  • if it isn't overlapped with the search origin, its rect should be on the navigation direction
  • if it partially overlaps with the search origin, its two edges which are orthogonal to the navigation direction should be on the navigation direction of the respective ones of the search origin
  • if it fully overlaps with the search origin

(This is same with the current implementation in blink)

After selecting the candidates, it selects the best candidate as following:

• If there is any fully overlapped element with the search origin among candidates, measure the inner distance from the search origin to the element to select the best candidate
• Else, use the distance function (https://drafts.csswg.org/css-nav-1/#find-the-shortest-distance) to select the best candidate.

This suggestion seems more reasonable than the previous suggestion and the spec.
Because
(1) There will be no unreachable focusable element
(2) The rule is simple

[junhoseo]

@jihyerish , looks good to me your last suggestion :)
#3386 (comment)
Thanks for your effort!