w3c
[css-overflow] Can you line-clamp by both a number of lines and a height at the same time?
The line-clamp property is defined as a shorthand for three longhands, one of which is max-lines, which says that the clamp point should be after a particular line. You can also remove the max-lines property (or set the shorthand to line-clamp: auto) and set max-height to clamp by a height.
With the continue: discard approach that was currently in the spec at the time of writing, the clamping is based on fragmentation, and max-lines adds a region break. So if you have both max-lines and max-height and the content overflows before the specified line, it will clamp based on the height.
However, as we just resolved, line-clamp will instead default to the continue: collapse approach (see #7708) which isn't based on fragmentation. So should that have the same behavior when clamping by both a number of lines and a height?
In our implementation in Chromium, when we started working on it we decided to not support clamping by both, to focus the implementation effort to the simple cases. But maybe at this point it makes sense to reconsider this.
I would support the ability of both working at the same time. The ability to say "up to 5 lines, or 100px, whichever is smaller" seems useful. You may also be constraining the height through grid layout or what not. Here too, it seems that as long as you've turned clamping on, if you'd end up overflowing in the block direction, it's better to clamp a little earlier, rather that to overflow and then clamp somewhere down in the overflow.
We recently implemented this in Chromium, but we unintentionally made this also apply to -webkit-line-clamp without needing to turn experimental features on, and so far we got feedback from two developers who are relying on -webkit-line-clamp with a (max-)height on their sites, and who would be affected by this change (https://issues.chromium.org/issues/436345865). We don't yet have any broader web compat data (especially since this change hasn't yet reached stable, and we plan to fix it before then), but it might be that this would need yet another difference between the prefixed and unprefixed shorthands.
The CSS Working Group just discussed [css-overflow] Can you line-clamp by both a number of lines and a height at the same time?, and agreed to the following:
-
RESOLVED: line-clamp: <integer> with a height constraint clamps by height or by lines, depending on what comes earlier, pending compat issues
The full IRC log of that discussion
<JoshT> andreubotella: [shares slides]<JoshT> ... when we looked at line-clamp, this was not the approach we would take in other browsers
<JoshT> ... you can have a fragment. the first fragment has a forced breakup. if you move the height so it breaks before the line where it breaks, the content moves into the second fragment
<JoshT> ... but does the line clamp still apply?
<JoshT> ... when I was prototyping this, we understood it to be clamping by lines or height but not both at the same time
<JoshT> ... I didn't realise that this was not the agreed approach until in april F2F
<JoshT> ... I implemented this recently and have no problem with it being in the spec
<JoshT> PROPOSED: line-clamp: <integer> with a height constraint clamps by height or by lines, depending on what comes earlier
<JoshT> ... height constraint means height, max-height, etc.
<JoshT> ... could be a constraint through the intrinsic layout
<JoshT> ... we accidentally shipped this behaviour in Chrome 140 and it was reported as a regression by two devs
<JoshT> ... we reverted the change and have added use counters for line-clamp with height constraints
<JoshT> ... we hope to have useful data in December
<JoshT> ... I asked those devs what their use cases were
<JoshT> ... for one, their use case would not be affected by this change
<florian> q+
<JoshT> ... it is possible we might need to not do this for the -webkit-line-clamp. we will know in December
<JoshT> florian: In general, I support proposal
<JoshT> ... if you have ten lines, you ask for four, you cut off at three, I think this is better
<JoshT> ... if we are constrained by compat, I would be sad but OK having a difference between -webkit- and non-prefixed
<JoshT> ... if the breakage is bad, we can do a difference in behaviour
<JoshT> fantasai: I agree with florian. I had some questions
<Kurt> https://issues.chromium.org/issues/436345865#comment23
<JoshT> ... if only one line fits, we should make that line doesn't get clamped
<JoshT> ... it seemed like in one case, they had a line height of 1em and a line clamp of 3 lines and a max-height of 3
<JoshT> ... in theory, there should be no conflucts between these two unless you have substancial content
<JoshT> ... there are often small difference in line hieght which can create a small amount of overflow not visible to the author
<florian> q+
<JoshT> ... so we might need some slack when working out whether to push over a line to the next fragment
<JoshT> andreubotella: do you expect a difference between just line-clamp or with height as well when calculating slack
<JoshT> fantasai: not sure. maybe we do that. if it's something that's weird that we have to do for web compat, maybe we do have the difference for the -webkit- prefixed version
<JoshT> ... it might end up being something reasonable
<JoshT> florian: I can't see how we make it work. there is not clamp by height.
<JoshT> ... the height you set is with regular height properties or the layout system
<JoshT> ... so I don't think we can give slack to the actual height
<JoshT> ... you could let content overflow just a little bit
<JoshT> ... I was wondering if instead of clamping or sizing, could this be about what we have in the css inline layout spec
<JoshT> fantasai: yes could be related. we will have to see
<JoshT> ... if we get a lot of cases where this is an actual problem and the maths doesn't work out
<JoshT> PROPOSED: line-clamp: <integer> with a height constraint clamps by height or by lines, depending on what comes earlier
<JoshT> RESOLVED: line-clamp: <integer> with a height constraint clamps by height or by lines, depending on what comes earlier, pending compat issues
Here's the text from the slides I presented in the discussion:
- When
(-webkit-)line-clampwas initially spec’d, it was defined in terms of fragmentation (continue: discard) - The line-clamp container created a fragmentation context, and any fragments other than the first one were discarded
-
line-clamp: 5created a forced break after the fifth line
(Interactive demo, which you can find at https://codepen.io/andreubotella/pen/empbjjM)
(The demo shows a fragmentation container, where the first fragment would be shown, and the rest are grayed out, representing fragments that would be discarded. The content has a forced break after the fifth line, which pushes content after it to the following fragments, which will be discarded. You can resize the height of the container, and when the fifth line will not fit in that height, it will be pushed to the following fragment, discarding it. Therefore, clamping by lines and height falls directly out fragmentation in continue: discard.)
- Now
line-clampusescontinue: collapse, which hides the content after clamp - When I was initially prototyping
continue: collapse, I understood the goals to be clamping by lines, and by height, but not both at the same time- I also initially took clamping by both out of the initial prototype because I expected it might be harder to implement
- Eventually this understanding made its way into the current implementation in Chromium, and into the spec text
- In the April F2F, Florian and Elika were surprised that this behavior was not in the spec
Proposal: line-clamp: <integer> with a height constraint clamps by height or by lines, depending on what comes earlier
Possible web compat issues
- We accidentally shipped this behavior by default for
-webkit-line-clamp(without experimental web platform features) in Chromium 140 Canary. - This was reported as a regression. In the issue, two developers said this would break their sites.
- We reverted this change before Chrome 140 shipped, and will add use counters for uses of
-webkit-line-clampwith height constraints in Chrome 141- We’ll have useful data in December
- https://issues.chromium.org/issues/436345865#comment23
Reopening this due to high use-count with the existing feature (~4% of page loads, on a large variety of sites).
Andreu added a use-counter for this case - and its very high for existing content.
Basically a lot of sites will use line-clamp: 2; font-size: 24px; height: 48px; (or similar), and due to fonts ascent/descent being large it'll overflow the container.
IMO web a web-developer has asked to clamp by lines, we should only honor that, and ignore the height constraint. This would mitigate the compat concern (which exists even for the un-prefixed variant of this feature due to auto-prefixers), and match web-developer expectations closer. IMO its would be very difficult to explain to a web-developer what is occuring in this cause if they get clamped at one line, when they explicitly asked for 2.
We shoudn't diverge the behaviour of the prefixed, and unprefixed variant of this feature unless we have a very good reason to do so - as it'll just cause developer confusion.
Agenda+ to change resolution to only clamping by lines in this situation.
Ian
We shoudn't diverge the behaviour of the prefixed, and unprefixed variant of this feature unless we have a very good reason to do so - as it'll just cause developer confusion.
I agree with this.
Agenda+ to change resolution to only clamping by lines in this situation.
Are you proposing the current prefixed behavior (clamp to two lines, but respect height) or something new (clamp to two lines, but ignore height and use a larger height?).
If it's the first one sounds good. If it's the later one I think that'd be unfortunate?
Are you proposing the current prefixed behavior
The current prefixed behaviour - clamp at two lines, and ignore height for the purposes of clamping at a potentially lower line-count (respect height like normal for sizing purposes).