[css-nav-1] Predefined algorithm for spatial navigation

[jihyerish]

When we first introduced spatial navigation, I also had suggested some features that can customize the default spatial navigation behavior.
One of those was nav-rule which changes the default focus navigation algorithm(or function).

I'd like to bring this up again.
It would be helpful for the author to use the predefined function which is used for deciding what will be the most desirable element to move the focus next among candidate elements.

The distance function for the default spatial navigation behavior in the spec was decided depending on UX test cases.
In certain cases which aren't counted in the test cases, other algorithms suit better than the default.
For example, for the page perfectly filled within a grid layout.
Moving the focus to the closest element only considering the one axis corresponding to navigation direction would be more reasonable. (If the right or left arrow key is pressed, only consider the distance along the x-axis.)
To define the distance function like this is straightforward and it may be used frequently.

Therefore the CSS property which can specify the predefined distance function would be useful.
The author doesn't have to implement such functions.

It would be defined as below:

spatial-navigation-function: normal | grid

• Value:
  • normal: Moves the focus with the default focus navigation algorithm defined by UA
  • grid: Moves the focus to the closest element only considering the one axis which corresponds to the direction of navigation.
• Inherited: Yes

This demo shows how this property works.

[dbaron]

This seems like it could be a reasonable thing to do, but I'm a little concerned about the wording in your description. Saying that you're only considering a single axis seems to imply that distance in the other axis is not considered -- whereas I would think for what you describe you would instead need to penalize distance in the other axis more severely than the current algorithm does, in order to continue moving straight along the desired axis. (Would that happen as a result of changing the orthogonalWeight in the distance function, or something like that?)

[jihyerish]

Oh, my description was ambiguous. The way to calculate the distance for the grid value is different from the distance function in the spec, and it doesn't use the distance function.

For grid value, three factors are considered when we calculate the distance:
(1) The distance along the axis which corresponds to the navigation direction
(2) The amount of alignment
(3) The distance along the axis which is orthogonal to the navigation direction

If there are more than one aligned candidates in the navigation direction:

• Among the aligned candidates, select the best one as a result of the calculation from (1)
• In case of best candidates more than two, select the best one with the minimum (2).

Else if there isn't any aligned candidate in a given direction

• Among other(not aligned) candidates, select the best ones as a result of calculation from (1)
• In case of best candidates more than two, select the best one with the minimum (3).

Therefore, this won't affect the orthogonalWeight in the distance function.

[css-meeting-bot]

The CSS Working Group just discussed Predefined algorithm for spatial navigation, and agreed to the following:

• RESOLVED: Add spatial-navigation-function to the spec

The full IRC log of that discussion

<heycam> Topic: Predefined algorithm for spatial navigation
<heycam> github: https://github.com//issues/3964
<heycam> jihye: in general, the focus move to the closest element from the currently focused element
<heycam> ... and in the spec the algorithm for how to find the closest element, there is a description about that
<TabAtkins> BTW: based on current discussion, I'm editting p-c-s to be "light | dark | bright", dropping the no-preference value (and defining that "light" should be what a lack of preference means).
<heycam> ... but some authors this kind of algorithm it's not suitable for them
<heycam> ... depending on their own layouts
<heycam> ... so there is some spatial nav API to help authors customize this algorithm
<heycam> ... but it's difficult to do this, since they have to interrupt the processing model of spatial nav
<heycam> ... the processing model means finding the best target
<heycam> ... starting from when the user inputs some information, finding the best target -- all that process is called "processing modeL"
<heycam> ... it's hard to interrupt that in the middle
<heycam> ... so it would be nice to have a new CSS property to provide another algorithm for spatial navigation
<heycam> ... this will increase flexibility of spatial navigation, and will help authors to implement it more easily
<heycam> ... I want to propose spatial-navigation-function CSS property, with two values
<heycam> ... normal, where focus will move to the closest one
<heycam> ... and grid, this will go to the most aligned element from the currently focused element
<heycam> ... the focus will go to a more obvious spatial navigation direction
<florian> q+
<heycam> ... there is a demo I attached in the GitHub issue
<Rossen_> Zakim, open queue
<Zakim> ok, Rossen_, the speaker queue is open
<florian> q+
<heycam> ... you can select normal or grid, and see how it works differently
<heycam> demo: https://raw.githack.com/WICG/spatial-navigation/develop/demo/calendar/index.html
<heycam> florian: bikeshedding aside, I'm supportive of having a property to switch how we calculate the distinace, how to pick
<heycam> ... I'm wondering if we have the right values in that list
<heycam> ... if we think we do, and implementors want to experiment with this, sure
<heycam> ... but there are a anumbe rof variants we can think of
<heycam> ... the ones proposed seem reasonable, but are they actually a good match?
<heycam> ... the alternative to normal, is that what authors really want? we're lacking experience
<heycam> ... it's difficult to say "70% of people who have trouble with normal want this grid behavior"
<heycam> jihye: with grid, I'm communicating with framework team in LG. this is their main request from them
<heycam> ... their main implementation is something like TV schedule web page, or TV content
<heycam> ... normally those kinds of pages, elements are grouped horizontall and vertically, so in that case moving the focus just horizontally or vertically is more important than moving to the closest one
<heycam> florian: for that reason, intuiitively the grid behavior makes sense to me
<heycam> ... if you have anecdotal evidence that authors want this, this is an improvement
<heycam> ... not quite as good as stats over many users but it's a start
<bkardell_> me wonders if he can reserve comments on this until post the next topic
<Rossen_> ack florian
<heycam> heycam: is that sufficient evidence to add it ot the spec?
<heycam> florian: we have some evidence it's wanted, and on the face of it is reasonable, so sure
<heycam> bkardell_: I would like to reserve comments until after the next topic, since they're related
<heycam> Rossen_: any objections to adding this to the spec?
<heycam> RESOLVED: Add spatial-navigation-function to the spec