[css-flexbox][css-grid] Providing authors with a method of opting into following the visual order, rather than logical order

[rachelandrew]

A proposal to provide a method in CSS for authors to opt in to following the visual order when in a flex or grid context.

The grid and flexbox specifications detail that reordering caused by these methods is only visual, and note that use of order or grid placement to do logical ordering is non-conforming.

With care from the author in creating a good document, this in general works well for screen reader users. Authors sometimes also use this to improve the experience for screenreader users. For example, by being able to show something visually near the top of the page but, because it would be repetitive for a screen reader user, physically locate it in elsewhere in the document.

Problems

Visual/tab order disconnect for keyboard users

In most cases, the document order is the correct logical order for screen reader users who are not able to see the visual display at all. However, if the author has reordered content using grid or flexbox, then the tab order of the document for keyboard users who are referencing the visual display can become disconnected, as it follows the document order.

Some use of grid layout in particular can cause reordering without input from the author. For example using grid-auto-flow: dense. In this case a screen reader user is likely well served by the document order, the keyboard navigator may experience unexpected jumps around the component as items appear out of logical order.

Example: https://codepen.io/rachelandrew/pen/NWbLRQE

Authors also want to be able to reorder content at different breakpoints, to provide the best presentation of the layout for different amounts of screen real estate. In this case again, it is likely that by starting with a sensible document source, a screen reader user will not be affected. A keyboard navigator could experience big jumps around the layout if, for example, an item that logically appears near the top of the source is placed in the footer.

Example: https://codepen.io/rachelandrew/pen/xxRJBGz

Impact on screen reader users if the author assumes the visual order is the logical order

Screen reader users can be impacted by the issue if the author assumes the visual order is the logical order. For example, someone building a site using a visual design tool that lets them drag elements about and places them using grid layout. In this scenario the author may never see the document order. If that tool does not also modify the source to reflect the visual layout, the screen reader user is going to hear things in a different order than the author intended.

In addition, tools that use the CSS order to infer logical order, will affect screen reader and keyboard navigators alike. Examples:

• Twitter thread (the demo uses order to re-order things by interest, it was pointed out this may have accessibility issues)
• Using the Grid Shepherd Technique to Order Data with CSS

Many discussions around this issue have ended on a note that authors should be “doing the right thing” and basing designs around a logically ordered document. As noted, in most cases this will serve screen reader users well. It can actually work against those using the keyboard to navigate however, as what they are looking at can become disconnected from the logical order.

Proposal

Provide a method in CSS for authors to opt into following the visual order when in a flex or grid context.

We already know the "visual order" of elements when in a flex or grid context:

• CSS Display: order-modified document order
• CSS Grid: grid-modified document order

When in a flex or grid context, authors could add a property, with a value that opts a component into a state where the order-modified, or grid-modified order should be followed. This would enable authors to indicate where this was appropriate, while still allowing order modification to be used without affecting logical order if that was appropriate.

For example:

.container {
  display: grid;
  focus-order: visual;
}

An opt in would enable use cases such as this thread. It would also mean visual design tools that allow people to create layout by drag and drop could add the opt-in as soon as the user started to create a layout that had the potential of reordering.

We could also consider making the default ordering visual in cases such as grid masonry layout, or auto-flow: dense where reordering is almost inevitable.

Alternate approaches and related work

An HTML attribute

During the breaks in a 2019 CSS WG meeting I discussed this issue with @bkardell and @hober, we have considered using an HTML attribute to indicate that the contents of that element had no logical order, therefore order should be inferred by other means (such as that created by CSS).

I think this could have broader implications than we really need to solve the issues that authors have. It could lead to people always adding this attribute to the body, and therefore treating the document as a bunch of unsorted stuff. It would also require that this worked in block and inline layout too, for example with positioning. While it is possible to reorder with absolute positioning, positioning an element requires some work and thought form an author already, and many of the use cases are better solved with grid today.

In addition, in a responsive design, it may only be at certain breakpoints where this disconnect happens. This would mean that authors could opt in only at the point at which they use a media or container query with the express purpose of doing some reordering.

CSS Spatial Navigation

The Spatial Navigation spec proposes a method of navigating a 2d space.

Open UI: focusgroup

The focusgroup primitive aims to facilitate focus navigation using arrow keys.

Research and further reading

Various people have already written about this problem. These posts also include examples of the issue.

• Previous issue (linked to Masonry) with examples and suggestions.
• Rachel Andrew: Grid, content re-ordering and accessibility
• Rachel Andrew (talk and demos): Grid, content, re-ordering and accessibility
• Manuel Matuzovic: The Dark Side of the Grid: Visual Order
• Adrian Roselli: Source order matters
• Adrian Roselli: HTML Source Order vs CSS Display Order
• Léonie Watson: Flexbox and the keyboard navigation disconnect
• MDN: CSS grid layout and accessibility

Examples from the community

I’ve asked for examples of this and related issues, please add a comment if you have more examples:

• Scott Jehl
• Wanting to reorder to cope with fixed markup
• Reordering for different screen sizes
• Deliberate visual reordering different to source
• Another example of deliberate visual reordering

[ausi]

I’d really like that feature 😍

Regarding the naming: the term “visual” might be confusing as it does not represent the actual visual order (after transforms applied and so on).

Maybe naming it something like focus-order: layout; and the current one focus-order: markup; can help to resolve this.

Related twitter thread: https://twitter.com/ausi/status/1538772128581013504

[MattWilcox]

This would be a great feature. Seconded with @ausi - the "visual" keyword has a separate meaning from "source order" or "flow / layout". Looking at the example code: https://codepen.io/rachelandrew/full/xxRJBGz the visual order may change purely by the visual design of the content without any source order or layout changes. For example if one box was fluorescent yellow with large black text, and another was the same but with smaller text, and every other box was monochrome greyscale - that establishes a visual order that's independent of layout and source order. That's what design is about doing, so naming the current mode "visual" is not accurate and potentially confusing. I don't see how a focus-order: visual would be possible in an automated way as the browser would have to understand how humans see things and rank attention in visual processing.

focus-order: layout; or focus-order: flow; would both work for a system that re-indexes focus based on the two dimensional order of content - though you still need to decide whether the order follows left-to-right as the primary axis or top-to-bottom as the primary axis, which may involve another keyword. I don't think it's safe to assume that flow will follow the document writing direction for this.

[MattWilcox]

2d display throws some spanners in the works. These suggestion's aren't likely to be right, but I think you'd need some mechanism to achieve a similar thing:

focus-order: source - the default we have now. focus-order: flow - in order of the language's document flow (e.g., left to right then top to bottom - row based) focus-order: cross-axis - the cross axis of the document flow (e.g., top to bottom then left to right - column based)

[smhigley]

Just to clarify, is the suggestion here to have focus/tab order differ from the accessibility tree/screen reader virtual cursor order? I'm probably missing something, just from the proposal text I assumed focus-order would influence both the accessibility tree order and the focus order, but the earlier sections are making me second-guess 😅.

[oberocks]

First off, this is really needed and could be super helpful. Especially for complex responsive visual order changes.

Just wanted to also voice (purely due to work of late) that this is also a really big deal from a component lib POV. If library A is set for one flow type and library B is set for another, both would ideally need a lib wide flow setting and top level options/inheritance for the downstream component users to set across all their component libs. Well that or discourage lib authors from declaring any flow state at all. 🤔

Good stuff, many thanks, and awesome work!

[aardrian]

I am so sorry to have spammed this with so very many words. I also have ignored all other comments because this is long enough.

I appreciate that the opening lays out the current situation, but there are a couple assumptions within worth reconsidering:

[…] With care from the author in creating a good document, this in general works well for screen reader users. […]

Some examples might be handy here. Moving an image visually before a heading in a card layout is good example (so the image retains its position, and meaning, following the heading in the DOM).

[…] For example, by being able to show something visually near the top of the page but, because it would be repetitive for a screen reader user, physically locate it in elsewhere in the document. […]

This may be true in some contexts for blind screen reader users. But since ¼ to ⅓ of screen readers are not blind this tends to be a problem. I am wary of the broad strokes here because I see devs making assumptions about "repetitiveness" and visual placement often.

Problem

Visual/tab order disconnect for keyboard users

[…] Authors also want to be able to reorder content at different breakpoints, to provide the best presentation of the layout for different amounts of screen real estate. In this case again, it is likely that by starting with a sensible document source, a screen reader user will not be affected.

A blind screen reader user may not be affected. A blind screen reader user who contacts support, or has a sighted person guide them in any way, may discover that directions like "the box after the heading" are meaningless when the DOM order does not match the visual layout. A low-vision screen reader user may also struggle when zooming causes breakpoints to visually reflow the visual order distinctly from the DOM order. The example, however, is a fantastic visual demo.

Impact on screen reader users if the author assumes the visual order is the logical order

[…] the screen reader user is going to hear things in a different order than the author intended. […]

No tweaking here; I am using this opportunity to let readers know that some screen reader users do not hear the output, but instead experience it on a Braille display. It should not affect this conversation much, but it is worthyknowing.

• Twitter thread (the demo uses order to re-order things by interest, it was pointed out this may have accessibility issues)

The "zero client-side JS" example is a bit of a red herring. Truly accessible interfaces would leverage script to re-order the content as appropriate. Most CSS-only UI efforts have questionable accessibility since things like state, properties, values all have to be managed and live outside the scope of CSS.

• Using the Grid Shepherd Technique to Order Data with CSS

This is another case where a CSS-only solution is only performing a visual change. This is the job for a DOM re-order via script. Not only that, developers (should) have known for years that CSS flex/grid-only solutions break semantics (not linking much-maligned original tweet), even though browsers fixed those gaps. That 2019 post should not have survived testing in real use.

Proposal

Provide a method in CSS for authors to opt into following the visual order when in a flex or grid context.

Essentially mimic how Firefox used to behave (2015), before it was changed (January 2016 / Firefox 44). At least, that is how I am reading this. These old bugs may be useful to peruse to understand why the change (or not?):

• #1107734 CSS flexbox order is not mapped into accessible tree (2014)
• #812687 Don't reorder frame tree for flex items (because "order" shouldn't affect tab-index / nav-index) (2012)

For example: […] focus-order: visual; […]

This is where I have my issue — the concern is about reading order, which begets focus order based on position in the DOM. The property name is disconnected from the intent or, if the intent is only to apply to focusable elements, will create greater problems as those will break from surrounding context.

• If this is meant to affect visual order, then how will it resolve conflicts with the existing order property?
• Does this only apply in a flex/grid context, and if so, what about absolute positioning and floats?

There is a genuine risk of a reading order, focus order, and DOM order disconnect. Incidentally, those are two separate WCAG Success Criteria to consider:

• 1.3.2: Meaningful Sequence (Level A)
• 2.4.3: Focus Order (Level A)

An opt in would enable use cases such as this thread.

I maintain that thread is a red herring. The wrong tool is being used for the job. Script should have been employed to re-order the DOM.

It would also mean visual design tools that allow people to create layout by drag and drop could add the opt-in as soon as the user started to create a layout that had the potential of reordering.

I don't understand. A design tool like Figma or like WordPress's block editor? The former should not render production code and so this proposal would be moot in that context. The latter suggests a visual designer is already working with a developer to enable some form of reflow. This may also be my lack of imagination.

We could also consider making the default ordering visual in cases such as grid masonry layout, or auto-flow: dense where reordering is almost inevitable.

If this means what I think it means, I refer readers to the Firefox issues I linked.

Alternate approaches and related work

An HTML attribute

For all the reasons cited, and years of tabindex misuse, I agree this is not a good approach.

CSS Spatial Navigation

The Spatial Navigation spec proposes a method of navigating a 2d space.

