-
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. |
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.
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 HTML spec shouldn't be written in a way that depends on specific CSS properties, because these can change--we shouldn't need to change the HTML spec to change how CSS calculates the reading order.
HTML should use a generic concept of a "rendering-defined sibling reading order" or something like that, which both specs can refer to. Then CSS can say how that order is calculated, and HTML can say how it interacts with HTML features and algorithms.
There have been multiple different proposals for how CSS calculates reading order, only some of which depend on values of reading-flow
. For example, we have discussed a property on the items (reading-order
), a property on the container (reading-flow
), a variety of different types of values for each, and the possibility of even changing behavior for effects like dense
packing to perform layout-based reordering by default (no specific property). All of this is out of scope for the HTML spec, and shouldn't be locked down into it as if it were the defining spec for these features.
Thanks for the feedback. I will update this spec to remove any specific CSS properties and instead refer to CSS Display 4 for rendering-defined sibling reading order and reading flow container. Next, I will refactor this PR accordingly to have only the reading flow order in the context of a focus navigation scope and illustrate the steps with a detailed example. |
I have updated the PR with a thorough example for the reading flow order algorithm without referring directly to any 'reading-flow' property. Would appreciate your review, thanks. Note: I am working with @rachelandrew to update the definitions in css-display-4. |
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 think this is looking good, % some comments about the example which I think could be cleared up.
Besides that, I was thinking more about how a "reading-flow-ordered focus navigation scope" is-a "tabindex-ordered focus navigation scope" but without the tabindex-ordering that it calls for. I tried to clarify this in a small commit that mentioned "by default" the odering of a "tabindex-ordered focus navigation scope" is tabindex-based, unless the ordering criteria is overridden, as it is with the reading-flow variant. But I almost wonder if we should go a step further and literally rename both:
- "tabindex-ordered focus navigation scope" -> "ordered focus navigation scope"
- "flattened tabindex-ordered focus navigation scope" -> "flattened ordered navigation scope"
... and continue to do what I did in 512e4fb, by making the "default" ordering of these tabindex-based, but allowing for the ordering to be overridden as we do in the reading flow variant.
@annevk what do you think about this naming question?
|
||
</div> | ||
|
||
</div> |
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.
Is this extra?
<p><img src="/images/reading-flow-order-example.svg" width="500" height="350" alt="" | ||
class="darkmode-aware"></p> | ||
|
||
<p>For a reading-flow-ordered focus navigation scope where wrapper is the focus scope owner:</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.
A few things for below:
- Please link to every definition you can. Things like "reading-flow ordered focus navigation scope", "rendering-defined sibling reading flow", and more, just like you were writing a non-example algorithm.
- Use
<var>
when referring to all variables, just like you would in a non-example algorithm. - When referring to nodes in the DOM outside of the actual example HTML code, use
<code data-x="">wrapper</code>
, like we do in https://html.spec.whatwg.org/#script-processing-model:html-element-post-connection-steps-5 etc. - Use the (unfortunate)
« »
syntax for beginning/end list brackets, instead of[ ]
. - Some of the "algorithms" below don't appear to be real algorithms. I'd write them a bit more descriptively. For example, instead of saying
Let <var>output</var> be « ».
, which is obvious since that's the first line of the#reading-flow-order
algorithm anyways, I would start with a paragraph telling you first what the reading flow order ofwrapper
is, and then describe (in list form maybe—I'm not saying anything is wrong with that) exactly how you get it. What you have is pretty close!
|
||
<li> | ||
<p><span data-x="list iterate">For each</span> <var>child</var> of <var>owner</var> element's | ||
children:</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.
Link to the DOM definition of an element's children here.
<var>output</var>.</p></li> | ||
|
||
<li><p><span>Break</span>.</p></li> | ||
</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.
I'd add a note below this </ol>
mentioning what exactly this condition is trying to accomplish, because it's not clear just from reading it why it does what it does.
<li><p>Let <var>container</var> be the <span>reading flow container</span> associated with | ||
<var>owner</var>.</p></li> | ||
|
||
<li><p>Let <var>items</var> be the <span>rendering-defined sibling reading flow</span> of |
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.
So this can include descendants of <var>container</var>
that are not direct DOM children of container, right? I guess that's the only reason we have to have a while loop that goes upward arbitrarily?
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 would like to discuss this one more time briefly during the CSS + WHATWG call. In particular to better understand the stability of this feature on the CSS side.
<p>The order within a <span>tabindex-ordered focus navigation scope</span> is determined by each | ||
element's <span>tabindex value</span>, as described in the section below.</p> | ||
<p>By default, the order within a <span>tabindex-ordered focus navigation scope</span> is | ||
determined by each of its element's <span>tabindex value</span>. This ordering criteria 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.
determined by each of its element's <span>tabindex value</span>. This ordering criteria is | |
determined by each element's <span>tabindex value</span>. This ordering criteria is |
Or you would have to pluralize element.
<p>A <dfn>reading-flow-ordered scope owner</dfn> is either: <ref>CSSDISPLAY</ref></p> | ||
|
||
<ul> | ||
<li><p>a <span>reading flow container</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.
<li><p>a <span>reading flow container</span>.</p></li> | |
<li><p>a <span>reading flow container</span>, or</p></li> |
(otherwise the lowercase starting letters don't make sense)
<p>A <dfn>reading flow item</dfn> is an element whose <span>parent element</span> is a | ||
<span>reading-flow-ordered scope owner</span>.</p> | ||
|
||
<p>The <dfn>reading flow order</dfn> of a <span>reading-flow-ordered focus navigation scope</span> <var>scope</var> is the ordered list of elements constructed as follows:</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.
This looks like it needs some wrapping (100 columns max and on spaces only).
<p>The <dfn>reading flow order</dfn> of a <span>reading-flow-ordered focus navigation scope</span> <var>scope</var> is the ordered list of elements constructed as follows:</p> | ||
|
||
<ol> | ||
<li><p>Let <var>output</var> be an empty <span>list</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.
<li><p>Let <var>output</var> be an empty <span>list</span>.</p></li> | |
<li><p>Let <var>output</var> be « ».</p></li> |
</li> | ||
|
||
<li><p>Return <var>output</var>.</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.
This newline can be removed.
</ol> | ||
|
||
<div class="example"> | ||
|
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 newline can be removed.
|
||
<p>Combining everything together, the flattened tabindex-ordered focus navigation scope is: | ||
[Wrapper, A, B, DC, F, C, E, D, H, PA, G].</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.
This newline can be removed.
</div> | ||
|
||
<div w-nodev> |
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.
These two can coalesce?
@domfarolino I would like at blame to see who introduced the naming and ask advice from them. I don't have a good intuition as to what's best here. |
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 )