Specification

https://drafts.csswg.org/css-overflow-4/#suppressing-excess

Explainer

https://github.com/Igalia/explainers/blob/main/css/line-clamp/README.md

Links

• Previous early design review, if any: N/A
• An introduction to the feature, aimed at unfamiliar audiences: https://github.com/Igalia/explainers/blob/main/css/line-clamp/README.md#introduction
• A description of the problems that end-users were facing before this proposal:
  • https://github.com/Igalia/explainers/blob/main/css/line-clamp/README.md#motivation
  • https://medium.com/mofed/css-line-clamp-the-good-the-bad-and-the-straight-up-broken-865413f16e5
• Alternatives considered: https:// <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
• Examples of how to use the proposal to solve the end-users' problems: https://github.com/Igalia/explainers/blob/main/css/line-clamp/README.md#examples
• What do the end-users experience with this proposal: https:// <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
• User research you did to validate the problem and/or design, if any: N/A
• Web Platform Tests: https://wpt.fyi/results/css/css-overflow/line-clamp

The specification

• Follows the Web Platform Design Principles.
• Includes Security and Privacy Considerations sections based on answers to the Security/Privacy Questionnaire.

Where and by whom is the work is being done?

• GitHub repo: https://github.com/w3c/csswg-drafts/
• Primary contacts:
  • Florian Rivoal (@frivoal), Invited Expert, Editor
  • Andreu Botella (@andreubotella), Igalia, Chromium implementer
• Organization/project driving the specification: Igalia
• This work is being funded by: Bloomberg
• Primary standards group developing this feature: CSS Working Group
• Group intended to standardize this work: CSS Working Group
• Incubation and standards groups that have discussed the design:
  • https://lists.w3.org/Archives/Public/www-style/2018May/0041.html
  • https://github.com/w3c/csswg-drafts/issues/7708

Feedback so far

• Multi-stakeholder feedback:
  • Chromium comments: Implementing, planning to ship
  • Mozilla comments: https://github.com/mozilla/standards-positions/issues/984 (see also https://github.com/w3c/csswg-drafts/issues/14189)
  • WebKit comments: https://github.com/WebKit/standards-positions/issues/316
  • Interop proposals: 2025, 2026, 2027
• Major unresolved issues with or opposition to this specification:
  • the current version of the editor's draft doesn't yet reflect the latest status of the working group resolutions in terms of how the syntax space is distributed across the longhands; w3c/csswg-drafts#14508 is a PR making these changes
  • w3c/csswg-drafts#14448, arguing that block-ellipsis's behavior of discarding the line's contents when there are no soft wrap opportunities is "clearly a bad result"
• Status/issue trackers for implementations:
  • Chrome Status: https://chromestatus.com/feature/4885575595458560
  • Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1540681
  • WebKit: There isn't a single meta-issue, but there's work being done: https://bugs.webkit.org/buglist.cgi?quicksearch=line-clamp&list_id=13494808

You should also know that...

• -webkit-line-clamp has been supported in all mainstream browser engines for years, even though it was not specified anywhere. There are cases, however, where the legacy behavior of mainstream engines is interoperable but where this specification changes the behavior. We don't expect breakage in the wild, since browsers aren't interoperable in many other cases, but it is possible that we might find some.

  • In the legacy behavior, content after the clamp point renders normally, except it is usually outside the box of the -webkit-line-clamp container, so that needs overflow: hidden to hide it. In the spec'd behavior, content after the clamp point becomes invisible and is counted as ink overflow, so overflow: hidden is not needed.
  • In the legacy behavior, if the ellipsis wouldn't fit at the end of a line, glyphs and atomic inlines would be removed off the end of the line to make it fit, as with text-overflow: ellipsis. In the spec'd behavior, inline content at the end of the line is displaced until the last soft wrap opportunity such that the ellipsis fits; and if there are none, the entire contents of the line are displaced.
  • In the legacy behavior, floats can overflow the -webkit-line-clamp container, but since overflow: hidden is almost always used, in practice they will be always clipped to the padding box. In the spec'd behavior, float clearance is not taken into account for the container's automatic sizing (meaning that floats can overflow despite the container establishing an independent formatting context), and floats before the clamp point are clipped to the container's content edge.

• Review on the naming of line-clamp's longhands would be appreciated. For example, there were questions raised on the name of the block-ellipsis property, since its keywords are ellipsis and no-ellipsis (see https://github.com/w3c/csswg-drafts/issues/13670#issuecomment-4179822644). We would also appreciate feedback on the name of the continue property, considering also that there are plans to extend this property to handle channeling overflow (https://drafts.csswg.org/css-overflow-5/#fragmentation).

• In Chromium, we are planning to ship line-clamp soon. We would only be shipping line-clamp as a longhand, and only ship its longhands at some point in the future. We will also be changing the legacy behavior of -webkit-line-clamp to match line-clamp at the same time.

<!-- Content below this is maintained by @w3c-tag-bot -->

---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1287