- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Apr 2025 13:42:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-overflow] `text-wrap-style` interaction with height-based `line-clamp` ``, and agreed to the following:
* `RESOLVED: balancing happens after determining the clamp point for 'balance'. ('pretty' is up to the UA)`
* `RESOLVED: if rebalancing causes the content to grow and overflow, the UA *must* step back (clamping a line earlier), and *may* rebalance again (and possibly step back again), but *must* end in a state that doesn't overflow.`
<details><summary>The full IRC log of that discussion</summary>
<flackr> your audio isn't working in the room<br>
<iank_> remote people can hear everything (including room)<br>
<astearns> 🎶<br>
<TabAtkins> andreubotella: we'd previously resolved that when you have text-wrap:balance in a paragraph that's in a line-clamp container<br>
<TabAtkins> andreubotella: line-clamp first clamps, then text-wrap balances<br>
<TabAtkins> andreubotella: now the q is what happens when you have line-clamp:auto and a height, which determines the clamp<br>
<TabAtkins> andreubotella: florian said earlier that you'd first do layout with tet-wrap:balance then clamp based on that<br>
<TabAtkins> andreubotella: i think that's accurate. but i'm not sure that will work, adn seems to go agaisnt what we previously resolved<br>
<andreubotella> https://codepen.io/andreubotella/pen/ByaOBMz<br>
<TabAtkins> andreubotella: so here if we have line-clamp:2 and balance<br>
<TabAtkins> andreubotella: so in the first, you wrap four items per line and clamp after the second.<br>
<florian> q+<br>
<TabAtkins> andreubotella: but in the second you have only balance, and you get three itmes per line. if you clamped at the second line you'd only see 6 items<br>
<TabAtkins> andreubotella: there's still a requirement that you don't grow<br>
<TabAtkins> andreubotella: [shows example where items that balance to the third row have a higher line-height, so if you didn't balance and they went to thes econd line, they'd grow the box]<br>
<TabAtkins> andreubotella: chrome's impl of text-wrap:pretty also only works on the lines before the clamp<br>
<TabAtkins> andreubotella: so it has the same limitations<br>
<astearns> ack florian<br>
<iank_> q+<br>
<TabAtkins> florian: i think we have three things we're trying to take into account<br>
<TabAtkins> florian: first, what does it look like when it's clamped<br>
<TabAtkins> florian: second, the clamping might be dynamic with the user hiding/revealing, so does it look reasonable when you hdie and show<br>
<TabAtkins> florian: third, try to keep the algo sensible<br>
<TabAtkins> florian: i think we ahd a discussion at tpac. what i wrote at the issue wasn't just my idea iirc, was partially consesnus<br>
<TabAtkins> florian: idea is you first do a regular layout (balance, pretty, etc), then you find the clamp point, discard remaining content, insert ellipsis on last line, then rebalance only the visible part<br>
<TabAtkins> florian: that last step was important, ian mentioned if you insert the ellipsis and dont' rebalance people can be upset<br>
<TabAtkins> florian: the ellipsis can unbalance that last line, especially if it's not just ...<br>
<TabAtkins> florian: so i think that was roughly the idea we were going for<br>
<TabAtkins> florian: if you do what's in Andreu's left example, when you unclamp it'll either dramatically rebalance, or not balance at all<br>
<TabAtkins> andreubotella: yeah, [shows off turning off clamp, it rebalances]s<br>
<TabAtkins> andreubotella: so this is what browsers do right now. tension between not reflowing when you hide/show, and the handling of stuff before the clamp<br>
<TabAtkins> andreubotella: in this case if you balance before clamp, then insert ellipsis, this does not look *un*balanced, but it look like there's more room for content<br>
<astearns> ack iank_<br>
<TabAtkins> iank_: the reason balancing is important after clamping is you can end up with very unbalanced lines, ignoring the ellipsis issue<br>
<TabAtkins> iank_: this was the first piece of feedback we got from people using the feature<br>
<astearns> q+<br>
<TabAtkins> iank_: we first balanced then clamped, and immediatley several users complained<br>
<TabAtkins> iank_: my pref here is just to layout initially without balance or pretty, then clamp, then apply balancing<br>
<TabAtkins> iank_: this also seems like something we can potentially change later<br>
<TabAtkins> iank_: all browsers have that behavior today and we haven't gotten negative feedback<br>
<TabAtkins> iank_: so my bias is to do nothing, keep the existing before (clamp before balancing), and if we get negative feedback we can chagne it<br>
<TabAtkins> astearns: when you say do initial layout, then clamp, then apply balancing<br>
<TabAtkins> astearns: you're balancing only the content that's been clamped?<br>
<TabAtkins> [yes, you balance the content that is visible after clamping]<br>
<TabAtkins> astearns: second question, for people who didn't like the lack of balancing, assuming they're okay with the reflow when you reveal what's after the clamp?<br>
<TabAtkins> iank_: yeah, we got feedback from pretty alrge sites, they do reveal, and didn't ahve negative feedback about that. maybe they haven't thought about it much, but they seem to hate the early balancing more<br>
<florian> q+<br>
<astearns> ack astearns<br>
<TabAtkins> iank_: other things that change height can change the layout, and that's ok, we are changing the height. all the elements areound it are growing and shrinking<br>
<andreubotella> q+<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: i think that makes sense, when you reveal you don't want to rebalance everything<br>
<jfkthame> q+<br>
<TabAtkins> fantasai: for pretty, in an impl where it affects all the lines having a reveal effect reflow the whole first half of the paragraph might be uncomfortable<br>
<TabAtkins> s/you don't/you do/<br>
<TabAtkins> fantasai: not sure the best answer, just noting the layout might have some hysteresis effect<br>
<TabAtkins> astearns: i think i disagree, the same reflow concerns apply to both balance and pretty<br>
<TabAtkins> astearns: the reflow might be an issue, but if it is, it's an issue for both<br>
<TabAtkins> fantasai: i think in the balance case the user will expect the reflowing, they expect it to be balanced in both cases, and that requires a reflow<br>
<TabAtkins> fantasai: but for pretty the effects are more subtle, and the user might not expect a reflow to cross that line<br>
<astearns> ack florian<br>
<TabAtkins> florian: adding to this, i have different levels of discomfort when you ahve a toggle - when you're doing it progressively like a height-based clamp<br>
<jfkthame> q-<br>
<TabAtkins> florian: if you drag progressively and reveal lines, the whole thing rejiggles and rebalances every time, that feels uncomfortable. some stability woudl be nice<br>
<TabAtkins> florian: i wonder if the gain from a progressive reveal might be worth it. but this isn't a hell i'm interested in staying in forver.<br>
<TabAtkins> florian: i'm just concerned by the progressive reveal case<br>
<TabAtkins> iank_: two things there<br>
<TabAtkins> iank_: depending on limits, we stop balancing after a certain number of lines anyway, so it'll become stable<br>
<TabAtkins> iank_: if you're dragging something, typically other things are reflowing on the page too, so keeping this one thing stable isn't as important i think<br>
<TabAtkins> iank_: but again, if we do get strong feedback in the opposite direction, this is potentially changeable<br>
<astearns> ack andreubotella<br>
<emilio> Yeah agreed this seems not very risky to change either way<br>
<TabAtkins> andreubotella: one thing i think we need to make sure we consdier is, if we have a first layout without balance, then use that for clamp, that shoudl not affect balanced paragraphs before that point. so if the clamp happens in the *second* paragraph it only affects that paragraph<br>
<TabAtkins> andreubotella: we don't want to disable text-wrap:balance in the first layout pass for everything, we just want to know the lines of the current paragraph without balancing<br>
<TabAtkins> andreubotella: don't know if what i said affects different impls, but i think it's something we should decide on<br>
<florian> q+<br>
<fantasai> +1 emilio<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: on the progressive reveal case, i think the user *would* expect rebalancing on each line, but for pretty they *woudln't* expect it<br>
<TabAtkins> fantasai: for ian's point about we only balance a few lines anyway, webkit balances unlimited lines, so that's not true across impls<br>
<TabAtkins> fantasai: re: tweaking later, i agree, and emilio does too. so we can pick what's best for now and adjust for user feedback, don't think it'll make a compat problem<br>
<TabAtkins> fantasai: but we should try to do the right thing from the beginning<br>
<TabAtkins> fantasai: so yeah for text-wrap:balance i do think we want it balanced at each point, and for pretty we want to allow the UA to maintain stability if they want to<br>
<TabAtkins> astearns: i do think we should be consistent<br>
<TabAtkins> astearns: we ahve the stable versions of text-wrap that are perfect for that gradual reveal without line jiggling<br>
<TabAtkins> florian: i agree with elika on this point, stable is about introducing text<br>
<astearns> ack florian<br>
<TabAtkins> astearns: i just mean "not balanced", auto included<br>
<fantasai> s/introducing/inserting/<br>
<TabAtkins> florian: okay. but it's about "does it look nice", and if you do balance, it's easy to look bad if you don't do what Ian is saying<br>
<TabAtkins> florian: but for pretty it probably doesn't look that bad.<br>
<TabAtkins> florian: it's not two-line headers, that's not what you apply pretty to<br>
<TabAtkins> florian: it's the beginning of an article<br>
<TabAtkins> astearns: i understand the article, but i disagree<br>
<iank_> I think we can just let pretty up to UAs for the moment<br>
<TabAtkins> astearns: i think people are using pretty to avoid orphans, and if we're not relaying out as pretty each time, you can end up with orphans on the clamped line<br>
<TabAtkins> astearns: so people will wonder why something isn't pretty<br>
<TabAtkins> florian: pretty isn't "avoid orphans"<br>
<TabAtkins> astearns: i know, but it's what people use it for now<br>
<TabAtkins> TabAtkins: [repeats Ian's line from IRC]<br>
<TabAtkins> fantasai: so it sounds like we want to specify that balancing is applied after clamping, not before<br>
<TabAtkins> andreubotella: and the interaction with clamping based on height<br>
<TabAtkins> andreubotella: so to what extent would it be okay to leave that impl-defined<br>
<TabAtkins> florian: i think we can say that *when* you do rebalancing after clamping, you don't re-check if your clamp point is fine after jiggling<br>
<TabAtkins> florian: you just keep using the initial clamp point<br>
<astearns> s/understand the article/understand the argument/<br>
<TabAtkins> florian: might need some bounds on your balancing argument, because a rejiggling might move tall items around to change the height<br>
<TabAtkins> florian: i think that's currently implied by the spec's note, but maybe not clear<br>
<iank_> i think for `height:auto` you can progressively step back the line-clamp line to get the correct behaviour<br>
<TabAtkins> florian: so a few resolutions. for balance, first clamp then balance. for pretty, up to the UA. in either case, the rearranging of lines that happen after clamping doesn't re-trigger clamping<br>
<TabAtkins> florian: if you calmp at 200px the rebalancing shoudln't give you 250px<br>
<TabAtkins> florian: so this needs to be taken into account<br>
<TabAtkins> TabAtkins: [describe's Ian's comment]<br>
<TabAtkins> fantasai: I think that's probably the right result for height-based clampding<br>
<TabAtkins> florian: I think we had earlier versions of balance/pretty that said it *couldn't* grow you rcontent<br>
<TabAtkins> florian: maybe we go back to that version when doing height clamping<br>
<TabAtkins> fantasai: i'm a little confused. if rebalancing grows your height, i think stepping back a line is what the author woudl expect<br>
<TabAtkins> fantasai: i think we could require that you're only required to do this step-back once<br>
<TabAtkins> andreubotella: one thing that could happen is that rebalancing could *shrink* your content and give space enough for another line, i think we don't want to add another line<br>
<TabAtkins> fantasai: right<br>
<TabAtkins> florian: do we want to specify step-back, or specify that you *can't* use a balancing that causes growth<br>
<TabAtkins> fantasai: that's very complicated<br>
<TabAtkins> florian: right, we ahd earlier text that said if rebalancing would move something to another line that changes the height, don't make that move<br>
<TabAtkins> fantasai: that's complicated, don't think we want to do it<br>
<TabAtkins> iank_: agree<br>
<TabAtkins> astearns: i think the earlier restriction on balancing is we couldn't change the number of lines, and we relaxed that. not sure we ever had a restriction on height.<br>
<TabAtkins> fantasai: okay i think we can take af ew resolution<br>
<TabAtkins> fantasai: proposed: balancing happens after determining the clamp point for 'balance'. ('pretty' is up to the UA)<br>
<TabAtkins> astearns: objections?<br>
<TabAtkins> RESOLVED: balancing happens after determining the clamp point for 'balance'. ('pretty' is up to the UA)<br>
<TabAtkins> fantasai: second thing is if rebalancing causes the content to grow past the clamp point (for height clamping), you're allowed to step back and redo clamping a line earlier (but you can't step forward if balancing added more space)<br>
<TabAtkins> fantasai: i think we should give discretion to the UA about how many cycles they have to do<br>
<TabAtkins> s/fantasai/florian/<br>
<TabAtkins> fantasai: no, you can construct a case where stepping back continues to cause problems<br>
<TabAtkins> florian: i think you can eventualky step back and *not* rebalance, that's better than rebalancing and overflowing<br>
<fantasai> TabAtkins: I see, agree. Agree that avoiding overflow is the most important<br>
<TabAtkins> fantasai: proposed: if rebalancing causes the content to grow and overflow, the UA *must* step back (clamping a line earlier), and *may* rebalance again, but *must not* overflow.<br>
<fantasai> s/rebalance/rebalance (and possibly step back again)/<br>
<TabAtkins> florian: as many rounds as the UA wants, but at the point where they give up, the state must be not overflowing.<br>
<dholbert> s/must not overflow/that rebalancing must not overflow/ I think?<br>
<TabAtkins> astearns: objections?<br>
<TabAtkins> RESOLVED: if rebalancing causes the content to grow and overflow, the UA *must* step back (clamping a line earlier), and *may* rebalance again (and possibly step back again), but *must* end in a state that doesn't overflow.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10827#issuecomment-2772608781 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 April 2025 13:42:45 UTC