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

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

[jihyerish]

The issue migration script created some duplicates. #3388 is the same as this one.
So I'll close this issue.