Re: [csswg-drafts] [css-display-4] Do we need `reading-order: <integer>` or should `reading-order: auto` be allowable in all grid or flex layouts? (#8589)

While I like giving power to the designer/developer, I think we should strive towards keeping this simple, without excessive options.
 
I also think we should decouple `reading-order-items` from a direct association with `order`, even in the property name. I like `reading-flow’. It would be inheritable, and affect tabbing order (when `tab-index` is not an integer greater than 0) and any other sequential access such as screen reading order. We might even let it affect the initial scroll position of a scroll pane (not sure if that is a sensible thing to do or not).
 
Having a separate `reading-order: <index>` property for tweaking individual children’s reading order separately from `order` should really be a completely separate issue, IMO, and not considered in the design or naming of the parent element’s reading flow property.
 
I also think we shouldn’t have values like `flex` that only apply apply when you have flex layout. It would be better to have “layout reading flow” value that can be set at the top of a tree and inherit down into whatever layout types exist within its decendants, including tables, grid, flex, and maybe floats. I don’t think negative margins, transforms, or abs-pos/fixed positioning should have any effect on how it works (it doesn’t seem necessary, and probably overly complicated for all parties, and would probably lead to behavior that is surprising for authors and users).
 
So my proposed syntax is:
 
```
reading-flow: normal | layout | cross-layout
````
 
Value meanings:
 
`normal`: DOM order, as it is today.
`layout `: After layout, including the effects of `order`, `grid-auto-flow`, the `grid-area` properties, the `flex-flow` properties, and `float`. Reading and tabbing happens in the direction of `flex-flow` for flex-layout, and in the direction of `grid-auto-flow` for grid. That determines whether you start with columns vs. rows in grid and table (if `grid-template-rows` is `masonry`, then reading starts with columns, and vice versa). The reading/tabbing order within each row or column would be from start to end (inline first, then block), AFTER `order` and the `grid-area` properties (and any dense packing) have determined the layout arrangement. The `-reverse` suffix for `flex-direction` and `flex-wrap` would have *no* affect on the direction of reading/tabbing (because that would be weird).

This also means that the cells of tables would would be in accessed in writing-mode order, e.g. starting in the lower right corner for `vertical-rl` writing mode. If the author didn’t want that, they could control it with something like this: `html, td {reading-flow: layout } table { reading-flow: normal }`

For floats, items floated to the inline-start side are read/tabbed to *before* other items or text in the line, and items floated to the inline-end side are read/tabbed to *after* other items or text in the line. (P.S. I don’t actually know how `float: left|right` works in vertical layouts.)

Even if a table-cell or grid item or flex item or float is not focusable, if this property causes them to move up or down in the reading order, then anything focusable in the contents of those items would also move up or down in the tab order. Tabbing is still from outwards to inwards if both an ancestor and decendant can both be focused.
`cross-layout `: same as `layout`, but in the cross direction for non-masonry grid and tables. For all other layout modes, this value is indistinguishable from `layout`.
 
As mentioned above, I can’t really imagine a likely case in which you would want to read or tab in a direction that is opposite of the reading mode. So in English, if you are reading by column (because of e.g. `reading-flow: layout; grid-auto-flow: column` for grid, or `reading-flow: cross-layout` for table), it would be top to bottom, and if you are reading by row it would be left to right.

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


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

Received on Saturday, 26 August 2023 02:36:00 UTC