Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
yairEO opened this issue Sep 17, 2023 · 20 comments
Closed

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

yairEO opened this issue Sep 17, 2023 · 20 comments
Assignees
@frivoal
Labels
Closed Accepted by CSSWG Resolution css-overflow-4 Needs Testcase (WPT)

Comments

@yairEO
Copy link

yairEO commented Sep 17, 2023 •
edited
Loading

Feature request

Spec links

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:
@SebastianZ
Copy link
Contributor

SebastianZ commented Sep 17, 2023 •
edited
Loading

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
Copy link
Collaborator

frivoal commented Sep 21, 2023

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
Copy link
Collaborator

frivoal commented Sep 21, 2023

cc: @andreubotella @fantasai

@andreubotella
Copy link
Member

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
Copy link

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
Copy link
Contributor

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

@yairEO yairEO changed the title [css-overflow-4] line-clamp "max-lines" - support auto value to fit container [css-overflow-4] line-clamp max-lines - support auto value to fit container Jan 1, 2024
@SebastianZ SebastianZ added the Async Resolution: Proposed Candidate for auto-resolve with stated time limit label Jan 1, 2024
@SebastianZ
Copy link
Contributor

SebastianZ commented Jan 1, 2024 •
edited
Loading

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
Copy link
Author

yairEO commented Jan 2, 2024

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

@SebastianZ
Copy link
Contributor

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
Copy link
Member

astearns commented Jan 3, 2024

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 astearns added Async Resolution: Call For Consensus Resolution will be called after time limit expires and removed Async Resolution: Proposed Candidate for auto-resolve with stated time limit labels Jan 3, 2024
@frivoal frivoal self-assigned this Jan 4, 2024
@astearns
Copy link
Member

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

@astearns astearns added Needs Edits Needs Testcase (WPT) and removed Async Resolution: Call For Consensus Resolution will be called after time limit expires labels Jan 16, 2024
@mozilla-apprentice mozilla-apprentice mentioned this issue Jan 16, 2024
Closed
@chromium-helper chromium-helper mentioned this issue Jan 16, 2024
Closed
frivoal added a commit that referenced this issue Jan 22, 2024
@frivoal
[css-overflow] allow line-clamp shorthand syntax to omitting max-line…
f33930c 
…s value

See #9368
@frivoal frivoal closed this as completed Jan 22, 2024
@cdoublev
Copy link
Collaborator

@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'>>? ]!

@cdoublev

This comment was marked as outdated.

Sign in to view
@Loirooriol
Copy link
Contributor

Yes the grammar should use !

@Loirooriol Loirooriol reopened this Jan 23, 2024
@frivoal
Copy link
Collaborator

frivoal commented Jan 24, 2024 •
edited
Loading

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Contributor

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

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

@cdoublev cdoublev mentioned this issue Feb 2, 2024
Merged
@yairEO
Copy link
Author

yairEO commented Feb 14, 2024

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.

@yairEO yairEO closed this as completed Feb 14, 2024
@frivoal frivoal reopened this Feb 20, 2024
@frivoal
Copy link
Collaborator

frivoal commented Feb 20, 2024

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

frivoal added a commit that referenced this issue Feb 26, 2024
@frivoal
[css-overflow-4] Adjust the syntax of the line-clamp property
a676261 
See #9368
@frivoal frivoal closed this as completed Feb 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@frivoal frivoal

Labels
Closed Accepted by CSSWG Resolution css-overflow-4 Needs Testcase (WPT)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@frivoal @fantasai @yairEO @SebastianZ @astearns @andyearnshaw @Loirooriol @andreubotella @cdoublev