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

@bkardell

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:

@chrishtr

@chrishtr

Agenda+ to discuss and resolve on reading-order as proposed #7387 (comment). 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?

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.

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?

@elika

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//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//issues/7387#issuecomment-1217193918
<jcraig> fantasai proposed a more refined order @@@elika help?@@@
<fantasai> rachel's use case analysis is here: https://github.com//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//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//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

[css-display-4] Initial draft copied from L3, adding w3c#7387

[css-display-4] Initial draft copied from L3, adding 'reading-order' w…

[css-display-4] Inline background logic from issue into a note #7387

[css-display-4] Define 'reading-order: auto' w3c#7387

Drafted up css-display-4 ED with reading-order and layout-order longhands for order as outlined in #7387 (comment).
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.

[css-display-4] Define 'reading-order: auto' #7387 #8257

[css-display-4] Define 'reading-order: auto' w3c#7387

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?

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.

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

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.

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.

[css-display-4] Initial draft copied from L3, adding 'reading-order' w…

[css-display-4] Inline background logic from issue into a note w3c#7387

[css-display-4] Use combinatorial keywords instead of 'reading-and-or…

[css-display-4] Define 'reading-order: auto' w3c#7387

[css-display-4] Use combinatorial keywords instead of 'reading-and-or…

[css-display-4] Define 'reading-order: auto' w3c#7387

[css-display-4] Use combinatorial keywords instead of 'reading-and-la…

@tabatkins

@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 a005500

BTW, this kind of feature could also offer a (moderately hacky) solution to being unable to effectively reorder animating nodes and such: whatwg/dom#586 (comment)

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¢

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.

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.

We're adding this to the agenda to see if we can get agreement on the simplified approach discussed in #8589

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

Randomized layouts (such as dense packing and masonry)
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.

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//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//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//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//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

Navigation Menu

Repository navigation

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

Problems

Visual/tab order disconnect for keyboard users

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

Proposal

Alternate approaches and related work

An HTML attribute

CSS Spatial Navigation

Open UI: focusgroup

Research and further reading

Examples from the community

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Problems

Visual/tab order disconnect for keyboard users

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

Proposal

Alternate approaches and related work

An HTML attribute

CSS Spatial Navigation

Open UI: focusgroup

Research and further reading

Examples from the community

Activity

aardrian commented on Sep 16, 2022

chrishtr commented on Sep 16, 2022

cookiecrook commented on Sep 27, 2022

css-meeting-bot commented on Sep 28, 2022

fantasai commented on Dec 23, 2022

cdoublev commented on Jan 12, 2023

pepelsbey commented on Jan 12, 2023

cdoublev commented on Jan 12, 2023

pepelsbey commented on Jan 12, 2023

cdoublev commented on Jan 13, 2023

fantasai commented on Jan 19, 2023

dead-claudia commented on Feb 7, 2023

mreinstein commented on Apr 19, 2023

deafninja commented on Apr 19, 2023

GideonCaspi commented on Apr 20, 2023

NickGard commented on Apr 23, 2023

rachelandrew commented on Jul 18, 2023

css-meeting-bot commented on Aug 23, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions