[css-display-4] drafting reading-order-items issue #8589

[rachelandrew]

Work on a draft for the reading-order-items property.

I have:

1. Put order back as in CSS Display 3, as the previous draft changed the order property and this does not.
2. Kept relevant sections from the original reading order draft, including design considerations, as it is still valid with some small updates.
3. Drafted reading-order-items with some examples. Worked examples can be found here.

An initial question, is that there is a section on order and accessibility in the specification. The details there are mostly relevant to order and reading-order-items, should this be updated to include both? (Could be done as a separate PR).

[dizhang168]

So the flex-direction doesn't impact the reading order? In this example, it is reading left to right because English is dir LTR.

[rachelandrew]

that's right, if you wanted to follow the direction you'd use flow.

[tabatkins]

Okay, so the six values are:

normal
normal from-order
flex visual
flex flow
grid rows
grid columns

The descriptions don't say it directly, but flex visual and grid * must incorporate 'order' already. I presume flex flow is intended to as well, and that implies that it's identical to normal from-order on a flexbox, right?

And for grid, hm, normal from-order is potentially different from either grid rows or grid columns. Maybe, then, we can just move the "just pay attention to order" value into grid: remove normal from-order, add grid order?

I'm slightly uncomfortable with normal from-order in any case; it feels like a value that could apply to other layout modes, but this property isn't (currently) designed to apply to anything else, so that'll be a compatibility hazard in the future. Having the value space be purely normal and then obviously layout-specific keywords makes this much safer, imo. We could always add this later, if we find it useful to allow authors to specify.

---

Otherwise, +1 from me

[tabatkins]

Hmmmm tho if we're not allowing the second keyword in flex/grid to be omitted (and I agree that we shouldn't, none of the values are reasonable as a default), we should probably just combine them into a single hyphenated keyword - flex-visual, grid-rows, etc. Unless you believe there's future extension to be done that'll need more control there?

[bradkemper]

I still prefer the syntax I proposed here: #8589 (comment) even if you leave out the part about tables and floats and such (though, like grid, I think it would be very useful with tables especially).

[rachelandrew]

@tabatkins with regard to combined keywords, that's also what fantasai had suggested, and as I wrote this out the separate keywords seemed odd as they have to be used together. I think if they were to be separate we'd need to define a default if someone just used 'grid' for example. So I think hyphenating is likely better. I'll update to that.

Maybe, then, we can just move the "just pay attention to order" value into grid: remove normal from-order, add grid order?

I think the from-order case is if you want everything to be the same as it would be today, so DOM order, but a small tweak to order—for instance moving an item to display first, then auto-placing everything else. But, you get that with grid-rows or grid-columns anyway.

I guess if you were placing all your items, and wanted normal ordering apart from one item with order, that's the only reason for grid-order and I don't think I can come up with a reason for flex-order.

I think you are right that having it separate from the grid and flex entries makes it look like something that could apply to other layout methods.

[rachelandrew]

@bradkemper I find your proposed syntax more confusing. It requires authors to understand what you mean by cross layout in various scenarios, so I feel as if it would be quite difficult to explain. Because of the different way flex and grid layout behave (especially with reverse in flex) I don't think it's easy to have a one size fits all approach. Also, I can see odd things happening if someone were to switch a component from being grid to flex, for example. At least this way, if you are using reading-order-items on a flex layout, which you then updated to use grid, it falls back to DOM order. This is likely to be better than the reading order being reinterpreted for the new layout context in a way that wasn't intended.

[rachelandrew]

@tabatkins updated as per the above discussion.

[bradkemper]

I find your proposed syntax more confusing. It requires authors to understand what you mean by cross layout in various scenarios,

I think that’s easy. Cross axis, cross direction, and cross size are terms used a lot in describing grid and flex-box. Even though we don’t use those terms in the grid spec, it is in the flex spec, the box alignment spec, and I see them in many other CSS Grid related pages on the web.

so I feel as if it would be quite difficult to explain.

In layouts with intersecting rows and columns, it would be the direction perpendicular to the reading direction. In one dimensional layout, cross-layout would just be the same a layout, which would just follow the reading directions. The mental model doesn’t seem difficult to me, or hard to explain.

Because of the different way flex and grid layout behave (especially with reverse in flex) I don't think it's easy to have a one size fits all approach.

I think having six different values is about three values to many. I really don’t see any common use cases for having the row reading order be the reverse of the reading direction. Using row-reverse or column-reverse to affect what goes where doesn’t mean that anyone wants to read a row or column backwards. It means you are arranging things visually so they can be read visually, either with your eyes or by some other means.

So, for example, for flex:

