-
Notifications
You must be signed in to change notification settings - Fork 649
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-display-4] Do we need reading-order: <integer>
or should reading-order: auto
be allowable in all grid or flex layouts?
#8589
Comments
The other part of the discussion on Monday was the idea that there are multiple ways one could want to auto-order certain layouts. A flexbox might want to go in flex order (source order 'order'), or in logical order (start from the startmost flex line, and the startmost item in it, then proceed, so 'flex-direction' and 'flex-wrap' also affect things). A grid might want to be read in column-major order or row-major order. Etc. It sounds like that's something that would be indicated on the container itself. So I think my proposal is that we should keep the current spec as written, but add a property on the container ( |
And by "we can extend it" I mean we should add at least one keyword per major layout type right now - block, table, flex, grid. This allows authors to get the "just do it right" behavior, but doesn't allow them to just set it on |
@tabatkins so in the case of having (for example) |
Right, exactly. (And it would do nothing on, say, a flexbox.) And for a non-ridiculous name suggestion, maybe |
Yeah This still leaves us with the question as to whether we need Could we initially drop |
As a developer I'm totally ok to first have only the auto options (and I'm ok with “one keyword per major layout type” limitation) and dropping the integer for now. I think there might be use-cases for the integers, but it can be quite a complicated issue, where things should be thought through quite extensively in order to replicate the mistakes of a tabindex, stacking context etc. So better to first have something that would work for more simple cases, and in the meantime see how the more complex cases could be handled. |
I don't really get when anyone would need the reading order to be different on individual children. It seems simpler (and shorter and easier to remember the property name) to just have The |
Proposed syntax:
In either of the latter cases, the 'order' property is taken into account, just like any other flex/grid layout property that affects where the element ends up. So an (Do we want a "DOM order, but let Per issue discussion, the |
I think this works.
So that would give the options:
That seems useful, and worth adding. |
Some comments:
|
It would be very nice to just add a @fantasai I would expect order to change the reading order too because it changes the visual order and I've requested the reading order to follow the visual order. There are uses for manually diverging visual and reading order but that should be a separate dial to turn. |
I'm not sure quite what you mean by this. In the flex/grid cases, DOM order is already completely lost. Other than its incidental effects on how elements get automatically ordered, there's nothing left there. Visual order inherently and necessarily is post- In the "DOM order, but let order take effect as well" example I was asking about, it would also be an intentional opt-in.
This is the |
We can't do this, unfortunately. There simply isn't a single correct answer for the elements that have this ability. We also somewhat want to encourage this to be something you think about a little bit. We don't need much, but it's good to have some deliberateness. |
It doesn't need to be a single correct answer it just needs to be a better default than the status quo. If there were a |
While I like giving power to the designer/developer, I think we should strive towards keeping this simple, without excessive options. I also think we should decouple Having a separate I also think we shouldn’t have values like So my proposed syntax is:
Value meanings:
As mentioned above, I can’t really imagine a likely case in which you would want to read or tab in a direction that is opposite of the reading mode/direction. So in English, if you are reading by column (because of e.g. |
I had a look through the initial examples of this that developers had raised (under examples from the community n the initial issue). The things people are wanting to do seem solved by the proposed solution. Tweaks, for example to form layout, when source is not modifiable. This isn't an ideal use, and advice would be to reorder the HTML where possible, but people are going to do this sort of thing. However this could be solved by changing the layout in grid then asking the reading order to follow that order. Different layouts for different screen sizes. This is the use case that comes up most often, and is solved by the current suggestion, assuming the grid layout is adjusted in the media/container query and the Deliberate reordering, where you want the source and display order to be different and this tweet still works as now, as you just don't use I can't think of, nor have I encountered from the community, an instance where we need |
Also, to respond to @bradkemper we are only considering doing this in flex and grid contexts. I don't think there's a compelling need to do this outside of those contexts. Yes you can disconnect the source and reading order by abspos etc. but I've not seen people having the issues there that they have with grid and flex layouts. This only came up as a developer request once we had layout methods that allowed easy reordering. |
I think we would be totally fine without the numeric order.
I expect this could potentially be more of an issue with anchor positioning and with Popover API used for it, where the anchor and its popover (or an anchor and a sidenote as in the other use case for anchor positioning) could be separated. I did create a separate issue to tackle this: #9356 — not sure if the |
The CSS Working Group just discussed
The full IRC log of that discussion<TabAtkins> rachelandrew: WE're trying to solve a problem with flex and grid<TabAtkins> rachelandrew: Devs can easily jumble up the order of things, reading and visual order different from the DOM <TabAtkins> rachelandrew: But DOM order is used by tabbing/etc <TabAtkins> rachelandrew: It's usually correct to tell authors to make the DOM order match the visual order <TabAtkins> rachelandrew: There are some cases where it doesn't tho <TabAtkins> rachelandrew: Like, responsive design - optimal reading order in one presentation is different from optimal order in another <TabAtkins> rachelandrew: So people want to shuffle things by MQ <TabAtkins> rachelandrew: We're tyring to solve this by letting authors specify the reading order, when it's differetn from the DOM <TabAtkins> rachelandrew: This particular issue, elika proposed a `reading-order: <integer>` <TabAtkins> rachelandrew: This would specifically set the reading order to match <TabAtkins> rachelandrew: As we worked thru the use-cases we realized devs probably didn't need it <TabAtkins> rachelandrew: Instsead they just want "follow the flex layout" or "follow the grid layout" <TabAtkins> rachelandrew: But there are still some switches on that <TabAtkins> rachelandrew: So here Tab proposed to remove the integer and instead have `reading-order-items: normal | flex [ visual | flow ] | grid [ rows | columns ]` <TabAtkins> rachelandrew: I think this covers all the use-cases <TabAtkins> rachelandrew: I think it also wouldn't stop us from doing the integer in the future <TabAtkins> rachelandrew: If we realize we need it <TabAtkins> rachelandrew: So issue is, can we resolve to drop the integer and just use reading-order-items? <TabAtkins> q <TabAtkins> Janina: Interesting! Sounds like we might get our cake and eat it too. <TabAtkins> Janina: previous discussions entangled benefits of various ways to handle it, without solving things <TabAtkins> rachelandrew: I think so, it keeps things in CSS <TabAtkins> rachelandrew: With flex and grid layout you *know* you're changing the order. Layout itself can change it. So you know you're doing it, and can trigger reading-order-items <matatk> q? <TabAtkins> matatk: Did you say default is DOM order, that's what normal does? <TabAtkins> rachelandrew: yes <TabAtkins> matatk: There's usually an auto value, why not here? <TabAtkins> astearns: One reason for normal vs auto is normal often has a single default behavior, while auto responds to various things <TabAtkins> astearns: So someone might interpret auto to mean "if I have a grid, do grid order" <astearns> ack TabAtkins <emeyer> TabAtkins: I think this is fine but there’s a necessary followup issue <emeyer> …We resolved that if you display: contents an A, the things inside A should still be tabbable <emeyer> …That interacts badly with the non-normal values here <emeyer> …We need to define something to fix that <emeyer> …I suggest the right answer is it should be put after either first or last in DOM order <emeyer> …If we need something more later, we could add integer back in <ydaniv> q <TabAtkins> matatk: I think with any of these technical things, Paul is our css expert. Paul hasn't commented on this issue. <TabAtkins> matatk: I'd feel better getting his opinion on it <TabAtkins> matatk: But the general principle feels good - the author can choose a sensible layout <astearns> ack ydaniv <TabAtkins> matatk: And we definitely don't encourage people to use positive tabindex values - we all know why - so this sounds good in general <TabAtkins> ydaniv: I'm a bit confused about the syntax <TabAtkins> ydaniv: If you end up with a grid layout, and the dev specifies flex, what would that do? would we want 'auto' instead? <TabAtkins> rachelandrew: I think it just wouldn't apply? <TabAtkins> TabAtkins: Yeah I think it would just act like normal <TabAtkins> astearns: So all the non-normal values would just not apply if they're not in the right layout context <TabAtkins> rachelandrew: Similar to alignment, yeah <TabAtkins> ydaniv: But doesn't the element already know the context? <jensimmons> There's a good question there, though. Why do `grid`, `flex`, etc, instead of having values like `layout` — where the browser knows whether it should be grid layout or flex layout. <TabAtkins> astearns: Rachel can elaborate, but I think the idea is that normal's the default, but it's not always the case that the visual reordering in a grid layout is appropraite for the a11y tree <TabAtkins> astearns: So there are cases where grid layout should not be the reading order <emilio> q <TabAtkins> rachelandrew: I think the intentionality is really specific to this, you <emeyer> TabAtkins: The m ore targeted answer is that we don’t have one correct behavior for flex, or for grid <emeyer> …I don’t think we can generally assume what the values imply <astearns> ack emeyer <emeyer> …Either of the cases for grid are common enough, and the results of getting it wrong bad enough, should require authors to say what they want <astearns> ack emilio <TabAtkins> emilio: The idea is that this modifies taborder <TabAtkins> emeyer: Do we ahve use-cases for a11y reorder, but not taborder? <emeyer> s/emeyer/emilio/ <TabAtkins> fantasai: I don't think so, I think we resolve a while ago that reading order and tab order should be in sync <TabAtkins> rachelandrew: i haven't been able to come up with any use-cases either <astearns> ack fantasai <TabAtkins> fantasai: I think there's a little bit more going on here. <TabAtkins> fantasai: Multiple ways to cause reordering to happen in grid <TabAtkins> fantasai: grid-auto-flow which controls how auto-placed items get palced (row or column, and probably reversible in the future) <TabAtkins> fantasai: Also the 'order' property <TabAtkins> fantasai: And lastly there's the visual/coordinate order with explicit placement <TabAtkins> fantasai: I think it's quite reasonable you'll have a grid where you are mixing some of these mechanism, some auto-placed items and some explicitly placed <TabAtkins> fantasai: And depending on how you're performing these, you may or may not want to follow the "visual order" - the writing-mode order I'll say, ltr, ttb for english <TabAtkins> fantasai: So there can be a mix of things that can happen and i think we're maybe not addressing what happens in these complex bits <TabAtkins> fantasai: Might want to follow auto-flow but also 'order' is purely a visual effect <TabAtkins> rachelandrew: I feel like if we came across those cases where author needs to be able to specify all of them <TabAtkins> rachelandrew: I don't know if integer would solve those cases anyway <TabAtkins> rachelandrew: And generally I only see people doing that when they've made a mistake <florian> q <TabAtkins> rachelandrew: So I think we might bea ble to find edge cases where it doesn't support <TabAtkins> rachelandrew: But if we find them and decide we need to fix them, we're not blocked from fixing them <TabAtkins> rachelandrew: But the stuff I'm being asked about by devs is very simple <TabAtkins> rachelandrew: They just want reading order "correct" so they can swap placement between mobile and desktop <TabAtkins> rachelandrew: And what we have here will enable those. We can address more cases as we realize we need it. <astearns> ack florian <TabAtkins> I think th ecurrent grammar is plenty extnesible, too <TabAtkins> florian: I think the high level takeaway is we're giving a switch telling the browser what mode it's in to traverse <TabAtkins> florian: For typical patterns <TabAtkins> florian: If we find more atypical patterns we can do an escape, but we're not there yet <TabAtkins> florian: Speculating on the atypical patterns today won't be too instructive <TabAtkins> Janina: I find this encouragin, we've been wrestling with it for a while <TabAtkins> astearns: So proposed resolution is we drop reading-order:<integer> and go with reading-order-items with the values proposed in TAb's comment (for now) <TabAtkins> fantasai: I think it's fine to draft it up <TabAtkins> fantasai: I don't know I'm confident this is definitely the way to go <TabAtkins> fantasai: So let's draft it into the ED, I'm just not 100% it's how we want to finish <TabAtkins> fantasai: I don't like it to imply that this is what we're going for definitely <TabAtkins> rachelandrew: I think we do need something firm to start moving forward on <fantasai> proposal: Draft reading-order-items into the ED for css-display-5 <TabAtkins> rachelandrew: We're not blocking the integer method <TabAtkins> astearns: and drop reading-order:<integer> for now? <TabAtkins> fantasai: I guess so <TabAtkins> astearns: So proposed resolution is to add reading-order-items into the ED and remove reading-order:<integer> <TabAtkins> astearns: Objections? <TabAtkins> RESOLVED: add reading-order-items into the ED and remove reading-order:<integer> |
Draft is now in the ED, and other comments have been captured as new issues. |
This issue relates to the edits to CSS Display 4 based on this dicussion, and the as-yet unmerged PR at #8257.
TL:DR is that we are wondering if we only need
reading-order:auto
(on the children) and if there are reasons to doreading-order: <integer>
at all, or initially. Do compelling enough use cases exist to have that level of control or do people really just want to follow the layout?Longer notes below:
My original suggestion was a switch on the grid/flex container. In that scenario all of the following would follow the grid or flex modified order:
In the existing edits plus this PR, the reading-order: auto value is applied to the children, and only covers:
"randomized grid layouts" with dense packing (and I'm assuming masonry)
To do the following you would need
reading-order: <integer>
on the children:There are definitely use cases for people wanting to follow the layout created by placement (usually because they want different layouts at different responsive breakpoints), so if we only do auto as specced, we don't have a method to achieve those use cases, and if we go for the switch on the container that likely stops us doing this version later.
An alternative, however, would be if the only value for
reading-order
wasauto
(applied to the children) and auto applied in all layout types, not just the randomized ones. As that shouldn't roadblock us from adding the integer value in the future.Reading order and layout order being separated, is a use case. For example, this, but I think in that case, if we went with auto applied everywhere that doesn't need to affect layout-order with no reading-order.
I feel that having the property on the children is better than my idea of a switch on the parent (though I guess we could then add a switch on the parent that sets them all as a group, as with align-items), because it allows for more flexibility, but I think we could get away with that initially being auto only.
The text was updated successfully, but these errors were encountered: