- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Aug 2023 16:35:31 +0000
- To: public-css-archive@w3.org
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`. <details><summary>The full IRC log of that discussion</summary> <emeyer> rachelandrew: The link in the minutes goes to a comment from the F2F<br> <emeyer> …I’m proposed a simplified approach for authors to follow the reading order rather than the document order<br> <emeyer> …We’re suggesting to remove the reading-order integer, written up in #8589<br> <fantasai> -> https://github.com/w3c/csswg-drafts/issues/8589<br> <emeyer> …I got some author feedback and this seems to be good<br> <TabAtkins> q+<br> <emilio> q+<br> <emeyer> …We’d keep reading-order: auto and add reading-order: items<br> <Rossen_> q<br> <fantasai> s/reading-order: items/reading-order-items property/<br> <emeyer> …The latter would let you explain your intention for reading order<br> <rachelandrew> https://github.com/w3c/csswg-drafts/issues/8589<br> <rachelandrew> https://developer.chrome.com/blog/reading-order/#proposed-solution<br> <emeyer> jensimmons: Can you summarize where we are now? How would this work?<br> <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<br> <emeyer> …This happens with masonry as well<br> <PaulG_> Q+<br> <emeyer> …With auto, try to follow the reading order rather than the DOM order<br> <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<br> <emeyer> …So if you’re reversing things in flex, you might say reading-order: items flex-flow<br> <emeyer> …In grid, you could say reading-order: items grid-row<br> <fantasai> s/reading-order: items/reading-order-items:/<br> <fantasai> s/reading-order: items/reading-order-items:/<br> <emeyer> …We realized even if you’ve laid out the items, it’s not always obvious what the correct reading order should be<br> <emeyer> …We think this should solve both these cases<br> <Rossen_> q?<br> <Rossen_> q+<br> <Rossen_> ack TabAtkins<br> <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<br> <emeyer> TabAtkins: I think the presence of reading-order: auto is a leftover from reading-order: <integer><br> <emeyer> …I think we can drop that and rely on reading-order-items, is that right?<br> <emeyer> rachelandrew: I think so, yeah<br> <emeyer> TabAtkins: Presviously everything was auto by default undless overridden with an integer<br> <florian> q?<br> <florian> q+<br> <jensimmons> q+<br> <emeyer> …Now that we don’t have an everything could be reading-order-items<br> <emeyer> rachelandrew: Yeah, I’m keen to remove things that were canned<br> <iank_> +1 to tab<br> <emeyer> emilio: I was going to make that same point<br> <Rossen_> ack emeyer<br> <emeyer> …But this also seems to conflict with making displayed items focusable<br> <Rossen_> ack emilio<br> <emeyer> …I think that needs some more thought<br> <fantasai> s/displayed items/'display: contents'/<br> <emeyer> Rossen_: Is this in the presence of reading order??<br> <emeyer> emilio: Yeah, you need to define the order display: content elements appear<br> <emeyer> rachelandrew: I think for any of these methods, we probably need an issue for this<br> <emeyer> …NO matter what we do here, that’s going to be a problem<br> <emeyer> Rossen_: Please open an issue for this and link it to this one<br> <emeyer> emilio: Will do<br> <emeyer> …This is pretty blocking for me<br> <Rossen_> ack PaulG_<br> <emeyer> PaulG_: A question about RTL<br> <emeyer> …Is there a plan to support RTL for reading order?<br> <emeyer> rachelandrew: I don’t think this would change that, that would be the flow order<br> <emeyer> …This shouldn’t affect that<br> <emeyer> Rossen_: Agreed, we’re talking about the flex or grid directoin<br> <emeyer> rachelandrew: This follows whatever the flow direction is<br> <Rossen_> q?<br> <emeyer> PaulG_: My main concern was in random situations, where the assumption seems to be LTR<br> <Rossen_> q-<br> <emeyer> rachelandrew: If you’re in a flex layout, the default is LTR in an LTR language, and RRTL in RTL languages<br> <emeyer> …So I don’t think this would be an issue as presently laid out<br> <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<br> <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<br> <TabAtkins> I think proposal is `readering-order-items: normal | flex [ visual | flow ] | grid [ rows | columns ]`<br> <fantasai> ok, is that written anywhere other than your IRC comment? :)<br> <TabAtkins> nah, this is distilling the examples<br> <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<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to ask about the value space<br> <jensimmons> q-<br> <emeyer> fantasai: It will be easier to understand the proposal if there was a little more formal writeup<br> <emeyer> …Second question, how does this interact with the `order` property?<br> <emeyer> rachelandrew: I believe we intend to follow that property if there’s an explicit `order` value<br> <emeyer> TabAtkins: This would change the tiebreaker behavior<br> <emeyer> fantasai: Right now, `order` does NOT affect reading order, its purpose is to allow breaking reading order from layout order<br> <TabAtkins> oh wait i think i got confused<br> <emeyer> …Are you intending to break that?<br> <TabAtkins> never mind, order just changes layout, and then reading-order keys into that layout<br> <Rossen_> Zakim, close queue<br> <Zakim> ok, Rossen_, the speaker queue is closed<br> <emeyer> …Are we using keywords that are going to implicitly change that behavior?<br> <emeyer> rachelandrew: I think if you set the `order`, why would you use `reading-order`? Using `order` diverges on purpose.<br> <jensimmons> q+<br> <emeyer> …The only reason you use `reading-order-items` is if you want to follow the layout<br> <Rossen_> q?<br> <emilio> (filed https://github.com/w3c/csswg-drafts/issues/9230)<br> <emeyer> …You can still use `order` as it is now, and wouldn’t use `reading-order-items`<br> <emeyer> …This is when you don’t want things out of sync<br> <emeyer> …I don’t think that’s an issue<br> <iank_> +1 to Rachel<br> <emeyer> …We do need to define what happens if there’s a conflict here<br> <emeyer> jensimmons: I can imagine a use case where the DOM order is great for desktop but on mobile you use `order` to rearrange<br> <emeyer> …You might want to apply `reading-order-items` to the mobile layout to fix the accessibility<br> <emeyer> Rossen_: Let’s get to the queue and close this at half past<br> <jensimmons> q?<br> <Rossen_> ack florian<br> <fantasai> fantasai: or not, whether to match order depends on what you're doing<br> <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<br> <emeyer> …The proposed values are all variants of “follow the visual order”<br> <emeyer> …It just depends on the direction you take in following visual order<br> <emeyer> rachelandrew: What I would say is there are things that need to be worked out with this<br> <lea> fantasai: re:order vs visual-order, what if order becomes a shorthand of both?<br> <emeyer> …What I’d like to ask is the original question, which is do we need the reading order integer?<br> <fantasai> lea, see https://drafts.csswg.org/css-display-4/#display-order<br> <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?<br> <fantasai> lea, but that doesn't fix the historic problem...<br> <emeyer> florian: Based on what you just said, I suspect we don’t need the interget<br> <emeyer> …I still think this is not going to be easy to define; there’s a lot of subtlety here<br> <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?<br> <emeyer> …There are a bunch of different ways you could iterate through a grid<br> <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<br> <fantasai> lea, e.g. don't use them for "I'm going to sort this column by last name"<br> <emeyer> Rossen_: Let’s redirect intot he issue, as there’s still quite a bit to be worked out<br> <fantasai> lea, reading order is still a _presentation order_<br> <emeyer> …Do we have enough convinction and understanding to resolve on dropping the integer value?<br> <emeyer> rachelandrew: I don’t think this is blocking, because if we drop <integer> now, we could add it back later<br> <emeyer> …We could say we don’t think we need it, and be open to adding it back in<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/8589#issuecomment-1690278747<br> <emeyer> jensimmons: I think it would be really helpful to have a document where everything’s all in one place<br> <fantasai> -> https://drafts.csswg.org/css-display-4/#display-order<br> <TabAtkins> (I think the above captures the rough draft proposal.)<br> <emeyer> fantasai: We do have a draft in the `display` spec<br> <emeyer> …I don’t want to take a resolution because I don’t understand what we’re trying to do here<br> <emeyer> Rossen_: Fair<br> <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 :/<br> <fantasai> /here/here. I would like a description of what we're trying to do, not three examples and "extrapolate what that means"/<br> <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<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1690281298 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 August 2023 16:35:33 UTC