[css-display-4] drafting reading-order-items issue #8589 by rachelandrew · Pull Request #9845 · w3c/csswg-drafts (original) (raw)

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.