[css-display-4] `reading-flow` HTML integration tracking issue

[fantasai]

The reading-flow property integrates with HTML features and algorithms, opening this issue to track this. See discussion:

• about tabindex specifically at tabindex vs reading-flow property whatwg/html#10642
• PR for integration at Add support for CSS reading-flow whatwg/html#10613

[css-meeting-bot]

The CSS Working Group just discussed [css-display-4] `reading-flow` HTML integration tracking issue.

The full IRC log of that discussion

<masonf> Di: we discussed this at the last joint meeting, but I think we didn't finish the conversation.
<dbaron> i/do you wnat/for full minutes, since start was missed, see https://github.com//issues/10857#issuecomment-2554873900/
<masonf> Di: question is "what is the stability of the feature on the CSS side"
<dbaron> i/for full minutes/Topic: [css-ui] UA stylesheet for appearance:base `<select>`/
<masonf> Di: Elika said there might be changes to the format, etc. Curious what we still need to resolve
<masonf> fantasai: there are a few significant issues. One is interaction with dense packing and masonry layout - that needs work.
<masonf> fantasai: discussion about initial value handle dense packing without requiring author to do anything. There's no value that is designed for masonry, need to add something.
<masonf> fantasai: masonry stuff might want to be on by default.
<masonf> fantasai: if any of this is on by default, that kind of makes it intractable to have the impact that we're proposing on ordering that isn't currently the default, and would need to be on by default.
<masonf> fantasai: in summary, what is the default behavior. Also feature needs more work for masonry, which might affect syntax and keywords.
<masonf> And reading-flow property works fine if container is unordered list of uniform items, but if container is unordered, but some things are in particular order.
<masonf> fantasai: example: demo for masonry, first item in layout was a side-bar with nav stuff, and rest of items in the list were pictures.
<masonf> fantasai: because the side-bar was placed on the right side, using any reading-flow values to scan the rows in visual order would place the side-bar as the 5th item, but it needs to be first. I don't think the current design of reading-flow handles that.
<masonf> fantasai: maybe there's another property or something, but we need to figure out that use case.
<masonf> Di: ok, makes sense, thanks for the details.
<masonf> Di: for masonry, we didn't include that because it doesn't exist yet. We need to do that, but it shouldn't be blocking for this yet.
<fantasai> masonry demo with righthand sidebar -> https://webkit.org/demos/grid3/museum/
<masonf> Di: for second point, special case for some ordered and some unordered, current design indeed doesn't allow that.
<masonf> Di: design visits in visual order, there's an assumption that we're e.g. going left-to-right. Needs help from CSS.
<masonf> fantasai: masonry is an additional thing, yes, but once we figure out how to make that work, it might cause us to rethink how it currently has.
<masonf> fantasai: reading-flow might need changes. We might only add values, but we might change the initial value, or even change all values to make them more coherent with everything included.
<masonf> fantasai: we need at least an idea about how to handle these use cases.
<masonf> fantasai: is this a subset? Or is this not developed enough. If the former, we're ok. But we might be in the latter case.
<masonf> Di: I agree, and maybe we can get these exact issues get Agenda+'d at CSSWG to work on them?
<masonf> Di: my one question is that while we might make changes, but would it be reasonable to keep progressing on HTML side?
<masonf> Di: HTML spec doesn't really depend on these specifics from CSSWG.
<masonf> Di: HTML talks about tabindex, and how to visit things, and not really the order of items provided by CSS spec.
<masonf> fantasai: I agree, keeping this loosely coupled, so CSS defines the order, and HTML doesn't hook into specific values.
<masonf> fantasai: if you do any re-ordering, if non-initial value, then you're re-ordering. Then you opt into different behavior, even if order of the items hasn't changed.
<masonf> fantasai: if initial value of property performs re-ordering, then what happens? We might want to automatically opt in to dense packing, for example.
<masonf> fantasai: we can consider it, we haven't made that decision. Maybe impact on tabindex and HTML, etc. is the reason we can't do the smart thing by default. But if we want to, every element that uses grid or masonry would change.
<masonf> fantasai: if initial value does re-ordering by default, is that ok?
<masonf> q?
<masonf> annevk: from the HTML side, about de-coupling. That's not something we do for HTML standard changes. We want all changes in the standard to be ready end-to-end, and be testable, and have WPTs.
<masonf> annevk: if the CSS spec isn't ready, then we can't write tests, etc.
<masonf> annevk: we wouldn't want to change those algorithms.
<masonf> fantasai: but we can continue to work on the PRs and fix issues, etc.
<masonf> annevk: ok to have the PR, but we can't merge it. That's why I added do-not-merge.
<masonf> annevk: that doesn't mean "stop working", it just means we need the dependencies done.
<masonf> past: does that mean HTML reviews can keep going
<masonf> domfarolino: we can keep going, and get right up to the "ready to merge" state for now. All that stops is when we can merge it.
<masonf> past: do we want to dive into the three issues brought up by fantasai?
<fantasai> sidebar issue -> https://github.com//issues/11208
<masonf> fantasai: side-bar issue is raised. I think there's one for masonry.
<fantasai> masonry reading order top-level issue -> https://github.com//issues/5675
<masonf> Di: maybe better to discuss soon, but not today, because I'm not as familiar yet, and it'll be helpful to have Tab and Rachel help with the design.
<masonf> fantasai: needs design work, which should happen in CSSWG. Give it a few weeks, perhaps at F2F in January.
<masonf> fantasai: by then we should have a better idea of the direction.
<masonf> Di: it's unfortunate (but understandable) that we need to stop on progress in HTML. Especially with PR open since Sept. But hopefully we can make good progress.
<masonf> domfarolino: is there a design opportunity before the F2F?
<masonf> fantasai: I think the complexity of what we need to solve - it'll help to have the bandwidth of a F2F. It's a design exercise.
<masonf> fantasai: we need to make sure it's easy, coherent, etc. If it was tweaks, we could handle it async.
<masonf> fantasai: just afraid that we adopt it too early and then find problems.
<masonf> past: also end of year holiday time, etc.
<masonf> masonf: maybe keep going on HTML PR
<masonf> Di: HTML PR is looking good. Getting positions from Mozilla and WebKit is blocking - perhaps we could get that?
<masonf> Di: would be good to get the position issues updated and list what is still unclear.
<masonf> domfarolino: we agree on the problem space enough to be thinking about future things. Perhaps that's supportive.
<masonf> fantasai: We think something like this is needed, but we're just unclear on the details.
<masonf> domfarolino: is that a formal positive signal? We're discussing stage 2/3 questions, it sounds like. Just checking my calibration.
<masonf> annevk: this is a problem that fantasai wants to solve, we're just not sure about specifics. We like to take a position when we're fully sure about most of the details. Not quite there yet.
<masonf> smaug: it wouldn't make sense to land the PR on HTML.
<fantasai> s/fantasai/WebKit/
<masonf> domfarolino: just talking about standards positions, not "do not merge"
<masonf> annevk: tests need to be updated, etc.
<masonf> domfarolino: sounds like webkit standards position is somewhere between stage 2 and 3, is that right?
<masonf> annevk: that's reasonable
<masonf> annevk: we've thought about splitting standards positions. We prefer not to have a position until we're completely sure about something.
<masonf> fantasai: we need to split them. We have "proposal is generally good" but also "we support working on this but not sure on details yet".
<fantasai> s/sure/satisfied/
<masonf> domfarolino: that's what I thought stages were for
<masonf> annevk: we're not using stages for this one, are we?
<masonf> domfarolino: no I guess not. But we could
<fantasai> s/split them/split them; it's confusing everyone right now/
<masonf> past: smaug, similar position?
<masonf> smaug: people interpret standards positions in a particular way, so we need to be very explicit.
<masonf> fantasai: we need to distinguish
<masonf> fantasai: we need to do a good job. If we don't specify, it gives anxiety about shipping.
<fantasai> s/about shipping/to people working on a proposal/
<fantasai> s/we need to do a good job/If we can say that we are supportive of ppl working on the problem and further developing the proposal, that encourages those working on it to keep working and engaging./
<masonf> masonf: I'll open an issue to add a checkbox for "reached stage 3" as an alternative to the standards positions checkboxes
<masonf> past: if I understand the concern, it's that people take the standards positions and then ship, regardless of the spec maturity.
<fantasai> fantasai^: But if we only say "we're supportive", it gets interpreted as "great, they love it, let's ship it!"
<masonf> annevk: in the past, there have been things that look like a great idea, and didn't mention caveats. Then it goes out the door and it wasn't quite ready, or we didn't have a chance to review yet.
<masonf> fantasai: example: anchor positioning. Supportive of Google working on the proposal, but we felt there needed to be significant changes before it adhered to CSS design principles. We did eventually get there. But saying we were supportive, but not yet clear on all details. It'd be helpful to be able to distinguish.
<masonf> past: we need a way to distinguish that. Sounds like we have a path in WHATWG. Perhaps we need something similar in CSSWG?
<masonf> annevk: we could probably add more comments on standards positions on what we're leaning toward.
<masonf> past: the labels are one thing, which are strong, but comments that convey the nuance would be very helpful.
<fantasai> "Supportive of progress in this direction" vs "Supportive of this specific proposal"
<masonf> domfarolino: from WHATWG it feels weird to have standards positions and also stages.
<masonf> annevk: to be clear, you need implementer interest, you don't need standards positions.
<masonf> annevk: if you ask about opinions, you might get an informal response.
<masonf> annevk: for WHATWG changes, I just check with people on IRC/matrix.
<masonf> smaug: one issue is that stages aren't very clear. Still figuring that out.
<masonf> past: I'd suggest more feedback on the issue I've raised about that.
<masonf> domfarolino: can someone link, on the reading-flow HTML PR, what we're blocked on at this point.
<masonf> domfarolino: lots of discussion about "it's not stable" and I don't know what that means. So a summary would be very helpful about what's outstanding on the CSSWG side.
<masonf> Di: yep, will do
<masonf> past: some issues not yet filed
<masonf> fantasai: a couple are filed, but I'll break it down into more pieces
<annevk> I guess we can just look at https://github.com/w3c/csswg-drafts/labels/css-display-4 and filter for reading-flow?

[dizhang168]

During the joint meeting, @fantasai mentioned 3 issues they would like to address for this feature:

• 11396: Initial value of reading-flow for dense packing
• 5675: Masonry layout in CSS Grid 3 has potential to cause accessibility problems with reading order
• 11208: reading-flow and mix of auto-flow and explicit items

[dizhang168]

After the meeting, we read through these issues, and upon further reflection, we don’t agree these are blocking issues for a first MVP version of reading-flow (defined in Display Level 4). They are either about the new and in-progress Masonry feature or about adding new CSS properties to complement reading-flow. We believe these can be handled as incremental improvements to the CSS reading-flow property, in particular because the Masonry layout mode is still in the Design/Implementation phase and should not be a blocker. For example, it seems natural to add something like reading-flow: masonry-order or similar, which would not affect existing values or behavior. We feel that reading-flow is a valuable feature, and we are anxious to make it a reality.

Having said that, we are happy to collaborate on potential solutions for these use cases ahead of upcoming CSSWG meetings and at the F2F. @rachelandrew has offered to help as well. We are hopeful that these issues can be discussed at length at the upcoming CSSWG F2F and get resolved. We will comment with proposals over the coming weeks.