- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Sep 2024 23:31:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-inline-3] text-box-trim vs fragmentation `. <details><summary>The full IRC log of that discussion</summary> <astearns> q+<br> <andreubotella> fantasai: I was chatting with Jen Simmons about how text-box-trim interacts with fragmentation. We have a discussion about setting text-box-trim in a box in the flow that gets fragment, but not on the multicol element. There's a lot of column boxes inside it, should it apply to any of them?<br> <andreubotella> Probably makes sense to apply to the first and last line box in each column<br> <andreubotella> assuming there's no intervening padding or borders<br> <chrishtr> +1<br> <miriam> +1<br> <andreubotella> frivoal: makes sense to me<br> <andreubotella> astearns: I know of a use case where we'd want to trim all of the top and bottom (?) of a column except for the very first and last. But we can handle that with the :column element<br> <andreubotella> frivoal: I'm aware of that for trimming margins, but this issue is about trimming the top and bottom of lines. Is that correct as well?<br> <andreubotella> astearns: You might be right that it might apply only to margins. There might also be a usefulness for lines. But yes, it should apply only to the top and bottom if it applies to multicolumn<br> <andreubotella> bfgeek: My concern is that if applied to the end, it might shorten the column box, which might change the fragmentation point<br> <andreubotella> fantasai: When fragmenting, you'd have to be aware of whether the line box to add to a page is trimmed or not<br> <astearns> ack astearns<br> <andreubotella> bfgeek: It's more complex, because of interactions with collapsing margins at the end<br> <andreubotella> I dont' know if this is implementable for end trimming<br> <andreubotella> frivoal: In this issue we're talking about trimming leading in lines, does that also affect?<br> <dholbert> q+<br> <andreubotella> astearns: We might need some make-forward-progress algorithm where you decide where the fragmentation break is, then apply the trimming, and not reconsider the break<br> <andreubotella> fantasai: It's similar to when trying to see if something fits, you truncate the margins. If there are borders or padding, you already cannot trim. It's different between line boxes and at the end of the element, so when you evaluate whether you fit, you trim the line box<br> <andreubotella> if additional content fits, then you move forwards<br> <andreubotella> frivoal: it's clear it's desirable, but not clear how doable. Can we edit it later if it's too hard?<br> <andreubotella> fantasai: I think that's reasonable. Because margins are invisible, it doesn't matter whether you consider the box trim or not. It's only when placing the content and checking wherther it fits before the end of the page is when you need to consider trimming<br> <andreubotella> bfgeek: What is the behavior with empty elements that are after this?<br> <andreubotella> If there's a subsequent empty element. That's not considered (?) if there's an empty element afterwards<br> <andreubotella> That's complex because we don't want to arbitrarily look forwards to see if this is the last<br> <andreubotella> fantasai: If the bottom edge of my box is 1em from the bottom of the page, but it has a bottom-margin of 2em<br> <andreubotella> we truncate the margin to the extent necessary to make it fit<br> <astearns> ack dholbert<br> <andreubotella> dholbert: when fantasai was talking about how it works in practice, discounting the text-box-trim for the purposes of seeing if the element fits, should it also make the element draw a smaller border box if it happens to fit when this is taken into account?<br> <andreubotella> should the border box extend to the bottom of the column?<br> <andreubotella> s/border box/background/<br> <andreubotella> fantasai: do you mean a block background or an inline background?<br> <andreubotella> dholbert: if the line of text has a background, i'm thinking of a span that has a background<br> <andreubotella> ...<br> <andreubotella> fantasai: as an author, you don't want to combine text-box-trim with a block background<br> <andreubotella> in the long term, we might want to have a control for this, similar to margin-trim for margins, but this would be the default<br> <fantasai> s/margin-trim/margin-break/<br> <andreubotella> astearns: should we specify the behavior as florian suggested, and reopen the issue if there are implementability concerns? or do we take it back to the issue for now?<br> <andreubotella> fantasai: I think this is what people would want if they set text-box-trim on multicolumn. The alternative is it doesn't apply at all<br> <andreubotella> frivoal: If it applies only to the first column, it's worse because you have unbalanced columns<br> <andreubotella> astearns: any objections, dholbert and bfgeek?<br> <andreubotella> bfgeek; there's some complexity because, the way it works we'd need to backtrack. For example, you place a line box, there's 10px of space remaining. You need to lay out the next line box, because it might only be 8px<br> <andreubotella> But if it's 12px high, you need to backtrack and go to the previous line box, and then trim it, which is a bit scary<br> <andreubotella> you don't know if it's the last line box until you lay out the next line<br> <andreubotella> frivoal: Having it only apply to the first column and not the others will be ugly. In general, for the problem, if we only trim at the first column it's bad<br> <andreubotella> same for printing and pagination, if you have a multi-page document, you want the top and bottom to match<br> <andreubotella> bfgeek: At the minimum we'd want trim-top. I'll talk to Morten to see how feasible is trimming the bottom if we have to backtrack<br> <andreubotella> fantasai: Once you've decided that the line box fits, you can forget about whether you trimmed it. It only matters if you drew a background, and if you do, you have the question of where it ends<br> <andreubotella> You have to make sure the background doesn't go beyond the fragmentainer edge<br> <andreubotella> bfgeek: It affects more things than that<br> <andreubotella> astearns: We should table the discussion of how it should work for now. bfgeek, are you okay having the conversation with Morten before resolving?<br> <andreubotella> bfgeek: yeah<br> <andreubotella> frivoal: Can we resolve to do it on the start side and leave the end side open?<br> <andreubotella> astearns: We'll discuss that next time<br> <dholbert> fwiw the "in what ways is the column-end-trimming observable [and how do we need to tidy up after ourselves after placing that line]"is the bit that I'm wondering about too<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5335#issuecomment-2330321072 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 September 2024 23:31:22 UTC