Intent to Prototype: CSS line-clamp property
Andreu Botella
Summary
Allows clamping a block element to have at most a specific number of text lines, or to have as many lines as will fit in a certain height, showing an ellipsis at the end of the last line. This allows showing a small preview of a longer text, purely in CSS, in a simpler way than was previously possible.
Blink component
Motivation
The functionality to clamp a block element to a number of lines and show an ellipsis at the end was previously already available through the -webkit-line-clamp property. This property, however, has a number of shortcomings. For instance, it relies on two other deprecated properties for it to work (display: -webkit-box and -webkit-box-orient: vertical), it requires overflow: hidden to be present so the clamped lines would be hidden, and it also only allows clamping based on a number of lines, not a height. The existing -webkit-line-clamp property seems to be a pain point for web developers (see this blog post, for example), and a Chrome use counter shows that its uses without the other properties that are needed for it to work are at 3-4%, showing significant misuse in the wild. Given this, it makes sense to implement a version without these fallbacks.
Initial public proposal
TAG review status
Risks
Interoperability and Compatibility
This feature would change the behavior of the prefixed -webkit-line-clamp property to be based on the implementation of line-clamp. This prefixed property only works in the presence of the properties display: -webkit-box and -webkit-box-orient: vertical, and this will not change (as that change would be web incompatible). However, the requirement of needing overflow: hidden would be lifted. We plan to use this prototyping stage to make sure this does not break sites.
Additionally, there is an ongoing discussion in the CSS Working Group on whether line-clamp should be implemented based on hiding lines from paint (“the collapse variant”), or based on fragmentation (“the discard variant”). The CSS Overflow Level 4 spec defines only the discard variant, and while Blink could implement it with LayoutNG, other browser engines will not be able to do so without a similar rearchitecturing effort. That is why we are planning to prototype the collapse variant.
Gecko: Was positive on the collapse variant on the CSSWG issue proposing it (https://github.com/w3c/csswg-drafts/issues/7708). Other than that, no signal yet (https://github.com/mozilla/standards-positions/issues/984).
WebKit: No signal yet (https://github.com/WebKit/standards-positions/issues/316).
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
None
Is this feature fully tested by web-platform-tests?
Flag name on chrome://flags
Finch feature name
Non-finch justification
Requires code in //chrome?
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status