- From: Rachel Andrew via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Feb 2024 09:49:03 +0000
- To: public-css-archive@w3.org
rachelandrew has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-display-4] Proposed alternative syntax for reading order == Working on spec edits for [8589](https://github.com/w3c/csswg-drafts/issues/8589#issuecomment-1721504153). The current PR specifies a `reading-order-items` property, with the possible values of `normal | flex-visual | flex-flow | grid-rows | grid-columns | grid-order`. The `reading-order-items` property is added to the parent (flex or grid container) and the values behave as follows: ## On a grid container - `normal`: Follow DOM order as usual. - `flex-visual`: As `normal` (this is a grid container). - `flex-flow`: As `normal` (this is a grid container). - `grid-rows`: Follow the visual grid layout by row, taking into account `order`, writing mode, and any placement of items either by placement properties or autoflow or masonry. - `grid-columns`: Follow the visual grid layout by row, taking into account `order`, writing mode, and any placement of items either by placement properties or autoflow or masonry. - `grid-order`: As `normal` but taking any use of the `order` property into account. ## On a flex container - `normal`: Follow DOM order as usual. - `flex-visual`: Follow the visual layout of the items, taking `order` and writing mode into account. Therefore in a LTR writing mode, reading and navigation order would be left to right even if a reversed method was used). - `flex-flow`: Follow the flow direction of the items, taking `order` and writing mode into account. - `grid-rows`: As `normal` (this is a flex container). - `grid-columns`: As `normal` (this is a flex container). - `grid-order`: As `normal` (this is a flex container). See the PR and also this repo for some worked examples of these. Raising this issue as @bradkemper has an alternative proposal detailed in comments. I've copied this from [the original issue](https://github.com/w3c/csswg-drafts/issues/8589#issuecomment-1694127490). ## Alternative proposal Proposed syntax: `reading-flow: normal | layout | cross-layout` (note: there is [a separate issue](https://github.com/w3c/csswg-drafts/issues/9921) about the property name) - `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/direction. 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. ## Initial thoughts As I [commented in the PR](https://github.com/w3c/csswg-drafts/pull/9845#issuecomment-1913153664), I'm not keen on cross-layout, developers are routinely confused by what is meant by the cross axis in flexbox. I think this proposal would be harder to explain to people. Brad disagreed, you can [see his reasoning in this comment](https://github.com/w3c/csswg-drafts/pull/9845#issuecomment-1915392860). I think people do use reverse flex layouts and expect things to still navigate according the the visual reading order, I've definitely seen people surprised by that in the early days of teaching flexbox, maybe not so much now. I also think that we have a goal of making people use this property in a very intentional way, having anything that just works in a magical (and slightly different) way across all layout methods could result in odd things happening if people change from a flex to a grid layout, for example. Raising this here though, to ensure these alternative thoughts are properly discussed rather than being hidden in comments. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9923 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 February 2024 09:49:05 UTC