-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for CSS reading-flow #10613
base: main
Are you sure you want to change the base?
Conversation
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 first pass!
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. |
source
Outdated
data-x="reading-flow-item">reading flow item</span> that is not a <span | ||
data-x="non-participating-reading-flow-item">non-participating reading flow item</span>.</p> | ||
|
||
<p>A <dfn>reading-flow focus navigation scope</dfn> is the <span>tabindex-ordered focus navigation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
- "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.
- 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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
source
Outdated
<li> | ||
<p>If <var>candidate</var> is a <span data-x="reading-flow-item">reading flow item</span> or | ||
null, <var>direction</var> is <i>forward</i>, and <var>starting point</var> is in a | ||
<span>reading-flow focus navigation scope</span> <var>scope</var>, then let <var>new |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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. |
8a1ee6d
to
93ec208
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for writing this! It looks quite clear. One thing I'm missing from the surrounding discussion we had are the examples. I thought those would be added to the specification in some fashion.
<p>A <dfn>reading flow container</dfn> is either: <ref>CSSDISPLAY</ref></p> | ||
|
||
<ul> | ||
<li><p>a <dfn data-x-href="https://drafts.csswg.org/css-flexbox-1/#flex-container">flex |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: single-space indentation.
<ul> | ||
<li><p>a <dfn data-x-href="https://drafts.csswg.org/css-flexbox-1/#flex-container">flex | ||
container</dfn> that has the <span>'reading-flow'</span> CSS property set to | ||
<span>'flex-visual'</span> or <span>'flex-flow'</span>.</p></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: if these end in a dot, we should start with an uppercase letter.
element</span> is a <span>reading flow container scope owner</span>.</p> | ||
|
||
<p>A <dfn data-x="non-participating-reading-flow-item">non-participating reading flow item</dfn> is | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spurious newline.
determined by the scope owner's computed value of the <span>'reading-flow'</span> property: | ||
|
||
<ul> | ||
<li><p>For <span>'flex-visual'</span>: follows the order defined by sorting the <span |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: single-space indentation.
data-x="reading-flow-item">reading flow item</span> that is not a <span | ||
data-x="non-participating-reading-flow-item">non-participating reading flow item</span>.</p> | ||
|
||
The <dfn>reading flow order</dfn> for a <span>reading-flow-ordered focus navigation scope</span> is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing <p>
<p>If <var>starting point</var> is a <span data-x="reading-flow-item">reading flow item</span> | ||
in a <span>reading-flow-ordered focus navigation scope</span> <var>scope</var>, then:</p> | ||
|
||
<ol> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This <ol>
should not be further indented than the <p>
above.
@@ -80691,6 +80787,23 @@ dictionary <dfn dictionary>ToggleEventInit</dfn> : <span>EventInit</span> { | |||
focusable</span>.</p> | |||
</li> | |||
|
|||
<li> | |||
<p>If <var>starting point</var> is a <span data-x="reading-flow-item">reading flow item</span> | |||
in a <span>reading-flow-ordered focus navigation scope</span> <var>scope</var>, then:</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for "then" if an if statement is followed by a nested set of steps.
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.
(See WHATWG Working Mode: Changes for more details.)
/index.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )
/rendering.html ( diff )