[css-nav-1] Tweak the distance function to prioritize elements that are aligned

[frivoal]

---

Migrated from WICG/spatial-navigation#122
Originally created by @frivoal on Wed, 17 Oct 2018 05:33:36 GMT

---

The current distance function behaves somewhat strangely, mostly due to:

• measuring edge to edge, which does not help decide which element to go to when two targets are at the same distance from the source's edge, even if one is fully in aligned, and the other is not
• The B factor in the formula penalizes elements which are aligned, in a way that is not fully compensated by C. Both in combination seem to favor elements at 0 or 90 degrees over those at 45 degrees, which does not seem justified.

We should:

• Switch from measuring from edge to edge to measuring from center to edge
• Drop the B factor, and possibly the C factor as well.

[frivoal]

---

Migrated from WICG/spatial-navigation#122 (comment)
Originally created by @cynthia on Mon, 12 Nov 2018 06:16:06 GMT

---

Probably an edge case worth noting that a horizontally equally sized multiple fragment would need to be handled by using the centroid of the vertical extremas.

[frivoal]

---

Migrated from WICG/spatial-navigation#122 (comment)
Originally created by @jihyerish on Fri, 09 Nov 2018 04:58:48 GMT

---

@hugoholgersson
Yes, I agree with you. Measuring the distance depending on the centroid can achieve the more precise result.

I've been also considering the case that you described above.
To cover this case, the span element is considered as the two fragments.
So inside the element's border box, the closest fragment from the edge which is on the direction of the navigation will be selected to use for calculating the distance.

In your example, if the user presses the down arrow key, from the "XXXXXXX" fragment in the second line the distance value will be calculated.

[frivoal]

---

Migrated from WICG/spatial-navigation#122 (comment)
Originally created by @hugoholgersson on Wed, 17 Oct 2018 07:25:51 GMT

---

Switch from measuring from edge to edge to measuring from center to edge.

We risk a "dead end" when a smaller focusable A sits centered, on top (z-wise) of a bigger focusable B, A->B->A->B->A ... ?

[frivoal]

---

Migrated from WICG/spatial-navigation#122 (comment)
Originally created by @cynthia on Thu, 25 Oct 2018 13:36:30 GMT

---

I've tried a quick and dirty prototype that computes the delta between the desired direction's reference angle and the angle between the currently focused element's centroid and the candidate element's centroid with an arctangent2, and it seems to improve performance a bit. @jihyerish knows how the strawman algorithm works, but the weights and magnitude have to be scaled to match the other ABCD scores in the distance computation phase.

Whether or not you factor this in is entirely up to you, but it seems to help.

[frivoal]

---

Migrated from WICG/spatial-navigation#122 (comment)
Originally created by @hugoholgersson on Mon, 12 Nov 2018 14:37:07 GMT

---

@cynthia could you give an ASCII example? (How do you define "vertical extremas"?)

I can imagine one case where a focusable, C, becomes unreachable (?) when going up/down between A and B:

BBBBBBBBBB
.........B
.....CC...
.........A
AAAAAAAAAA

[frivoal]

---

Migrated from WICG/spatial-navigation#122 (comment)
Originally created by @hugoholgersson on Fri, 09 Nov 2018 11:16:31 GMT

---

Taking the centroid of that fragment, you mean?

[frivoal]

---

Migrated from WICG/spatial-navigation#122 (comment)
Originally created by @jihyerish on Mon, 12 Nov 2018 00:49:33 GMT

---

@hugoholgersson Yes. Because of that, it needs to be defined which fragment to take depending on the input direction.

[frivoal]

---

Migrated from WICG/spatial-navigation#122 (comment)
Originally created by @hugoholgersson on Thu, 08 Nov 2018 10:23:15 GMT

---

I also like the idea of calculating the distances between elements' centroids. But how do we define the centroid of inline elements that span a line break (i.e non-rectangular elements)?

  ..................XXXX
  XXXXXXXX..............

[jihyerish]

---

Migrated from WICG/spatial-navigation#122 (comment)
Originally created by @jihyerish

---

@hugoholgersson
Yes, I agree with you. Measuring the distance depending on the centroid can achieve the more precise result.

I've been also considering the case that you described above.
To cover this case, the span element is considered as the two fragments.
So inside the element's border box, the closest fragment from the edge which is on the direction of the navigation will be selected to use for calculating the distance.

In your example, if the user presses the down arrow key, from the "XXXXXXX" fragment in the second line the distance value will be calculated.

[jihyerish]

While investigating how to improve the distance formula in the spec, I noticed that prioritizing elements that are with the currently focused element can be solved by removing the B factor of the formula.

But there still remains ambiguity when there are more than one aligned elements with the currently focused element.
For example, please see this sample.

Therefore, to solve this problem, I'd like to suggest adding a new factor for calculating the degree of alignment between a candidate and the search origin.

The factor is calculated as

Factor = degree of alignment * alignWeight

degree of alignment = (length of the edge of the area of intersection between a candidate and the search origin / length of the edge of the search origin)

See more information in here.

For overall improvement of the distance formula, I suggest the changes in the issue #3384.