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