Spatial navigation is meant only for interactive controls. Which, again, causes me concern since disconnecting focus order and reading order brings a bunch of unnecessary risk. Which is also why I am confused about this proposal overall since it seems to alternately equate the two and ignore one or the other.

Anyway, if readers want to try spatial navigation, I have instructions how you can do it today as part of a larger post about keyboard navigation in scrolling content areas (which maybe should be a concern within this proposal as well).

Open UI: focusgroup

The focusgroup primitive aims to facilitate focus navigation using arrow keys.

My comments about spatial navigation generally apply here, minus being able to play around with it.

[alastc]

I think this feature is desirable from an accessibility point of view.

in most cases this will serve screen reader users well. It can actually work against those using the keyboard to navigate

I also tend to separate keyboard/switch (visual) use from screenreader use to explain things, but as Adrian notes it is more of a continuum. Some people with cognitive issues using screenreaders, and some low-vision people partially using a screenreader. Therefore the focus-order should follow the content order in general.

I think this needs to be the wholistic reading / content order, e.g. reading-order, or content-order: visual;? Otherwise it might be thought to only affect interactive controls.

Also, if the other value was "logical", I think that might get confusing as many orders can be "logical" depending on your perspective. Wouldn't it be better as DOM or source-code?

Assuming this would apply within media queries, it would also solve the responsive order conflict I noted previously. That is also a good argument for having it in the CSS rather than HTML, the desired order might vary based on things in the CSS.

[rol4nd909]

Yes please this would be a nice feature! 😍

[fantasai]

I agree with a lot of the concerns noted by @aardrian in https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1160991881 and while I think it's clear we need to do something here, I want us to be careful about what we're doing so that we don't make things worse. To that end, there's a few things we should consider:

• Focus order and screenreader order should always match, because there are users who use both together.
• There are clear use cases for disconnecting these from the box layout order, the most fundamental of which is to make sure the focus/screenreader order matches the visual perception order when it is not the same as the layout order.
• There are a lot of cases where authors are using order as a convenience to perform semantic reordering (e.g. sorting lists). These are cases where all the orders should match, including the source order.
• There are also cases where visual design choices should affect all user interaction orders, but the reordering is not fundamentally semantic (because either order would convey the same information; essentially the pieces are semantically unordered).
• Each component or hierarchical level of a page can have different requirements for reordering, so we shouldn't design something that lends itself too easily to blanket use (like box-sizing) rather than tailored use (like logical properties).

My proposal here is twofold:

• Put some pressure on the DOM teams to provide a better API for reordering siblings. Something like Element.sortChildrenBy(attribute or comparison function) could go a long way towards reducing inappropriate use of order for semantic ordering, especially if it can be so simple that we can slip copy-pasteable examples into various tutorials and reference pages on order itself.

• Add a property (“reading-order”) that affects reading and interaction order simultaneously, not just focus order, and in a way that lends itself to explicit tailoring for each case of reordering, e.g.:

   reading-order: source | auto | <integer>
     impacts screenreader, 'speech' media, focus order (subordinate to tabindex)
     source = document source order (as currently)
     auto = source, except match randomizing layout methods (dense/masonry)
     <integer> = modify source order by <integer> (just like order/z-index)

  Could even make it a longhand of order (bikeshed keyword):

  order: <'box-order'> [ <'reading-order'> | reading-matches-box-order ]?
   box-order: <integer> /* current order property */
   reading-order: source | auto | <integer>

  This makes it easy to think about them together, and allows a lot of flexibility in tailoring the reading order compared to the box order, but requires considering the reading order explicitly in order to affect it.

[css-meeting-bot]

The CSS Working Group just discussed [css-flexbox][css-grid] Providing authors with a method of opting into following the visual order, rather than logical order, and agreed to the following:

• RESOLVED: the WG not accept ‘visual-order’ as a switch, but continue working on other methods of order that will aid various technologies
• RESOLVED: (and vice-versa for the last baseline)

The full IRC log of that discussion

