Re: [csswg-drafts] [css-display-4] drafting reading-order-items issue #8589 (#9845)

# Reply to reading order comments 

> 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 writing`direction`), 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. 

-- 
GitHub Notification of comment by bradkemper
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9845#issuecomment-1915392860 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 29 January 2024 19:14:49 UTC