[css-display-4] Proposed alternative syntax for reading order

[rachelandrew]

Working on spec edits for 8589.

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.

Alternative proposal

Proposed syntax: reading-flow: normal | layout | cross-layout (note: there is a separate issue 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, 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.

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.

[tabatkins]

Making the values extremely layout-specific was part of the earlier discussion for this topic. This was explicitly discussed, and the current design was important for acceptance of the feature.

1. We do not want to suggest that the values are usable on arbitrary layout modes; this property does not have a noticeable effect if you're not testing your site with a screen reader or similar tool, so the possibility that people slap it onto an element and just assume it works (but actually create an inaccessible document with nothing fixed) is very high if we're not careful with the design. Baking the display value into the keywords makes it much, much more obvious that you're doing something if you set flex-visual on a display:block or something.
2. As shown by the existing values, the sorts of ordering you want to do are pretty layout-specific. Being generic with names can be useful sometimes, when there are common notions between layout modes, but that's not the case here.

[JoshuaLindquist]

I think the current syntax is much easier to understand than the proposed alternative. I had to read the alternative explanation multiple times and check the additional context in the other linked comment before I understood.

I agree that it might be nice to have one layout value instead of six for code simplicity, but I also think it adds confusion because you cannot read the alternative syntax and immediately understand which display mode you are working in.

The reading-order-items property may not be in the same declaration as the display property. Perhaps display: grid is declared for all div.fubar but we only need to change the reading order on div.fubar.special. That extra declaration might be nested or even declared in a different stylesheet. You then have no idea what layout and cross-layout are doing. Is it grid or flex, rows or columns, etc.?

The current value syntax makes it immediately clear which display mode you are in and explicitly tells you what order has been activated. I also prefer how the current value syntax follows the established format of Flex and Grid related features beginning with flex- and grid- (though, admittedly, the prefixes are normally used for properties rather than values).

I see the merit of the alternative, but I strongly prefer the current syntax.

[bradkemper]

...the possibility that people slap it onto an element and just assume it works (but actually create an inaccessible document with nothing fixed) is very high if we're not careful with the design.
...
2. As shown by the existing values...

I don't think any of the values would make it inaccessible. Certain values can make accessibility of the document less predictable and less intuitive. This happens already when the DOM order doesn't match what people see with their eyes. Many people using screen readers are at least partially sited, and many more use keyboard tabbing. Besides DOM order, the least predictable and least intuitive reading/tabbing order (from the user's perspective) would be to have any section of the document read in an order that is the reverse of their language's norm. From the author's perspective, the least desirable thing would be to specify a reading order that matched visual order, and have it fall back to DOM order, which is a much more likely to be not what the author intended.

So when you say "As shown by the existing values", those values are the heart of the problem with the assumption that it might work worse for some things that the author slaps it on. In every case I can think of, it's already worse if CSS reading order is the reverse of the normal language reading order. With the three values I proposed, it is much more likely that even without testing a11y, it is a very high likelihood that the author's choice will be better than falling back to DOM order (since it matches display order and language rules), and a very low probability that it will be worse.

I mean, suppose an aside comes second in DOM order, but first in visual order. Is having it read in visual order, when the author specifies a visual order, really going to make the document inaccessible? If you switch from grid to Flexbox, or vice versa, keeping it in visual order if that was the author's intent, is always going to be better. Is there some example you can give that might change my mind?

[dbaron]

Reading the above descriptions, I'm a little confused by what "taking writing-mode into account" means. Are there any cases where using writing-mode can cause items to be read backwards from the "logical" order that was used to place them (assuming they weren't placed explicitly with grid-row, grid-column, or grid-area)? (It seems like the only thing in the existing proposal that allows reading in the reverse of the "logical" order is the combination of reading-order-items: flex-visual with flex-direction: row-reverse | column-reverse or flex-wrap: wrap-reverse, and I don't see anything in the alternative proposal that allows that.)

On a separate topic, it feels like part of @bradkemper's position is making the argument that the default value is wrong, and the default should be visual order rather than DOM order. That seems like an even bigger change, but it also feels inconsistent to accept that argument without also changing the default.

[rachelandrew]

@dbaron you mean the description of the existing spec, or in @bradkemper's proposal?

I included "taking writing mode into account" in the spec to ensure it is clear that is the intention, if someone is in a RTL language then the "reading order" is right to left. It's only in the scenario you point out, with reverse values of flex where you can switch into something that runs counter to the direction of text (and that's why we have the flex-visual and flex-flow values).

My main issue with this alternative proposal is that it would allow people to make global switches into visual order, I am pretty keen we don't allow that as in the majority of cases DOM order is the correct order. Tab's previous comment also describes why this is key to the design and acceptance of the proposal.

[dbaron]

I was referring to the description of both, I think, but I hadn't reviewed the actual spec.

[css-meeting-bot]

The CSS Working Group just discussed [css-display-4] Proposed alternative syntax for reading order, and agreed to the following:

• RESOLVED: close no change

The full IRC log of that discussion

<bramus> rachelandrew: First of 3 reading order issues
<bramus> … 1st one is an alternative syntax to current draft in display-4 and was proposed by brad.
<bramus> … in the issue i have outlined what we are currently doing and brad’s alt proposal
<bramus> … to have a reading ?? property with 3 values
<bramus> … been a few comments on the issue
<TabAtkins> q+
<bramus> … my concern is that it would allow for a global switch into following visual order which we would want to avoid I think
<bramus> … and also it feels quite confusing as it would ask devs to understand a lot about what they are doing, directions and such
<bramus> … anyone else has comments?
<bramus> astearns: is there anything about this that could be salvaged as something good to add?
<bramus> … agree we should not have a global switch
<bramus> iank_: I like the shorter property name
<bramus> dbaron: I thing next issue is about that
<bramus> rachelandrew: yes, separate thing
<bramus> astearns: other comments?
<astearns> ack TabAtkins
<bramus> TabAtkins: was on queue to agree with rachel’s reasoning. we designed it the way it is for few reasons. making it generic loses those reasons.
<bramus> … i like the current value set
<bramus> astearns: proposed resolution to close no change
<bramus> … concerns?
<bramus> fantasai: which issue?
<bramus> TabAtkins: 9923
<bramus> astearns: objections?
<bramus> RESOLVED: close no change