- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 11 Feb 2026 18:01:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-position-3] Containing block formed by fragmented inlines`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> iank_: I don't think the resolution is gonna be web compatible<br> <TabAtkins> fantasai: there were three proposals<br> <TabAtkins> fantasai: current behavior is we take top/left from the first fragment, and bottom/right from the bottommost/rightmost of all Fragments, make that the CB<br> <TabAtkins> fantasai: from Ian, proposal to change the CB based on what insets are set<br> <TabAtkins> fantasai: and a variation on that from the print people that's pretty similar<br> <TabAtkins> fantasai: we can dig into it, but q is if we *should* dig into what Ian is proposing<br> <flackr> q+<br> <TabAtkins> iank_: I don't know if I love my idea<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <astearns> q+ flackr<br> <TabAtkins> iank_: just that the current resolution breaks having an abspos at the end of a span, when the start of the span is further to the right on a previous line<br> <TabAtkins> iank_: I expect people might be relying on that to work<br> <TabAtkins> iank_: it might only work in wk/blink anyway<br> <TabAtkins> iank_: I don't love the resolution right now<br> <TabAtkins> iank_: my proposal might be too compat-risky<br> <TabAtkins> iank_: we can throw in some use counters<br> <astearns> ack flackr<br> <TabAtkins> flackr: possible idea - in other fragmentation contexts, we have the idea of using the pre-fragmented layout, then letting that content itself fragment<br> <TabAtkins> flackr: so in this case would be the unfragmented line span and then fragmenting that. does that work?<br> <TabAtkins> iank_: unfortunately we don't actually *use* fragmentation in the inline axis<br> <TabAtkins> iank_: that works in columns because we can actually fragment the abspos in the block direction<br> <TabAtkins> iank_: here, it's in the inline direction and abspos's generally can't do that<br> <TabAtkins> iank_: so you'd potentially end up with an abspos anchoring across multiple lines<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: for ian's proposal, I think it would boil down to: if one of the sides is auto, you find the fragment that has the opposite edge<br> <TabAtkins> fantasai: if your box is broken across two lines, with left:0;right:auto;, we find the first fragment and use its left/right positions, ignoring other fragments<br> <TabAtkins> fantasai: that would easily let people do fragmenting to the left edge of the first fragment.<br> <TabAtkins> fantasai: and similarly, with left:auto;right:0; we'd take the left/right from the last fragment<br> <TabAtkins> fantasai: that's a little weird in terms of spec history, but it seems like it would match author intent pretty well<br> <TabAtkins> fantasai: it leaves the q of what to do if you set left:0;right:0;<br> <TabAtkins> fantasai: maybe we take the bounding box at that point<br> <TabAtkins> iank_: that's a decent summary. some details to work out for the auto side, what edge do you use<br> <TabAtkins> iank_: that will affect stretch and fit-content<br> <TabAtkins> iank_: could use the bounding box on that side rather than the fragment's dimension<br> <TabAtkins> iank_: not sure<br> <TabAtkins> fantasai: I think the height, the block axis, should use the fragment size<br> <TabAtkins> fantasai: how large you report in the inline axis is interesting q<br> <TabAtkins> fantasai: should probably match either that fragmented, or the bounding box of the line<br> <TabAtkins> fantasai: if you have bidi stuff happening<br> <fantasai> TabAtkins: Agree, I wouldn't want an inline fragmented across columns to do something weird with the bounding box across columns<br> <fantasai> TabAtkins: so focusing on lines seems the right behavior to match the intent that we're going for<br> <TabAtkins> astearns: you mentioned the possibility of a use counter?<br> <TabAtkins> iank_: yeah, thinking about if it's useful, difficult to gather data<br> <TabAtkins> iank_: it'll likely overcount<br> <TabAtkins> iank_: and inline CBs are relatively common, but they often have just one or two fragments<br> <TabAtkins> iank_: display:inline is the default for unknown web components<br> <TabAtkins> astearns: at time, is there a resolution here, or back to the issue to more fully explore?<br> <TabAtkins> fantasai: I think we need to flesh out ian's proposal. it's roughly what we said here. we need definition for what if you set both, and what happens with block/inline split<br> <TabAtkins> astearns: then take back to the issue. if there's a full proposal we might be a ble to async<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8284#issuecomment-3886037562 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 February 2026 18:01:14 UTC