New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-display-4] Proposed alternative syntax for reading order #9923
Comments
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.
|
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 The 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 I see the merit of the alternative, but I strongly prefer the current syntax. |
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 |
Working on spec edits for 8589.
The current PR specifies a
reading-order-items
property, with the possible values ofnormal | 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
: Asnormal
(this is a grid container).flex-flow
: Asnormal
(this is a grid container).grid-rows
: Follow the visual grid layout by row, taking into accountorder
, 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 accountorder
, writing mode, and any placement of items either by placement properties or autoflow or masonry.grid-order
: Asnormal
but taking any use of theorder
property into account.On a flex container
normal
: Follow DOM order as usual.flex-visual
: Follow the visual layout of the items, takingorder
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, takingorder
and writing mode into account.grid-rows
: Asnormal
(this is a flex container).grid-columns
: Asnormal
(this is a flex container).grid-order
: Asnormal
(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 oforder
,grid-auto-flow
, thegrid-area
properties, theflex-flow
properties, andfloat
. Reading and tabbing happens in the direction offlex-flow
for flex-layout, and in the direction ofgrid-auto-flow
for grid. That determines whether you start with columns vs. rows in grid and table (ifgrid-template-rows
ismasonry
, 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, orreading-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.
The text was updated successfully, but these errors were encountered: