[css-overflow-4] line-clamp max-lines - support auto value to fit container

[yairEO]

Feature request

Spec links

• https://drafts.csswg.org/css-overflow-4/#propdef--webkit-line-clamp
• https://drafts.csswg.org/css-overflow-4/#propdef-line-clamp

Currently -webkit-line-clamp property only supports an integer number which represents the maximum
number of lines to possibly render before truncating the text with an ellipsis.

I have a use-case where I need an dynamic value for the -webkit-line-clamp so it matches the
number of lines which can fit in the container (which is being truncated), assuming the container
has a dynamic height.

Also important - nothing should be painted past the ellipsis point (unlike today when the container's height is set to a value greater than the height of the truncated lines)

Example:

https://jsbin.com/kovuwow/edit?html,css,output

<div>
  Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt 
  ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco 
  laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in 
  voluptate velit esse cillum dolore eu fugiat nulla
</div>

div {
  display: -webkit-box;
  -webkit-line-clamp: auto; /* 👈 keyword to let line-clamp according to the container */
  -webkit-box-orient: vertical;
  overflow: hidden;
  resize: auto;
}

If you want line-clamp to (show N lines that can) fit the container element, it is currently impossible:

line-clamp--auto-value.mp4

Javascript-based solution

I've hacked this using (a lot of) javascript: https://codepen.io/vsync/pen/eYbGgGL

line-clamp--auto-value.mp4

---

Related StackOverflow questions:

• https://stackoverflow.com/q/51816862/104380
• https://stackoverflow.com/q/71145324/104380

[SebastianZ]

If I am not mistaken, this use case is already covered by continue: discard in combination with block-ellipsis: auto.

Though it looks like this can't be set via the shorthand line-clamp yet. So I suggest to change its syntax so setting the max-lines value is not required.
I think it is not necessary to add direct control over continue but instead set it to discard in case a block ellipsis is set.

So I suggest to change the syntax to

none | [ <integer [1,∞]>? <'block-ellipsis'>? ]!

With that change, one could write line-clamp: auto (with auto standing for the block-ellipsis value) to achieve the above.

Sebastian

[frivoal]

If I am not mistaken, this use case is already covered by continue: discard in combination with block-ellipsis: auto.

Correct.

So I suggest to change the syntax to

none | [ <integer [1,∞]>? <'block-ellipsis'>? ]!

Seems reasonable to me.

[frivoal]

cc: @andreubotella @fantasai

[andreubotella]

none is a valid value for block-ellipsis, so with this syntax there would be no way to represent a height-based clamping without ellipsis. That might be fine, though.

[andyearnshaw]

FYI @yairEO you can sort of do this in pure CSS now, but you need to provide container queries for a fixed number of lines. Here's an example:

https://codepen.io/AndyE/pen/xxmeXKM

[SebastianZ]

none is a valid value for block-ellipsis, so with this syntax there would be no way to represent a height-based clamping without ellipsis. That might be fine, though.

Right, but for that case authors can still use the longhands. Alternatively, they could provide an empty string for the block-ellipsis to achieve the same effect.

Sebastian

[SebastianZ]

The syntax proposal for line-clamp I made earlier got some positive feedback. So it seems to be uncontroversial. So maybe we can resolve on that.

Sebastian

[yairEO]

I really hope this tiny easy change, with a lot of potential for the web, will be implemented ASAP

[SebastianZ]

I really hope this tiny easy change, with a lot of potential for the web, will be implemented ASAP

The syntax change to line-clamp is small, yes. And I also wish for it landing in browsers soon. Though to set expectations, implementors are very hesitant to add line-clamp and its longhands so far, because it seems generally hard to implement. From what I understand, this is mostly due to #7708.

Sebastian

[astearns]

Given that this is just allowing in the shorthand something useful that’s already possible with the longhands, and the consensus in the discussion so far, I think this is reasonable to resolve asynchronously.

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: Change the line-clamp shorthand syntax to allow omitting the max-lines value

[astearns]

RESOLVED: Change the line-clamp shorthand syntax to allow omitting the max-lines value

[cdoublev]

@frivoal, I think the second alternative should be wrapped in [...]!, otherwise an empty value would be valid:

- Value: none | <<integer [1,∞]>>? <<'block-ellipsis'>>?
+ Value: none | [ <<integer [1,∞]>>? <<'block-ellipsis'>>? ]!

[Loirooriol]

Yes the grammar should use !

[frivoal]

I've always thought that there was an implicit ! on the whole value syntax definition of every property, so that it wasn't necessary to include in cases like this one. If not, I agree it should be added, but given that empty values are never valid, and based on "what else could it possibly mean", it seems we'd be better off adopting that convention if we haven't already.

So, should I add a ! here, or should we clarify in css-values that it's implied in cases like that, or do we already have that somewhere?

cc: @fantasai @tabatkins

[fantasai]

I think the correct answer here is to use ||. :) There's no reason for these two values to not be reorderable.

(This side-steps your question about !... frankly it's never come up before.)

[cdoublev]

The meaning of line-clamp: 1 "..." seems slightly easier to understand than line-clamp: "..." 1 but || would give the choice to the author, at least.

It seems awkward to accept an empty value in a property value definition but reject it implicitly as a convention. And from an implementation perspective, things like @supports (line-clamp: ), line-clamp: !important, --custom: , require a little extra work.

[Loirooriol]

@frivoal Empty values are valid on custom properties, since they have grammar <declaration-value>?

CSS.supports("--a", ""); // true

[yairEO]

This is kind of like the field-sizing: content property but in reverse,
because the content's size is determined by the outside (ie. the "field" container).

Just now it occurred to me. interesting similarities with completely different naming.

[frivoal]

Reopening so that I don't loose track of the fact I've got follow up edits to make