Add support for CSS reading-flow

[dizhang168]

The CSSWG resolved to add the new CSS property reading-flow: (w3c/csswg-drafts#7387, spec). Chrome has been working on a prototype for how to change the sequential focus navigation order within a container that has reading-flow.
This PR specs the new CSS property reading-flow per proposal described at #10407.

• At least two implementers are interested (and none opposed):
  • Chrome
  • Gecko: CSS reading-flow mozilla/standards-positions#1056
  • WebKit: CSS reading-flow WebKit/standards-positions#378
• Tests are written and can be reviewed and commented upon at:
  • wpt/focus-navigation/reading-flow/tentative
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/40932006
  • Gecko: TBA
  • WebKit: TBA
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/index.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )
/rendering.html ( diff )

[domfarolino]

By the way, in the OP you have "At least two implementers are interested (and none opposed):" checked, but neither of the two linked standards positions have been resolved yet, so I'd uncheck that unless you you have other cross-browser support to point to.

[dizhang168]

Thanks for the first pass!

By the way, in the OP you have "At least two implementers are interested (and none opposed):" checked, but neither of the two linked standards positions have been resolved yet, so I'd uncheck that unless you you have other cross-browser support to point to.

Thanks for the call out. There has been conversation in meetings and implementers from non-chromium browsers are interested and none opposed. But I will wait for their comments on the official position issues before checking the checkbox.

[domfarolino]

I'm a little worried about using "tabindex-ordered focus navigation scope" here, instead of "flattened tabindex-ordered focus navigation scope". Do we know that this is the right choice?

The terms differ in two ways:

1. "tabindex-ordered focus navigation scope" may contain non-focusable items, which the "flattened tabindex-ordered focus navigation scope" weeds out. I know we only care specifically about the "reading flow items" inside the "reading-flow focus navigation scope", but can any of these "reading flow items" be non-focusable? If so, then I think the https://whatpr.org/html/10613/interaction.html#reading-flow-sequential-navigation-search-algorithm steps could return a non-focusable item which is broken.
2. The other obvious distinction between the flattened and non-flattened variants is the recursive flattening. Do we really not want the recursive flattening property for reading flow, when selecting the next reading flow items to focus?

[dizhang168]

The focus scope finds the next (or previous) element to visit and returns it. Then, we checks for two conditions:

• Whether this element is focusable
• Whether it has the correct tabindex value (the next element with tabindex value greater or equal).

I believe we should not use "flattened tabindex-ordered focus navigation scope" because this traversal needs to reach all elements and then do the filtering above. For example, display: contents elements are most often not focusable, yet they must be returned by the algorithm.

[domfarolino]

This comment is related to the one above about whether "reading-flow focus navigation scope" should be an unflattened tabindex-ordered list, or a flattened one. If it should be flattened (which feels a little more right to me), then I think we can:

• Use the condition "selection mechanism is sequential" instead of "starting point is in a reading-flow focus navigation scope". This is because we know starting point belongs to its document's sequential focus navigation order;
• Which means we can just pass in "starting point's Document's sequential focus navigation order" to the reading flow search algorithm, as the reading flow focus navigation scope parameter.

[dizhang168]

Status update: I have addressed all the formatting comments. @domfarolino and other reviewers proposed more suggestions and changes at TPAC 2024. I will go back to working on the proposal before making more changes to this spec PR.