CSS line-clamp property #1029

Activity

1. ramiy

   added

   focus-area-proposalFocus Area ProposalFocus Area Proposal

   on Sep 5, 2025
2. github-project-automation

   added this to Interop 2026on Sep 5, 2025
3. github-actions commented on Sep 5, 2025

   

   github-actionsBot

   on Sep 5, 2025 – with GitHub Actions

   More actions

   This comment was automatically generated based on the information you provided. Please don't edit it.

   Below is additional information about the web feature (from the web-features project) which is referenced in your proposal.
   If this doesn't accurately correspond to your proposal, please update your initial comment to include web-features: <feature-id>.
   To find feature IDs, use the web-features explorer.

   Feature line-clamp

   • ID: line-clamp
   • Name: line-clamp
   • Description: The line-clamp CSS property limits the text in a block container to a certain number of lines. The prefixed -webkit-line-clamp is widely supported but only works with -webkit-box-orient: vertical in combination with display: -webkit-box or display: -webkit-inline-box.
   • Baseline status: Limited Availability
   • State of CSS/JS/HTML surveys: State of CSS 2025 (usage question), State of CSS 2025 (typography question), State of CSS 2025 (features question), State of CSS 2024 (usage question), State of CSS 2024 (features question)
   • More information: See the web-features explorer

   👍React with 👍2Reacted by Yisi and BearCoder
4. andreubotella commented on Sep 5, 2025

   

   andreubotella

   on Sep 5, 2025

   Last edited by andreubotella

   Member

   More actions

   I've been working on the implementation of line-clamp in Chromium, and it would probably be ready to ship in early 2026, if not earlier. My understanding is that WebKit has also been working on implementing it. Firefox in the past tried to update some parts of the -webkit-line-clamp behavior to match the line-clamp spec, and found some web compat issues that led to spec changes, but as far as I can tell they haven't made more progress in that direction.

   line-clamp will be different from -webkit-line-clamp in that:

   • It will not require the display: -webkit-box and -webkit-box-orient: vertical properties that the prefixed property requires. Making this change on -webkit-line-clamp is not web compatible, sadly.
   • It will support clamping by height, by setting line-clamp: auto and a height constraint (e.g. setting max-height). This will clamp by however many lines fit in that height. Note that line-clamp: 3 would be different from line-clamp: auto; max-height: 3lh in that the latter will clamp to fewer lines if you have images or different font sizes that change the line height.

   That said, in many other cases the specified behavior for -webkit-line-clamp and line-clamp is different from the not-so-interoperable legacy -webkit-line-clamp behavior in browsers in various ways, such as:

   • The line-clamp container will behave like a block element establishing an independent formatting context (as it already is in Firefox and Chromium), rather than behaving like a legacy flexbox (-webkit-box) as in WebKit.
   • Lines and most other content after the clamp point will be automatically hidden (as if it had visibility: hidden), without needing overflow: hidden. That content will still overflow the line-clamp container, but it will be treated as ink overflow so it doesn't take up space in scrollers.
   • When the ellipsis is inserted into a line, it will only be inserted at a break opportunity, that is, at a place where the line could break. The current -webkit-line-clamp implementation in all browsers instead uses the same behavior as text-overflow: ellipsis, where characters are removed off the end of the line one by one until the ellipsis fits. This can lead to the ellipsis cutting off part of a word, sometimes with confusing or hilarious effects.
   • When the clamp point happens in a nested block element, which might have margins, borders and padding, all such nested block elements would also "clamp", such that visibly you have all the nested margins/borders/paddings, as if the nested element ended there. Instead, currently in Webkit and Firefox, the line-clamp container's height is set to the clamp point, so that the borders and so on overflow.
   • If (-webkit-)line-clamp: 3 is set with a given height constraint (such as max-height), it will clamp to either 3 lines, or as many lines as fit in the given height, whichever comes first. This is an extension to the line-clamp: auto behavior described above, but since it doesn't change the -webkit-line-clamp syntax, it might also affect legacy uses.

   In my opinion, for all of these, the new behavior makes more sense than the legacy one. But since they change the behavior of a legacy property, they might not be web compatible. So if line-clamp is accepted for Interop 2026, it should be with the understanding that these changes to -webkit-line-clamp might not be included.

   👍React with 👍5Reacted by Ana Tudor, Benoît Rouleau, Yisi, BearCoder and Steffen Weber
5. meyerweb commented on Sep 5, 2025

   

   meyerweb

   on Sep 5, 2025

   More actions

   I just want to call out this part of @andreubotella’s excellent comment:

   So if line-clamp is accepted for Interop 2026, it should be with the understanding that these changes to -webkit-line-clamp might not be included.

   I don’t feel that this limitation should be solely determinative of acceptance or rejection, but it will be important to weigh it nevertheless.