• If using direction: rtl and flex-direction: row-reverse or row, then you are going to either want the items read in DOM order or layout visual order of right to left, with order modified elements included in that visual order.
• If using direction: ltr and flex-direction: row-reverse or row, then you are going to either want the items read in DOM order or layout visual order of left to right, with order modified elements included in that visual order.
• Same idea for grid and table:
  • If your writing-mode is horizontal-tb, then you are going to either want the items read in DOM order, or layout visual order of following the writing direction (horizontally, thus row by row downward), or a cross-layout visual order perpendicular to that, following the block progression direction (thus, column by column, then by writingdirection), with order or explicitly placed elements or flow direction influencing the visual order.
  • If your writing-mode is vertical-* or sideways-*, then you are going to either want the items read in DOM order, or vertical layout visual order (i.e. inline progression direction of top to bottom, then column by column in the block progression direction), or a layout visual order perpendicular to that following the block progression direction (row by row, then proceeding in the inline direction), with order or explicitly placed elements or flow direction influencing the visual order.

Also, I can see odd things happening if someone were to switch a component from being grid to flex, for example. At least this way, if you are using reading-order-items on a flex layout, which you then updated to use grid, it falls back to DOM order.

Yeah, if I specified a visual-based reading order, then DOM order isn’t what I want though. If I had reading-order: visual; display: flex, and then I updated to grid, then I’d still expect it to be read in visual order, which would now still be horizontal ltr for English. It would be with my proposal. Having it switch to DOM order would be exactly what I didn’t want.

If I had flex-direction: column, then reading-order: layout would be read vertically first (top to bottom). Updating to a grid, I would likely use grid-auto-flow: column if I was going for something similar to my flex layout. If I didn’t also update to reading-order: cross-layout, then bad me, but at least the reading order would make more sense to someone with some vision capability than if we fell back to DOM order. (This is presuming DOM order doesn’t match visual order, or else we wouldn’t need any reading order property. )

This is likely to be better than the reading order being reinterpreted for the new layout context in a way that wasn't intended.

Yeah, I totally disagree with that statement. See above.

In any case, there were a couple other parts to my proposal:

1. We should be calling this property reading-order or reading-flow, not reading-order-items. I don’t think we need to repeat the confusion of -items vs. -content and having to remember which one means what. That is, IMO, the worst part of css-align. As long as we are only dealing with the property of the aligning parent, then why make authors write something extra long that doesn’t add anything? And reading-flow is a better choice because it avoids any direct association with the order property, as this does something completely different from that. We resolved against having a separate reading-order property that acted more like order, but the -items suffix seems to be there just in case we later want to bring that idea back. I don’t think that’s a good enough reason to have authors type this extra suffix.
2. Have this new property apply to tables in the same way it applies to grid. They are very similar visually, and the end user doesn’t care what display type was used to achieve the grid of rows and columns they are looking at. It would be weird if you could make the reading order better for grid in rtl or vertical writing, or to be able to read down columns first, but not for table. One type of reading behavior for a visual grid generated one way but not the other means unpredictable behavior for the user.
3. Have this new property affect tabbing order too. I think it would be very strange if it didn’t. Maybe, without a lot of extra work, it could be more of a note than something normative, but surely there is something we could say about it that helps tabbing and reading order work together in an intuitive way. Or maybe that is in there, and I just missed it. But my comments about floats were just about how tabbing between a float and a grid/flex-box/table would integrate with a visual based reading order on that grid/flex-box/table, and not about reading order applying to floats or abs-pos directly.

[rachelandrew]

@bradkemper I think it would definitely be good to raise all of this as separate issues. Can I suggest we do the following:

1. I'll add into this draft issues for discussion of everything above.
2. You or I can create separate GitHub issues against the spec for each.
3. We land this change in the ED as it is now based on the resolution, even if we change the syntax or naming, it's far closer in intention than what is currently in the ED (given that devs do read the EDs, I'd like to get that updated as it currently has the change to the order property) and if we have the issues in the spec it's clear that this isn't the done deal?

I think it would be good to disentangle several different points, and these things might be good to discuss at the upcoming f2f. The planning pages currently have a mysql error so I can't see if you are going to be there, but if not maybe we can schedule them at a time you can be on the call?

[rachelandrew]

So, I've taken into account all of the above discussion. For the points that @bradkemper raised, I've created three new issues and also added these inline to the draft, I think this is better than comments on a PR that are a bit hidden. We can then deal with each individually.

Brad, your final point re tab order, I think this is already accounted for in the draft. The intention is that reading and navigation order are the same.

@tabatkins @fantasai while there are still issues to resolve, I think that the current state of this is closer in intention that what is currently published in the ED and does the work detailed in the resolution at TPAC. I'd like to propose we merge this to account for the previous resolution and I'll continue to work on the outstanding issues, and any others that are raised.

[tabatkins]

Looks good to me, +1 to merge

[bradkemper]

Thanks @rachelandrew. I will use other issues to comment, and will be at the F2F. I agree that you should move forward with what you have, and we can resolve those other issues separately.