[w3ctag/design-reviews] Other Spec Review: CSS line-clamp (Issue #1287)

andreubotella created an issue (w3ctag/design-reviews#1287)

### Specification

https://drafts.csswg.org/css-overflow-4

### 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

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/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
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/316
  - Interop proposals: [2025](https://github.com/web-platform-tests/interop/issues/725), [2026](https://github.com/web-platform-tests/interop/issues/1029), [2027](https://github.com/web-platform-tests/interop/issues/1379)
- 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](https://drafts.csswg.org/css-display-4/#invisible-box) and is counted as [ink overflow](https://drafts.csswg.org/css-overflow-3/#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


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1287
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1287@github.com>