<emeyer> Topic: [css-flexbox][css-grid] Providing authors with a method of opting into following the visual order, rather than logical order
<emeyer> github: https://github.com/w3c/csswg-drafts/issues/7387
<Rossen_> s/will be republished/Publish new WD of css-contain-3/
<emeyer> TabAtkins: In Rachel’s post, she points out with Grid and flexbox, visual order can be divergent from source order
<emeyer> …That’s literally the feature. But it’s easy for the two orders to diverge, such as styling a grid differently based on media queries.
<emeyer> …Suggestion is to have a way for authors to indicate to the browser that it should present elements to the accessibility tree in source or visual order
<Rossen_> q+
<emeyer> …Example, in masonry layout, the visual order is guaranted to get shuffled
<emeyer> …We’ll need to address how this impacts focus navigation; lot of details to get worked out
<emeyer> …Core idea is: can we give CSS authors to have a way to opt into different accessibility ordering?
<emilio> q+
<fantasai> https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1160991881
<emeyer> fantasai: I have a lot of concerns, as did posters in the thread
<emeyer> …One is that having focus order differ from screen reader order is a real problem
<emeyer> …There are a bunch of other considerations like: some examples should have source order changed, not be addressed via this sort of mechanism
<fantasai> https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
<emeyer> …I think we should consider that focus and screen reader order should always match
<emeyer> …There are clear use cases for disconnecting layout order and screen reader order, because visual-perception order is not the same as layout order
<emeyer> …There are examples in the thread where you don’t want to follow the box order
<emeyer> …There are a lot of cases where people are using ‘order’ as a convenience and we don’t want to encourage that
<emeyer> …It’s important to note that each hierarchical level of a page can have different needs for ordering. We should have something that can do fine-tuned adjustments on specific cases, not be a document blanket
<emeyer> …We should put pressure on the DOM side to provide an API for letting people rearrange DOM order, something simple
<fantasai> https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
<emeyer> …We should also add some ability to change reading order in CSS
<fantasai> reading-order: source | auto | <integer>
<miriam> q+
<emeyer> …We’ll want the ability to force source order, there should also be the ability for the author to specify exact reading order
<fantasai> order: <'box-order'> [ <'reading-order'> | reading-matches-box-order ]?
<fantasai> box-order: <integer> /* current order property */
<fantasai> reading-order: source | auto | <integer>
<emeyer> Rossen_: huge plus-one on all that
<fantasai> i/Rossen_: huge/fantasai: This is my proposal. Open to others, but I think `focus-order: visual` as proposed earlier would be harmful/
<emeyer> …Very long-standing issue. I strongly believe calling this ‘visual-order’ will create misperceptions
<fantasai> We have box-sizing, and box-decoration-break, border-box/content-box, etc. So we've already established the idea of CSS boxes
<emeyer> …As we are thinking through this, there’s an intersection of how to handle focus, how to handle search, screen reader order; if these are in mistmach, they cause confusion
<Rossen_> ack Rossen_
<Rossen_> ack emeyer
<smfr> make d
<Rossen_> ack emilio
<emeyer> emilio: The proposals seem fine but I think there’s a lot more complexity than it seems
<emeyer> …focus order is already not following the accessiblity tree order
<emeyer> …At the very least, we should figure out what tree we want to sort on; we might want focus order to be flat-tree order
<Rossen_> ack miriam
<emeyer> miriam: My main concern as an author is where it happens automatically, like in ‘grid-flow: dense’
<emeyer> …Will ‘auto’ solve those sorts of things?
<emeyer> fantasai: Yes. I’m open to which value should be the default.
<Rossen_> q?
<emeyer> Rossen_: Sounds like there’s a set of good proposals that Elika summarized, but don’t feel like we’re ready to resolve on any of them
<emeyer> …Do you want to discount any of these now, Elika?
<emeyer> fantasai: I’m against having a switch that just says “use the visual order” because I think it would be mis-used and allow people to stop thinking about source versus reading order
<fantasai> s/mis-used/misunderstood and mis-used/
<emeyer> Rossen_: So we can resolve on this and continue to work on the details of how this will work
<fantasai> s/versus reading order/versus reading order to the detriment of getting it right/
<emeyer> RESOLVED: the WG not accept ‘visual-order’ as a switch, but continue working on other methods of order that will aid various technologies

[chrishtr]

Agenda+ to discuss and resolve on reading-order as proposed here. Let's include a11y representatives in that discussion also.

[rachelandrew]

I thought I'd add some examples here as to how reading-order might behave from the point of view of the different use cases authors have. This is based on my understanding after our break discussion at TPAC.

Example 1: The layout uses grid-auto-flow: dense

In this case, using dense packing indicates that the elements inside this layout do not have a defined order. The grid items should have reading-order: auto, and the reading order will then follow the grid-modified order that is created by the dense packing.

Example 2: To create the optimal reading order at different breakpoints, the author uses media queries to change the reading order of elements at one or more breakpoints.

Within media queries, in addition to changing where items sit on the grid, the author will add the reading-order property to each grid item, with an integer indicating the reading order of that item at that breakpoint. When developing such a layout, the author should create a canonical source order that makes the most sense if the document were read with no CSS. They will then only need to add reading-order to grid items in presentations of the layout where reordering happens.

Example 3: The layout is being created by a WYSIWYG editor that allows people to create a layout visually.

The spec should clearly define that UAs used to create such layouts are non-conforming if they use reading-order to avoid needing to re-order the source. As with an author creating such a layout manually, the UA should create a canonical source order, and re-order the underlying HTML to match it. It can then enable authors to create other presentations of the content, by using reading-order.

[aardrian]

@chrishtr

Agenda+ to discuss and resolve on reading-order as proposed https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918. Let's include a11y representatives in that discussion also.

I take this to mean you do/did not have accessibility reps in the prior session. Do you have any for the coming discussion? Or are you looking for some?

[chrishtr]

I take this to mean you do/did not have accessibility reps in the prior session. Do you have any for the coming discussion? Or are you looking for some?

I am looking for some, and have emailed public-aria inviting that group to attend.

[cookiecrook]

One thing I did not see mentioned is, what should happen to KB or AT focus when the layout order and/or focus order changes out from underneath the user? KB focus is easily detectable, but AT focus is usually not, so there is no consistent way to know whether the user is in an appropriate context where it's acceptable for the author to change the respective orders. Perhaps the recommendation should be to only change the order on user action, and have an optional parameter (if a JS API?) that hints where the new KB focus and/or AT focus should go.

I'm looking forward to attending the CSS call to discuss this. I think the proposal is a good starting point, but a CSS algorithm may be insufficient to determine flow order or where KB or AT focus should "land." That said, requiring authors to call focus() after a layout change also hasn't proven to work well… most forget. I could be convinced that algorithms may handle the general cases if explicit ordering and focus hint options remain.

Some additional comments that came from Apple internal discussion:

• would need to determine visual/layout order for all cases of grid and flex, not just simple cases
• Is this something that the spec authors intend to define, or is it left to the implementation to determine what constitutes visual/layout order?
• As with above, what happens when the layout algorithm and DOM still result in an unintended order? Can an author override?

[css-meeting-bot]

The CSS Working Group just discussed [css-flexbox][css-grid] Providing authors with a method of opting into following the visual order, rather than logical order, and agreed to the following:

• RESOLVED: Draft reading-order (minus source value) into css-display-4 ED

The full IRC log of that discussion

<Rossen_> Topic: [css-flexbox][css-grid] Providing authors with a method of opting into following the visual order, rather than logical order
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/7387
<jcraig> rachelandrew: several requests over the years
<jcraig> css says stick with document order... works in most cases
<jcraig> but with grid in particular, can be a disconnected from the sighted focus or AT, screen reader...
<jcraig> my initial proposal, can the author opt in to "visual" order instead of Dom/source
<fantasai> my proposal Rachel mentions is here: https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
<jcraig> fantasai proposed a more refined order @@@elika help?@@@
<fantasai> rachel's use case analysis is here: https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1248754496
<Rossen_> q?
<jcraig> so we need a way to define reading order if not logical in the DOM
<fantasai> scribenick: fantasai
<jamesn> q+
<fantasai> chrishtr: Specific proposal from fantasai on August 16th (see above)
<fantasai> ... candidate for resolution
<fantasai> ... affects focus order and reading order simultaneously
<chrishtr> https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
<chrishtr> (oops, sorry dup of what fantasai said above)
<fantasai> ???: Just want to confirm it's for grid/flex, not abspos etc?
<astearns> s/???/jamesn/
<fantasai> rachelandrew: Yes, you can get disconnected order in abspos
<Rossen_> ack jamesn
<fantasai> ... but I don't see people building entire layouts using abspos
<jcraig> s/???: /jamesn: /
<fantasai> ... things like grid-auto-flow: dense are cases where the won't know where things are
<fantasai> ... so scoping down
<TabAtkins> They are reordering, *and* we have a reliable way of knowing the order they're producing (as opposed to abspos/floats).
<fantasai> jamesn: support scoping down, just wanted to confirm
<iank_> q?
<fantasai> iank_: Question, in flexbox there's various mechanisms to switch the order
<fantasai> ... e.g. flex-wrap: reverse
<fantasai> ... would this affect that as well?
<fantasai> rachelandrew: I think so, should behave similar way as when you have one of the grid values that allows reordering
<fantasai> ... if logically it looks like you're following the different order
<TabAtkins> Yes, I think they'd also reorder per the reading order of the writing mode on the element, I'd think.
<fantasai> ... but worth coming up with use cases to check
<fantasai> Rossen_: fantasai, can you give an overview of the proposal?
<fantasai> ... particularly effects on flex/grid and also on abspos
<fantasai> ... if mostly reviewing, don't need thorough minuting
<fantasai> https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
<Rossen_> q+
<Rossen_> ack fantasai
<jcraig> fantasai: reviewing this proposal to add a reading order property with values: source (DOM), auto [default, would follow rendering order but not in cases that authors could not predict. final value: an integer that affects keyboard order
<iank_> q+
<jcraig> could also use it differently than the order property.... or use reading order in layout mode... so abspos elements reading order could be modified by the order value.
<jcraig> IMO author unpredictable layout methods should not be covered by auto... maybe a different keyword, but not by default
<jamesn> q+
<jamesn> q-
<fantasai> s/unpredictable/predictable/
<jcraig> e.g. if you're reversing the order, that doesn't mean there is no order,. should follow the layout.
<jcraig> q+
<jamesn> q+ to clarify which would be the default (I had previously presumed source)?
<jcraig> ack me
<jcraig> Rossen_: how does this impact reading order vs focus management
<jcraig> ack Rossen_
<fantasai> fantasai: Randomizing layout models indicate that the underlying order of the items doesn't matter, so in this case we want the UA to make the reading order match the visual order.
<fantasai> ... but if it's not randomizing, the source potentially has meaningful order and we should preserve that unless specifically overridden by the author
<jcraig> fantasai: reading order vs focus management... different ways to manipulate the default.... linear forwards or backwards
<jcraig> linear order is an artifact of the @@@ order
<jcraig> there should not be a disconnect between the order we choose for the reading order and the focus order
<fantasai> Rossen_: suppose I have items with tabindex, I swap the visual order, what happens
<chrishtr> +1 to tabindex taking precedence
<jcraig> fantasai: interaction with tabindex needs defining... explicit tabindex should be respected
<jamesn> q-
<Rossen_> ack iank_
<fantasai> iank_: Property does 2 things, work at different levels
<fantasai> iank_: e.g. reading-order, works at the container level
<fantasai> iank_: I think it's a mistake to also bundle the 'integer' variant on top of that
<fantasai> iank_: it seems to me that it operates on the item instead
<fantasai> iank_: so if we want the integer variant, that should likely be a separate property
<jcraig> fantasai: think of the value similar to z-index: auto versus integer
<jcraig> iank_: would then need to set on every item?
<jcraig> fantasai: I see that as an unsolved issue... integer versus auto can't be resolved at the element level
<fantasai> s/see that as/see, that's
<jcraig> fantasai: could drop the source value unless someone really wants it
<Rossen_> q?
<jcraig> could be useful as separate properties in case you want to define them independently
<fantasai> iank_: are valid use cases for source order
<fantasai> ... core use cases for column-reverse is chat bubbles that propagate upwards
<fantasai> ... but you're saying that doesn't affect it ...
<fantasai> iank_: I think I'll need to see all the interactions written down
<fantasai> ... before I can evaluate it as a whole
<fantasai> ... lots of subtle interactions here
<jcraig> q+
<fantasai> jcraig: I agree lots of subtleties in the layout examples
<rachelandrew> q+
<fantasai> ... some of the other subtleties mentioned last night are what's supposed to happen to either a keyboard user's focus or an AT user's focus, such as screenreader
<fantasai> ... not detectable
<fantasai> ... what happens when the order changes on the fly?
<fantasai> ... use cases were based on dynamic interaction of values of these orders might change
<fantasai> ... what happens to the users keyboard focus or AT focus, when metaphorica rug gets pulled out?
<fantasai> ... If JS interaction, author should maybe call .focus() after UI modification
<fantasai> ... but in this case, not a CSS method for doing this
<fantasai> ... do we expect this to be primary rendering layout in CSS and then need to follow up with focus method afterwards?
<fantasai> ... or other interactions?
<jcraig> fantasai: focus should stay on the same element. but its relative order to other elements around it
<fantasai> ... can change
<fantasai> fantasai: only have a problem if you remove the element you're on
<fantasai> jcraig: afraid there's some unpredictable cases, e.g. you tab through and get stuck in a loop
<fantasai> ... so interactions where we might not be able to rely on it
<fantasai> ... could maybe get a good default
<Rossen_> q?
<fantasai> ... when that happens, maybe call focus()
<Rossen_> ack jcraig
<fantasai> ... I'm just worried about a layout method that changes reading/kb/AT order not tied to a JS call
<fantasai> rachelandrew: In terms of having all of the likely combinations that might want to assess, would it be helpful for me to do?
<fantasai> ... discussed with Chrome DevRel
<fantasai> ... would it be helpful to come up with the different combnations of things are that people could see this being used for?
<Rossen_> q?
<jcraig> s/JS call/JS call (e.g. focus()) that would not to be used to correct it/
<fantasai> jcraig: that would be great
<Rossen_> ack rachelandrew
<chrishtr> q+
<jcraig> q+
<jcraig> q+ to volunteer to work on that use case list with rachelandrew
<rachelandrew> they are all with me here in NY so I'll go and talk to folks :)
<fantasai> chrishtr: I suggest possible resolution, in general this is a good idea, need to work out the details, so go work it up in a draft spec
<fantasai> me q+
<Rossen_> ack chrishtr
<Rossen_> ack jcraig
<Zakim> jcraig, you wanted to volunteer to work on that use case list with rachelandrew
<fantasai> jcraig: happy to work on the list with rachelandrew
<fantasai> ... and try to throw in as many AT challenges as I can
<Rossen_> ack fantasai
<chrishtr> display-4 SGTM
<fantasai> fantasai: Suggest drafting into css-display-4
<fantasai> fantasai: (which doesn't yet exist)
<fantasai> fantasai: then we can work on details, evaluate, and decide if we like it
<fantasai> Rossen_: Opinions from others?
<fantasai> ????: I do agree with what you've been talking about, just read through the bug, and there are some things I'm not familiar enough that I can't provide info on, but like idea of moving this
<fantasai> ????: One scenario is that basically curious how it works with ARIA widgets, e.g. listbox that has options
<astearns> s/????/bryang/
<fantasai> bryang: style various list items, once you add aria roles to it [missed]
<fantasai> bryang: I'd be happy to be part of future discussion if that's helpful
<fantasai> Rossen_: Thanks, helpful
<fantasai> Rossen_: anything else on this topic?
<fantasai> Rossen_: we have concrete direction
<fantasai> Rossen_: talked about this in 2015, glad to see we've got a direction here
<fantasai> RESOLVED: Draft reading-order (minus source value) into css-display-4 ED
<rachelandrew> thanks all, I'll start a list and ping people to contribute
<fantasai> Rossen_: Ok, back to our regularly scheduled CSS topics. Welcome to stay or leave
<jcraig> scribe- jcraig

[fantasai]

Drafted up css-display-4 ED with reading-order and layout-order longhands for order as outlined in https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918. Agenda+ to request CSSWG review of the text and the following details:

• order as shorthand for reading-order and layout-order
• reading-order applied to all elements, not just flex and grid
• order shorthand syntax defined as:

  [ <'layout-order'> <'reading-order'>? ] | /* reading defaults to 0 */
  [ reading && <'reading-order'> ] |        /* set reading to value, layout to value */
  [ layout && <'layout-order'> ] |          /* set layout to value, reading to zero */
  [ [ reading && layout ] && <integer> ]    /* set both to same value */

  Note: We are deliberately making it uncomfortable to set both, since in most cases where you want to change both you're supposed to fix the source order.

• https://github.com/w3c/csswg-drafts/pull/8257

[cdoublev]

I think -webkit-order must become an alias of reading-order or layout-order. I think it does not really matter but can you please tell me which one?

[pepelsbey]

I think -webkit-order must become an alias of reading-order or layout-order. I think it does not really matter but can you please tell me which one?

-webkit-order is an alias to order, which will become a shorthand for reading-order and layout-order. As far as I understand, for example, setting order (or -webkit-order) shortcut to -1 will set layout-order: -1 and reading-order: 0. This way it will keep all existing orders and -webkit-orders from changing reading order.

So, there’s no need to change anything, apart from implementing these two new properties. Please correct me if I’m wrong.

[cdoublev]

What should be -webkit-order if you only declare reading-order or layout-order? Empty string?

[pepelsbey]

What should be -webkit-order if you only declare reading-order or layout-order? Empty string?

The same that’s already happening with animation, for example: the computed duration will be 0.5.

div {
  -webkit-animation: 1s name;
  animation-duration: 0.5s;
}

I checked it in Safari.

Or, specifically:

div {
  -webkit-order: -1;
  /* like you would set
    layout-order: -1;
    reading-order: 0;
  */
  layout-order: 1;
}

In non-supporting browsers element’s order would be -1, in the supporting ones 1.

[cdoublev]

I think I was wrong saying that it does not matter which sub-property -webkit-order should be an alias: imo, it should be an alias of layout-order because order currently changes the layout (visual) order but not the reading (focus) order, if I am not mistaken.

In non-supporting browsers element’s order would be -1, in the supporting ones 1.

I was thinking about this:

el.style.layoutOrder = 2
el.style.order; // ''
el.style.webkitOrder; // ?

A shorthand must serialize to empty string when it cannot represent all its longhands (CSSOM), so order must serialize to empty string. Legacy name aliases (like -webkit-order) require to replace the legacy name with the new property name (Cascade). So -webkit-order must also serialize to empty string if it is an alias of order.

In your example, -webkit-order would be replaced with order so -webkit-order cannot be -1.

Now I see no reason why someone would want to reflect layout-order on -webkit-order. The bidirectional mirroring is just a "happy" accident resulting from the legacy aliasing mechanism.

---

The issue also applies to -webkit-box-ordinal-group, which is currently a mapping to order. Imo, Compatibility should update it as a mapping to layout-order.

[fantasai]

@tabatkins suggested replacing [ reading-and-layout && <integer> ] with [ [ reading && layout ] && <integer> ] which folds the entire keyword-based grammar to an appropriately CSSy [ [ reading || layout ] && <integer> ] so I've gone ahead and done that in https://github.com/w3c/csswg-drafts/commit/a00550093461a75b54215f500f724c97dfa368b9

[dead-claudia]

BTW, this kind of feature could also offer a (moderately hacky) solution to being unable to effectively reorder animating nodes and such: https://github.com/whatwg/dom/issues/586#issuecomment-1420231217

[mreinstein]

Another example of the value of a constraint layout solver in css; not having to muck about with order properties.

Instead we kept bolting on never ending properties in the hopes that just one more will make layout not horrendous in css.

[deafninja]

While I believe to be a great solution, I think the problem with assistive technologies is how you get them to read the layout that is different from the source order though.

We all know that assistive technologies do NOT read the page but the source order as stated in your proposal so for assistive technologies to figure out a way to read the actual page order/layout I believe is going to be a tough ask.

I'm more inclined to have order be taken out totally from the equation honestly. While I do see benefits from using order (both grid and flexbox) I am in the camp where I believe causes more harm than good for assistive technologies thus authors should be implementing their source code semantically and in order of work flow.

My 2¢

[GideonCaspi]

Having read the Chrome blog write-up, this seems like a great idea that admittedly I haven't hit too much, but have wondered about its implications when I have.

My initial thoughts are that it would be useful for the defaults to solve most use cases so that the reading order follows the layout, rather than having to remember "when I change the rendering order of the source I also need to apply a few more new rules". The reading-order and focus-order rules would then be useful for intentionally following the CSS-defined layout if that's desired. This stems from a feeling that this should be handled automatically with available manual interventions for (presumably) rare cases that would want to follow the source order in visually modified layouts, in line with;

We could also consider making the default ordering visual in cases such as grid masonry layout, or auto-flow: dense where reordering is almost inevitable.

[NickGard]

Have there been considerations for enabling authors to retrieve the new focus/tab order from the DOM? A use-case for this is implementing something like a roving tab index. Imagine wanting to add arrow key listeners to move between cards (links) in a masonry layout where the whole grid is a single tab-stop.

Current solutions parse the DOM for focusable elements and assume they're in the correct visual order. These implementations are buggy when elements are reordered and without a way to get the visual/reading order from the DOM, they'll stay buggy after this change.

[rachelandrew]

We're adding this to the agenda to see if we can get agreement on the simplified approach discussed in https://github.com/w3c/csswg-drafts/issues/8589

I wrote this up as a blog post, which has examples of the two possible ways an author would invoke this ordering.

1. Randomized layouts (such as dense packing and masonry)
2. Non randomized layouts where the author is moving items away from the DOM order intentionally and wants the reading order to follow.

So the proposal is to keep reading-order: auto on the grid items of randomized methods, and to add a reading-order-items property for the grid or flex container, which is used in the non-randomized cases, allowing the author to explain their intent for the reading order.

We simplify by removing reading-order: <integer>, however this approach wouldn't prevent us from going down that line in the future if needed.

[css-meeting-bot]

The CSS Working Group just discussed [css-flexbox][css-grid] Providing authors with a method of opting into following the visual order, rather than logical order.

The full IRC log of that discussion

<emeyer> rachelandrew: The link in the minutes goes to a comment from the F2F
<emeyer> …I’m proposed a simplified approach for authors to follow the reading order rather than the document order
<emeyer> …We’re suggesting to remove the reading-order integer, written up in #8589
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/8589
<emeyer> …I got some author feedback and this seems to be good
<TabAtkins> q+
<emilio> q+
<emeyer> …We’d keep reading-order: auto and add reading-order: items
<Rossen_> q
<fantasai> s/reading-order: items/reading-order-items property/
<emeyer> …The latter would let you explain your intention for reading order
<rachelandrew> https://github.com/w3c/csswg-drafts/issues/8589
<rachelandrew> https://developer.chrome.com/blog/reading-order/#proposed-solution
<emeyer> jensimmons: Can you summarize where we are now? How would this work?
<emeyer> rachelandrew: If you have a randomized layout, like dense packing, people usually want the browser to follow the layout rather than the source order
<emeyer> …This happens with masonry as well
<PaulG_> Q+
<emeyer> …With auto, try to follow the reading order rather than the DOM order
<emeyer> …For things that are non-randomized, pretty much everything else, like grid and flex layouts with obvious order, the idea there is to keep the reading order auto on the items, but on the parent you do reading-order: items
<emeyer> …So if you’re reversing things in flex, you might say reading-order: items flex-flow
<emeyer> …In grid, you could say reading-order: items grid-row
<fantasai> s/reading-order: items/reading-order-items:/
<fantasai> s/reading-order: items/reading-order-items:/
<emeyer> …We realized even if you’ve laid out the items, it’s not always obvious what the correct reading order should be
<emeyer> …We think this should solve both these cases
<Rossen_> q?
<Rossen_> q+
<Rossen_> ack TabAtkins
<lea> Coming to this late, but what are the use cases beyond a) reading order = document order b) reading order = visual order. The integer syntax seems very low-level for the vast majority of cases to me, but again, I'm probably missing a lot as I haven't followed this
<emeyer> TabAtkins: I think the presence of reading-order: auto is a leftover from reading-order: <integer>
<emeyer> …I think we can drop that and rely on reading-order-items, is that right?
<emeyer> rachelandrew: I think so, yeah
<emeyer> TabAtkins: Presviously everything was auto by default undless overridden with an integer
<florian> q?
<florian> q+
<jensimmons> q+
<emeyer> …Now that we don’t have an everything could be reading-order-items
<emeyer> rachelandrew: Yeah, I’m keen to remove things that were canned
<iank_> +1 to tab
<emeyer> emilio: I was going to make that same point
<Rossen_> ack emeyer
<emeyer> …But this also seems to conflict with making displayed items focusable
<Rossen_> ack emilio
<emeyer> …I think that needs some more thought
<fantasai> s/displayed items/'display: contents'/
<emeyer> Rossen_: Is this in the presence of reading order??
<emeyer> emilio: Yeah, you need to define the order display: content elements appear
<emeyer> rachelandrew: I think for any of these methods, we probably need an issue for this
<emeyer> …NO matter what we do here, that’s going to be a problem
<emeyer> Rossen_: Please open an issue for this and link it to this one
<emeyer> emilio: Will do
<emeyer> …This is pretty blocking for me
<Rossen_> ack PaulG_
<emeyer> PaulG_: A question about RTL
<emeyer> …Is there a plan to support RTL for reading order?
<emeyer> rachelandrew: I don’t think this would change that, that would be the flow order
<emeyer> …This shouldn’t affect that
<emeyer> Rossen_: Agreed, we’re talking about the flex or grid directoin
<emeyer> rachelandrew: This follows whatever the flow direction is
<Rossen_> q?
<emeyer> PaulG_: My main concern was in random situations, where the assumption seems to be LTR
<Rossen_> q-
<emeyer> rachelandrew: If you’re in a flex layout, the default is LTR in an LTR language, and RRTL in RTL languages
<emeyer> …So I don’t think this would be an issue as presently laid out
<emeyer> fantasai: What is the value space of this property? In the writeups I found, there were examples of values, but I didn’t see a definition
<emeyer> rachelandrew: We haven’t written a spec yet, we’re trying to see whether we could achieve what authors want without needing to explicitly define each item in the order
<TabAtkins> I think proposal is `readering-order-items: normal | flex [ visual | flow ] | grid [ rows | columns ]`
<fantasai> ok, is that written anywhere other than your IRC comment? :)
<TabAtkins> nah, this is distilling the examples
<emeyer> …There was a bunch of suggestions in the original #8589, but I don’t think we’ve written everything out, which we’d need to do if this is the approach we want to take
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to ask about the value space
<jensimmons> q-
<emeyer> fantasai: It will be easier to understand the proposal if there was a little more formal writeup
<emeyer> …Second question, how does this interact with the `order` property?
<emeyer> rachelandrew: I believe we intend to follow that property if there’s an explicit `order` value
<emeyer> TabAtkins: This would change the tiebreaker behavior
<emeyer> fantasai: Right now, `order` does NOT affect reading order, its purpose is to allow breaking reading order from layout order
<TabAtkins> oh wait i think i got confused
<emeyer> …Are you intending to break that?
<TabAtkins> never mind, order just changes layout, and then reading-order keys into that layout
<Rossen_> Zakim, close queue
<Zakim> ok, Rossen_, the speaker queue is closed
<emeyer> …Are we using keywords that are going to implicitly change that behavior?
<emeyer> rachelandrew: I think if you set the `order`, why would you use `reading-order`? Using `order` diverges on purpose.
<jensimmons> q+
<emeyer> …The only reason you use `reading-order-items` is if you want to follow the layout
<Rossen_> q?
<emilio> (filed https://github.com/w3c/csswg-drafts/issues/9230)
<emeyer> …You can still use `order` as it is now, and wouldn’t use `reading-order-items`
<emeyer> …This is when you don’t want things out of sync
<emeyer> …I don’t think that’s an issue
<iank_> +1 to Rachel
<emeyer> …We do need to define what happens if there’s a conflict here
<emeyer> jensimmons: I can imagine a use case where the DOM order is great for desktop but on mobile you use `order` to rearrange
<emeyer> …You might want to apply `reading-order-items` to the mobile layout to fix the accessibility
<emeyer> Rossen_: Let’s get to the queue and close this at half past
<jensimmons> q?
<Rossen_> ack florian
<fantasai> fantasai: or not, whether to match order depends on what you're doing
<emeyer> florian: I’m not sure here, if we only have reading-order-items, then there’s only two options: follow visual layout, or don’t
<emeyer> …The proposed values are all variants of “follow the visual order”
<emeyer> …It just depends on the direction you take in following visual order
<emeyer> rachelandrew: What I would say is there are things that need to be worked out with this
<lea> fantasai: re:order vs visual-order, what if order becomes a shorthand of both?
<emeyer> …What I’d like to ask is the original question, which is do we need the reading order integer?
<fantasai> lea, see https://drafts.csswg.org/css-display-4/#display-order
<emeyer> …Are there use cases that absolutely require integer? Or can we simplify and then start to formally define how to resolve conflicts and such?
<fantasai> lea, but that doesn't fix the historic problem...
<emeyer> florian: Based on what you just said, I suspect we don’t need the interget
<emeyer> …I still think this is not going to be easy to define; there’s a lot of subtlety here
<lea> fantasai: thanks! "They are not intended (and should not be used) to apply semantic reordering operations." I'm confused, isn't semantic reordering the whole point of reading-order?
<emeyer> …There are a bunch of different ways you could iterate through a grid
<emeyer> …Not sure if we’ll only need a few values, or a whole lot of values to handle overlaps and such, or if we actually need integers
<fantasai> lea, e.g. don't use them for "I'm going to sort this column by last name"
<emeyer> Rossen_: Let’s redirect intot he issue, as there’s still quite a bit to be worked out
<fantasai> lea, reading order is still a _presentation order_
<emeyer> …Do we have enough convinction and understanding to resolve on dropping the integer value?
<emeyer> rachelandrew: I don’t think this is blocking, because if we drop <integer> now, we could add it back later
<emeyer> …We could say we don’t think we need it, and be open to adding it back in
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/8589#issuecomment-1690278747
<emeyer> jensimmons: I think it would be really helpful to have a document where everything’s all in one place
<fantasai> -> https://drafts.csswg.org/css-display-4/#display-order
<TabAtkins> (I think the above captures the rough draft proposal.)
<emeyer> fantasai: We do have a draft in the `display` spec
<emeyer> …I don’t want to take a resolution because I don’t understand what we’re trying to do here
<emeyer> Rossen_: Fair
<lea> fantasai: in that case, I do not understand what reading-order is, which I suspect means it will be incredibly hard to explain it to authors :/
<fantasai> /here/here. I would like a description of what we're trying to do, not three examples and "extrapolate what that means"/
<emeyer> …I think the conversation captures that we’re leaning toward not having an <integer>, but once the proposal is clear we can read and take a resolution