- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Mar 2025 18:00:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-display-4] reading-flow and mix of auto-flow and explicit items `, and agreed to the following: * `RESOLVED: Add a source-order value to reading-flow.` * `RESOLVED: reading-flow: source-order works on block containers. reading-order applies to block-level boxes, and not to inline-level boxes` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> TabAtkins: last time we discussed thre was a question about whether reading order is the one that explicitly sets an element to a particular spot<br> <kbabbitt> ... rather than relying on visual stuff<br> <kbabbitt> ... should work without opting into one of the other explicit reading flow values<br> <kbabbitt> ... whether it should be explicit or implict etc<br> <kbabbitt> ... authors had opinions in thread<br> <kbabbitt> ... the idea of having a reading-flow value that does no reordering by default but just gives side effects<br> <hober> fs<br> <kbabbitt> ... sounds perfectly reasonable<br> <kbabbitt> ... we didn't do this before because just tab-index was the side effect<br> <kbabbitt> ... but with reading order in display now it makes sense to have a reading-flow value that does no implicit reordering<br> <kbabbitt> ... just reordering that author asked for<br> <kbabbitt> ... we do however feel strongly that it needs to be a new keyword<br> <kbabbitt> ... rather than a default behavior that can trigger anytime an eleement has reading order<br> <kbabbitt> ... fantasai was suggesting that if any element has reading order it automatically makes parent into a reading flow container<br> <kbabbitt> ... emilio disagreed on perf implications<br> <kbabbitt> ... can't tell if something is a reading-flow container just from element itself<br> <kbabbitt> ... grid with a whole bunch of autoflow children can be an expenseive operation<br> <kbabbitt> ... I think becoming a reading flow container has side effects<br> <kbabbitt> ... having a child with reading order would implicitly apply side effects to siblings<br> <kbabbitt> ... this would happen if you have the same markup several times on a page or across multiple pages<br> <kbabbitt> ... only some have a reading order child or have a reading order child that is hideable<br> <kbabbitt> ... will change whether side effects apply to everything else<br> <kbabbitt> ... seems not great, just as hard for authors to predict as stated concern<br> <kbabbitt> ... that authors would not be able to predict whether reading flow works by default<br> <kbabbitt> ... so we are pretty strongly against reading flow working by default for these reasons<br> <kbabbitt> ... should instead opt into reading order<br> <kbabbitt> ... fantasai's third point in response was forward compatibility<br> <kbabbitt> ... if reading order automatically turns on reading flow containers, that only works if everything can be a reading order container<br> <kbabbitt> ... or if we fix the set of block types that can ever be reading order containers<br> <kbabbitt> ... otherwise others could set reading order on a block which would do nothing today<br> <kbabbitt> ... we could define it in the future and it would turn on suddenly causing side effects that they don't expect<br> <kbabbitt> ... fantasai suggested we could go ahead and define block-level reading flow right now in trivial case of no reordering<br> <kbabbitt> ... we're not super comfortable with that<br> <kbabbitt> ... display:block order is going to be complicated anyway<br> <kbabbitt> fantasai: I don't think so, we're not proposing to add new visual order<br> <kbabbitt> ... just saying you can have normal flow order and also apply reading order different from source order<br> <kbabbitt> ... you ahve an order that's the source order, you don't have a magic order, just saying reading order shoulda pply to source order like in a flexbox<br> <kbabbitt> ... don't think floats etc. introduce any more complexity<br> <kbabbitt> ... just as simple as a flexbox that doesn't have any order properties<br> <kbabbitt> chrishtr: almost a no-op?<br> <kbabbitt> fantasai: no because if you set reading order on... eg. I have a section with a heading and a couple of paragraphs<br> <kbabbitt> ... if I set reading order -1 on the heading it would pull up the heading above the paragraphs<br> <kbabbitt> ... no magic about floats, because that would require a new value for reading-flow<br> <kbabbitt> ... which would be magic block reordering something<br> <kbabbitt> ... we're not suggesting that<br> <kizu> present-<br> <emilio> q+<br> <kbabbitt> TabAtkins: it does sound like a potentially doable behavior for block but our opinion is still towards not triggering by defau;t<br> <kbabbitt> ... our ideal conclusion would be to add a no-op value that just makes something a reading flow container<br> <astearns> ack JoshT<br> <kbabbitt> ... and doesn't do anything else special<br> <kbabbitt> ... define that it works for everything<br> <kbabbitt> ... not everything because we still want tables to be handleable in a different way<br> <kbabbitt> ... so define it for blocks and call it a day<br> <kbabbitt> fantasai: this gets into another issue about initial value of reading-flow<br> <kbabbitt> ... next issue<br> <kbabbitt> ... having initial value being smarter than sort order<br> <kbabbitt> ... adding new value that is strict source order<br> <kbabbitt> ... with those two, the strict source order could be the value we use here<br> <astearns> q+<br> <kbabbitt> emilio: agree with TabAtkins<br> <kbabbitt> ... did we decide whether reading order affects a11y tree as well?<br> <kbabbitt> fantasai: yes<br> <kbabbitt> emilio: I don't know exact order of abspos and floats right now<br> <kbabbitt> ... but presumably that would get more tricky<br> <iank_> I think this property only applies to in-flow elements?<br> <kbabbitt> ... e.g. does the float get ordered... in source order?<br> <kbabbitt> fantasai: if we apply to blocks, when floats come out of flow that's a visual effect<br> <kbabbitt> ... does not affect reading order<br> <kbabbitt> ... would be there as if not floated<br> <kbabbitt> emilio: ok that seems fine<br> <kbabbitt> ... I would expect containing block to ? the order<br> <astearns> ack emilio<br> <astearns> ack astearns<br> <kbabbitt> fantasai: in the future maybe we want to do something fancy with floats<br> <kbabbitt> astearns: in the proposal where reading order works without reading flow, is it the case that if you set reading order on an element that will make the nearest block-level parent a reading flow container?<br> <kbabbitt> TabAtkins: yes<br> <kbabbitt> fantasai: yes<br> <kbabbitt> astearns: very limited utility with markup I'm used to working with where things can get wrapper elements<br> <kbabbitt> ... caption goes above picture until someone decides caption needs a wrapper element<br> <kbabbitt> ... then it stops working as intended<br> <kbabbitt> fantasai: don't think you can introduce a ? that hoists things out of the tree<br> <kbabbitt> astearns: yes. I think this is an argument for TabAtkins' position<br> <kbabbitt> fantasai: don't think that would change situation in your case<br> <kbabbitt> ... if reading order ?? it's still not going to move<br> <kbabbitt> ... you still have to set it on child that you're trying to reorder<br> <kbabbitt> ... if reading order is not set on the elements you want to reorder that are siblings<br> <kbabbitt> ... nothing is going to happen<br> <astearns> s/on child/on the direct child/<br> <kbabbitt> ... question is whether or not you need something on the container, not going to make a difference here<br> <kbabbitt> ... reason TabAtkins wants it is to make sure author is opted into the side effects<br> <fantasai> s/the side/the tabindex side/<br> <kbabbitt> TabAtkins: that's the big part, also if we go with your suggestion we could never introduce a more complex behavior<br> <kbabbitt> ... might be something we never need but I feel like if we explore block cases more we might want to do something like that<br> <kbabbitt> ... uncomfortable with shutting off that possibility<br> <kbabbitt> fantasai: if you were going to reshuffle the tree...<br> <kbabbitt> ... order property doesn't work like that<br> <kbabbitt> TabAtkins: but order property only works with flex and grid which are explicit about container child relationship<br> <kbabbitt> ... uncomfortable shutting off possibility of better block reordering strategy<br> <kbabbitt> fantasai: how would that work? extract element outside container?<br> <kbabbitt> TabAtkins: don't know<br> <kbabbitt> ...there's some meat on that bone though<br> <kbabbitt> ... because as astearns said, it's common to have wrapper elements<br> <kbabbitt> fantasai: if you introduce wrapper elements the reading order property will be on outermost wrapper<br> <kbabbitt> ... a number of properties that you want to set on outermost wrapper, reading order is one of them<br> <kbabbitt> TabAtkins: discussion got mixed with next issue<br> <kbabbitt> fantasai: swap issues or stay on this one?<br> <kbabbitt> TabAtkins: we can get some resolutions on this one<br> <kbabbitt> ... can resolve on a no-op container ? value, a source order value or something<br> <kbabbitt> fantasai: need that for both issues<br> <kbabbitt> chrishtr: not to choose a name, say there is a value<br> <kbabbitt> TabAtkins: happy to resolve on that<br> <kbabbitt> astearns: Proposed resolution is to add a source order value to reading-flow property<br> <fantasai> PROPOSED: Add a source-order value to reading-flow.<br> <kbabbitt> RESOLVED: Add a source-order value to reading-flow.<br> <kbabbitt> fantasai: Proposed: reading-order applies to block-level elements, does not apply to inline-level elements<br> <kbabbitt> TabAtkins: such that source-order value points to it?<br> <kbabbitt> fantasai: that's the third question<br> <kbabbitt> TabAtkins: not yet whether it applies by default or not<br> <fantasai> PROPOSAL: reading-order applies to block-level boxes, and not to inline-level boxes. (Note this will work under source-order, and not e.g. flex-*/grid-*)<br> <TabAtkins> reading-flow:source-order works on block containers. reading-order works on block children of those block containers that are opted in to reading-flow<br> <fantasai> PROPOSAL: reading-flow: source-order works on block containers. reading-order applies to block-level boxes, and not to inline-level boxes<br> <kbabbitt> astearns: objections?<br> <fantasai> RESOLVED: reading-flow: source-order works on block containers. reading-order applies to block-level boxes, and not to inline-level boxes<br> <kbabbitt> astearns: anything more we can resolve on?<br> <kbabbitt> chrishtr: that it has to be explicit?<br> <kbabbitt> astearns: that is the sticking point<br> <kbabbitt> TabAtkins: resolution as it stands says implict stuff doesn't work<br> <kbabbitt> ... right now only explicit works<br> <kbabbitt> fantasai: we can take that back to the issue<br> <kbabbitt> chrishtr: come back to this issue next week for 3rd point<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11208#issuecomment-2701683923 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 March 2025 18:00:16 UTC