- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Mar 2023 17:58:08 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-position-3] Containing block formed by fragmented inlines`, and agreed to the following: * `RESOLVED: Try out the proposal above, spec the fragmentation behavior` * `RESOLVED: in LTR-tb the top-left corner is the top-left corner of the top-left-most fragment of the first line, and the bottom and right edges are bottommost and rightmost edges of all the fragments. Directionality comes from the inline` <details><summary>The full IRC log of that discussion</summary> <emilio> scribenick: emilio<br> <fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E%3Cdiv%20style%3D%22background%3A%20gray%3B%20width%3A%20100px%3B%20height%3A%201em%3B%20display%3A%20inline-block%22%3E%3C%2Fdiv%3E%3Cspan%20style%3D%22position%3A%20relative%3B%20border%3A%20solid%20blue%22%3E%3Cspan%20style%3D%22position%3A%20absolute%3B%20inset%3A%200%3B%20border%3A%20orange%20solid%22%3E%3C%2Fspan<br> <fantasai> %3Efirst%20and%3Cbr%3Esecond%20line%20that%27s%20very%20long%20and%3Cbr%3Ethird%3C%2Fspan%3E%0A%3Cp%3E%3Cspan%20style%3D%22position%3A%20relative%3B%20border%3A%20solid%20blue%22%3E%3Cspan%20style%3D%22position%3A%20absolute%3B%20inset%3A%200%3B%20border%3A%20orange%20solid%22%3E%3C%2Fspan%3Efirst%20and%3Cbr%3Esecond%20line%20that%27s%20very%20long%20and%3Cbr%3Ethird%3C%2Fspan%3E<br> <emilio> fantasai: what do we do when the absolute positioned box is an inline but it spans multiple lines<br> <emilio> [describes test-case]<br> <emilio> ... firefox and chrome disagree<br> <emilio> ... so... on a single line the abspos cb is the line's bounds<br> <emilio> ... when it spans multiple lines we could use join the top-left of the first fragment and the bottom-right of the last<br> <emilio> ... but if the last line is to the left of the first it creates a negative area<br> <emilio> ... chrome / webkit collapse the width to zero<br> <emilio> ... firefox does [missing]<br> <emilio> ... there are pros and cons to both approaches<br> <emilio> ... the four things we think we can do are in the bullet list in the last comment<br> <fantasai> Use the first line's fragments only (so the entire containing block is contained by its generating box).<br> <fantasai> Anchor at the start/start corner of the first line box and extend to the end/end corner of the last line box, but clamp the inline size at zero (so the end/end corner might not overlap with a fragment).<br> <fantasai> Anchor at the start/start corner of the first line box and extend to the end/end corner of the last line box, and allow inversions (so the corners are pinned to actual fragment corners, but the containing block might end up between fragments).<br> <fantasai> Anchor at the start/start corner of the first line box and extend to the end/end corner of either the last line box (if that's endward of the start line) or of the first line box (otherwise).<br> <dbaron> There's some old discussion of this in https://bugzilla.mozilla.org/show_bug.cgi?id=489100 and maybe also the somewhat-related https://bugzilla.mozilla.org/show_bug.cgi?id=489207<br> <emilio> TabAtkins: my preferred behavior is to anchor the top left of top left of the first fragment, anchor bottom to the bottom of the last fragment, and anchor right to the right-edge of either the whole fragment, or line box edge if there are multiple<br> <emilio> ... allows cb to be as tall as the whole multi-line text box<br> <emilio> ... and also as wide as the whole text<br> <emilio> ... if there's text going further on later lines it'd be good to include that on the box left<br> <emilio> ... so top-left to top-left of first fragment (matches webkit + blink + ff)<br> <iank_> q+<br> <emilio> ... bottom matching blink/webkit<br> <emilio> ... and right edge to the right edge of line box (if multi-line) or end of fragment if it's single-fragment<br> <astearns> ack dbaron<br> <fantasai> ... rather than whereever the first fragment happened to break<br> <emilio> dbaron: this is something I thought about a good bit about a decade ago<br> <fantasai> Tab's proposal seems reasonable to me...<br> <emilio> ... two things I wanna point out<br> <emilio> ... one is that it's worth being reasonably careful about directionality<br> <emilio> ... I think we all do this based on the direction prop of the inline<br> <iank_> we've fixed stuff<br> <emilio> ... iirc chrome didn't handle rtl well but edge did<br> <emilio> ... related issue issue is: how do auto-offsets behave for absposes inside inlines<br> <emilio> ... maybe it's not that related but there are a few interesting aspects to it<br> <astearns> ack iank_<br> <astearns> q+<br> <emilio> iank_: worth retesting Chrome because we've fixed a lot of these<br> <emilio> ... one thing to note is the start and end is complicated, because the IFC can have different direction to the inline CB<br> <emilio> ... I _believe_ we use the direction of the IFC<br> <TabAtkins> Yeah, I'd think the IFC is probably the most coherent thing to take the directions from?<br> <emilio> ... we don't necessarily want to do that but it makes sense given all the edge cases<br> <emilio> ... when you say linebox we don't quite want that<br> <emilio> ... you probably want the max IFC inline edge coordinate<br> <emilio> ... because you can have multiple fragments in one line<br> <emilio> ... and those might not go at the end of the line box<br> <emilio> TabAtkins: if the inline starts at the left edge of the text area and it covers multiple lines the CB should fill the box<br> <emilio> ... even if if the actual text bounds is slightly narrower<br> <emilio> iank_: you can have the situation where the span won't go all the way to the inline edge but there may be some text there<br> <emilio> ... but it is different<br> <emilio> ... I think tab's proposal seems fine<br> <emilio> astearns: I don't like something about tab's proposal, which is the difference for the determination for the start and end edge<br> <emilio> ... I think it'd make sense to also take the smallest start edge<br> <emilio> iank_: I doubt that'd be compatible<br> <emilio> ... that's interoperable now, it's used to do something like a caret at the start of an inline<br> <emilio> TabAtkins: that's why<br> <emilio> astearns: It's just a weird result where the orange box covers half of the paragraph in fantasai's<br> <astearns> ack dbaron<br> <emilio> ... test-case<br> <astearns> ack astearns<br> <emilio> TabAtkins: yeah, but it's very interoperable behavior, so I think we're stuck with that<br> <iank_> there is :)<br> <emilio> dbaron: Are there complications here when the inline is split across columns/pages?<br> <emilio> iank_: there are, I can talk about what edge did here, but that's a long tangent<br> <emilio> TabAtkins: so we do ???<br> <astearns> ack dbaron<br> <TabAtkins> s/???/still anchor the top-left of the CB to the top-left of the first fragment there?/<br> <emilio> dbaron: I think the issue of splitting over columns / pages is one of the reasons this never got fixed in Gecko<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to discuss this right-edge criteria<br> <emilio> ... but might also be more about the auto behavior<br> <astearns> q+<br> <emilio> fantasai: Wanted to talk about about what we pin the right edge to<br> <emilio> ... end of the first line's last fragment?<br> <emilio> ... rightmost of all of the lineboxes?<br> <TabAtkins> My instinct is that if there's a column/etc break, we put the bottom edge to the end of the last fragment in that fragmentainer, analogous to the right-edge behavior.<br> <emilio> ... rightmost of all the fragments?<br> <emilio> ... line boxes have different edges with floats<br> <iank_> From my perspective right most of either the line-boxes or the fragments<br> <emilio> ... do we want to consider all of the lines? Or just the first?<br> <emilio> iank_: pretty strong bias towards all of the lines<br> <emilio> ... covers the case where all of the lines might not line up<br> <TabAtkins> Ah, I see what you mean by "probably don't want lineboxes" then, yeah<br> <TabAtkins> right edge fo the IFC or whatever, instead, yeah<br> <TabAtkins> +1 to rightmost/bottommost of all fragments<br> <emilio> fantasai: my proposal would be to use the rightmost edge of all of the fragments of the inline box<br> <emilio> astearns: hard time coming with a use case for doing much more than what FF is doing<br> <emilio> ... the case of putting a caret at the beginning of the line is the thing we can't change<br> <emilio> ... what use case is there for having an abspos thing going over some weird section of a fragmented inline?<br> <emilio> TabAtkins: there's no use case for doing both of the horizontal/vertical bounds we're defining<br> <emilio> ... but each individually make sense<br> <emilio> iank_: someone willing to cover all of the lines<br> <emilio> fantasai: that's only useful if the span is the first thing in the line<br> <TabAtkins> 1) Putting something at the start of the text (requires top/left to be the top left of the first fragment). 2) Have something as tall as the text (background, or overlay, etc).<br> <emilio> iank_: true<br> <TabAtkins> I think those are the two use-cases we can reasoanbly address with a single-box solution.<br> <emilio> astearns: I worry that we're coming up with this thing that isn't really motivated by use cases<br> <emilio> ... we're defining some reasonable behavior for this edge case where a lot of cases we could get the abspos cb further up<br> <emilio> ... firefox's behavior seems simpler to spec and doesn't run into fragmentation issues<br> <TabAtkins> +1<br> <emilio> iank_: we have a solution for fragmentation<br> <TabAtkins> (+1 to Ian, that is)<br> <emilio> ... but somewhat hard<br> <emilio> ... probably don't have time on this call to consider it<br> <emilio> ... I think we should consider at least all of the lines' block edges<br> <iank_> (i've got to run š)<br> <emilio> fantasai: proposal is that that in LTR-tb the top-left corner is the top-left corner of the top-left-most fragment of the first line, and the bottom and right edges are bottommost and rightmost edges of all the fragments<br> <dholbert> bottom right of all-of-the-fragments, or all-of-the-line-boxes-that-contain-fragments? (if there's a <br> that prevents the fragments from hitting the end of the line)<br> <emilio> RESOLVED: Try out the proposal above, spec the fragmentation behavior<br> <TabAtkins> (afaict, the use-cases I listed are already satisfied by Chrome/WebKit's behavior, since neither of them depend on the right side. But I do think a zero-width box should be avoided if we can.)<br> <dbaron> (also need to be clear whether that LTR-tb is for the IFC or the inline)<br> <fantasai> analogously for other writing modes, anchoring on the same writing mode as the painting of borders<br> <emilio> fantasai: I think you want the writing-mode of the inline element, e.g. if you want a flag at the start of the span<br> <emilio> emilio: iank_ was arguing for writing-mode of the IFC<br> <dholbert> (my question relates to a distinction that Tab was making early on; we should be clear whether we're talking about line boxes vs. fragments for bottom-right corner. Sorry, my audio seems to be broken)<br> <emilio> proposal for dholbert's question is using the fragments themselves<br> <dholbert> thanks!<br> <emeyer> I have an uneasy feeling about the proposed solution, but Iām not sure I understand it properly..<br> <fantasai> Using fragments, because if you have short lines of text you want the edges of those inlines, not the far right of the screen<br> <emilio> RESOLVED: in LTR-tb the top-left corner is the top-left corner of the top-left-most fragment of the first line, and the bottom and right edges are bottommost and rightmost edges of all the fragments. Directionality comes from the inline<br> <fantasai> see testcase on borders: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3EThis%20%3Cspan%20dir%3Drtl%20style%3D%22border%3A%20solid%22%3Etest%3Cbr%3Eborder%3C%2Fspan%3E%3C%2Fp%3ERESOL<br> <TabAtkins> emeyer, top/left/bottom edge all match Chrome's current behavior, right edge is the rightmost of *all* fragments (rather than just the first, like what FF currently does, or the last-but-clamped, like Chrome currently does)<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-1460601033 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 March 2023 17:58:10 UTC