6. frivoal commented on Sep 11, 2025

   

   frivoal

   on Sep 11, 2025

   More actions

   Spec editor here. I very much support inclusion of line-clamp into interop 2026. The legacy -webkit-line-clamp, while useful and commonly used, is quite bizarre in the details of its behavior, and aligning implementations on what we have now specified should help make the behavior less quirky, more broadly applicable, and more interoperable.

   So if line-clamp is accepted for Interop 2026, it should be with the understanding that these changes to -webkit-line-clamp might not be included.

   Agreed. I also wanted to add a nuance. The spec is written to cover both the line-clamp syntax and the legacy -webkit-line-clamp syntax, defining the legacy version on top of the newer, more sensible behavior. Behavior quirks and deviations that are known to be necessary for -webkit-line-clamp to be web compatible are meant to be covered by the spec. It is quite possible that we will discover more, but in that case, the intent is to update the spec to account for them. The overarching goal being to have both variants be as well-behaved as possible, which being responsive to web-compat requirements.

   👍React with 👍8Reacted by Michaël Vanderheyden, Oliver Williams, Rami Yushuvaev, Andreu Botella, woody-li, Yisi, Steffen Weber and Kenrick
7. frivoal commented on Sep 26, 2025

   

   frivoal

   on Sep 26, 2025

   Last edited by frivoal

   More actions

   In addition to the points raised above, here's an attempt at a general summary of the feature, and the status of its spec and tests:

   Overview

   -webkit-line-clamp is a CSS property which allowed authors to truncate content after a given number of lines, and to insert an ellipsis (“…”) at the truncation point.

   It is a useful and frequently used feature (≈40% according to Chrome's CSS usage metrics), implemented in all browsers. However, its initial implementation was very much a quick-and-dirty affair, built on shaky foundations, with very quirky behavior, limited i18n capabilities, no spec, and copied with limited interoperability by other browsers in all but the most simple cases.

   Over the past few years, the CSS Working Group has sought to to improve that situation, and has defined a line-clamp property, which achieves a similar effect in the simple situations that were already usefully interoperable in all browsers, while being built from a more sensible mechanism, making it more robust and more broadly applicable. The specifications also redefines a -webkit-line-clamp in terms of this newer model, with a few additions for compatibility with existing content.

   See also the explainer by Igalia.

   Scope

   The line-clamp and webkit-line-clamp properties are defined, for ease of use and extensibility purposes, in terms of 3 longhand properties: continue, block-ellipsis, and max-lines. These should be considered in scope for this interop exercise.

   However, only two of the three values of the continue property are needed here: auto (do nothing special) and collapse (hide content after the truncation point). The third value, discard, is a more powerful but more complex alternative to collapse, being explored by the CSSWG as a possible opt-in extension. It is less mature than the rest, but also not needed for the base behavior. That third value should be considered out of scope for interop 2026. (Note that tests pertaining to the discard value are grouped in a separate subdirectory in WPT to make progress on the rest easy to track).

   Specification

   https://drafts.csswg.org/css-overflow-4/#suppressing-excess and subsections (excluding 5.3.2 which is about continue: discard), as well as https://drafts.csswg.org/css-overflow-4/#block-ellipsis.

   The fundamentals of the specification have been stable for a while, and the current approach based on continue: collapse was designed with input from all browser engines in the context of CSSWG discussions.

   There remains a few open issues on details of the behavior, which the CSSWG is making progress through, several of which have already been recently resolved about and are pending spec edits.

   There is ongoing active effort to address the remaining issues over the next few months, and increased focus can be expected if line-clamp is made part of interop 2026.

   Tests

   https://wpt.fyi/results/css/css-overflow/line-clamp/, excluding the discard subdirectory

   As can be seen through tests annotations in the spec, coverage is already quite extensive. Some of the tests are tentative; these are tied to work-in-progress issues mentioned above, and expected to be resolved before long.

   Platform Impact

   Impact on horizontal-review areas:

   • Accessibility: expected to be improved. The interaction between the legacy -webkit-line-clamp and screen readers is undefined, but currently results in visually invisible content being exposed to screen readers. The standard approach to line-clamp can address this. (see [css-overflow] Line-clamp and screen readers w3c/csswg-drafts#12859)

   • Internationalization: expected to be improved. The legacy version of webkit-line-clamp is bidi-challenged, buggy in vertical writing-modes, and language-insensitive. Such issues were a key motivation for the design covered by the specification, which resolves them.

   • Privacy: no impact expected.

   • Security: no impact expected.

   Standard positions:

   • Safari: line-clamp CSS property (collapse variant) WebKit/standards-positions#316
   • Firefox: line-clamp CSS property (collapse variant) mozilla/standards-positions#984
   • Chrome: https://cr-status.appspot.com/feature/4885575595458560

   👍React with 👍1Reacted by woody-li

   ❤️React with ❤️2Reacted by Kenrick and Luke Warlow
8. connorshea commented on Sep 28, 2025

   

   connorshea

   on Sep 28, 2025

   More actions

   Would love to see this, I recently ran into a need for this property at work :)
9. wpt-interop commented on Feb 12, 2026

   

   wpt-interop

   on Feb 12, 2026

   Collaborator

   More actions

   Thank you for proposing CSS line-clamp property for Interop 2026.

   We want to let you know it was not selected to be part of Interop this year.

   On behalf of the entire Interop team, thank you for submitting it for consideration. We got many more proposals than we could include in this year's project, necessitating some difficult choices. Please note this should not be taken as a comment on the technology as a whole, or our willingness to consider it for Interop in the future. We appreciate the work you put into your proposal, and would welcome your participation in future rounds of Interop.

   Posted on behalf of the Interop team.
10. jgraham

    closed this as completedon Feb 19, 2026
11. github-project-automation

    moved this to Done in Interop 2026on Feb 19, 2026