-webkit-line-clamp

[bfgeek]

Description
-webkit-line-clamp is a highly used feature to clamp the number of lines shown for inline-content.

Specification
https://drafts.csswg.org/css-overflow-3/#propdef--webkit-line-clamp

Tests
https://wpt.fyi/results/css/css-overflow?label=master&label=experimental&aligned&q=webkit-line-clamp
... kinda - some of these tests are incorrect.

Rationale
The un-prefixed version "line-clamp" is relatively expensive for engines to implemented. (Specifically dropping content after the trimmed line is difficult for /reasons/).

However that shouldn't stop getting the behaviour of -webkit-line-clamp closer to line-clamp.

There are roughly three areas for improvement across browsers.

1. RTL support. We (Blink) added this in 2020[1] and is the biggest show-stopper for people using this feature from us talking with various web developers.

   • https://codepen.io/nilsynils/pen/QKgJAY?editors=1100#
   • https://codepen.io/bjhytrek/pen/poyQZQj?editors=1100

2. Create a block-flow box, instead of a flex box. We (Blink) also fixed this in 2020 - under the hood Blink creates a block-flow box instead of a flex box. This means that it mirrors the spec more closely (making far more likely we can directly map it onto the un-prefixed version) and also matches what developers expect. See:

   • https://twitter.com/davatron5000/status/1428751058822647810
   • https://twitter.com/jaffathecake/status/1235869840226881536

3. Support "-webkit-line-clamp: none" only FF supports this currently, and this would round out making it a minimal when un-prefixing.

cc/ @frivoal

[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/SVD5wSqVwKU/m/eY28UiNkAwAJ?pli=1

[foolip]

Thanks for submitting this proposal, @bfgeek! Regarding -webkit-line-clamp: none, do you know if there are Chromium or WebKit bugs for that? I couldn't find either in a quick search, at least.

[foolip]

Survey data supporting this is in #7. Most of the responses just said "line-clamp", but these were a bit more elaborate:

• "line-clamp with children elements"
• "I like how line-clamp is implemented in Chrome. The rest is just a bad developer experience and requires additional JavaScript."
• "-webkit-line-clamp is another one that would be good to have standardised."
• "not full support of line-clamp for safari - lists with line clamp"

[jgraham]

some of these tests are incorrect

It would be good to get some more detail on which tests are incorrect/missing here.

Also, if I understand correctly it also seems like there's some spec work needed? Although there's definitely a good case that authors are looking for improvements here, we don't want to include things that are likely to undergo significant churn. How confident are we that we will have an correct set of tests and an accurate/agreed-upon spec before the new year?

[bfgeek]

Thanks for submitting this proposal, @bfgeek! Regarding -webkit-line-clamp: none, do you know if there are Chromium or WebKit bugs for that? I couldn't find either in a quick search, at least.

We don't have an explicit bug for this. This was implemented in FF when they shipped -webkit-line-clamp, and is the main reason why Blink fails the various tests linked above.

It would be good to get some more detail on which tests are incorrect/missing here.

https://groups.google.com/a/chromium.org/g/blink-dev/c/SVD5wSqVwKU/m/eY28UiNkAwAJ?pli=1
external/wpt/css/css-overflow/webkit-line-clamp-008.html
external/wpt/css/css-overflow/webkit-line-clamp-029.html

Are the two tests. These test the bad "line-clamp each child box individually" which nobody we've talked to wants.

Also, if I understand correctly it also seems like there's some spec work needed? Although there's definitely a good case that authors are looking for improvements here, we don't want to include things that are likely to undergo significant churn. How confident are we that we will have an correct set of tests and an accurate/agreed-upon spec before the new year?

There isn't really any spec work here. (Aside from any potential clarifications). The spec is currently aspirational, in that it requires dropping children after when the line-clamp is applied. This is currently very difficult for browsers, but importantly isn't the source of the developer pain here.

We (Blink) believe that with our current behaviour we'll be able to completely transition to the un-prefixed version without any compat issues. However (again) the dropping content issue isn't the source of developer pain. Its the other interop issues.

Survey data supporting this is in #7. Most of the responses just said "line-clamp", but these were a bit more elaborate:

This is great! At least two (three?) of these responses are happy with the better behaviour:

"I like how line-clamp is implemented in Chrome. The rest is just a bad developer experience and requires additional JavaScript."
"line-clamp with children elements"
"not full support of line-clamp for safari - lists with line clamp"

(for the list one I didn't even realize that we (Blink) supported this, but it makes sense: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9796 )

[jgraham]

There isn't really any spec work here. (Aside from any potential clarifications). The spec is currently aspirational, in that it requires dropping children after when the line-clamp is applied. This is currently very difficult for browsers, but importantly isn't the source of the developer pain here.

OK, that sounds good. Is it accurate to say the proposal is "pass the existing tests from https://wpt.fyi/results/css/css-overflow?label=master&label=experimental&aligned&q=webkit-line-clamp, with -008 and -029 changed to match the current Blink behaviour"?

[bfgeek]

OK, that sounds good. Is it accurate to say the proposal is "pass the existing tests from https://wpt.fyi/results/css/css-overflow?label=master&label=experimental&aligned&q=webkit-line-clamp, with -008 and -029 changed to match the current Blink behaviour"?

Thats correct.

[bfgeek]

(at least I believe those are the only two tests which need to be updated from my previous analysis).

[bfgeek]

Potentially also: http://wpt.live/css/css-overflow/webkit-line-clamp-024.html as this is assume flex baseline behaviour instead of block baseline behaviour.

[foolip]

@bfgeek I added the requires:spec label here in our previous meeting, but I hadn't read #16 (comment) then, just noted the "kinda" in the description.

For the spec situation, can you outline which bits of the spec that are included, or which should be ignored, whichever is the smaller set?

Or could this be framed as following the spec, but the tests we include don't exercise some of the things that we want to leave out of scope?

[mrego]

From the spec side, @frivoal has been paying attention to this topic, and maybe he can help to clarify the status of things.

[frivoal]

The spec's status is about as stable as it'll get without implementations progressing further.
With a couple of minor exceptions (see below), it's meant to be design-complete, both taking into account what the "right" design should be, and compat constraint as they are understood.

If implementation experience shows that we underestimated the demands of compatibility with the -webkit- version, then we may have to tweak things a bit, but otherwise it should be good to go. If there are questions as to why the design is the way it is, I'm happy to go into that, but for now, I think it's enough to say the design is intentional, not pending any particular rework by the CSSWG, and complete except for implementation feedback and a couple of comparatively small issues.

The remaining two issues are w3c/csswg-drafts#2970 and w3c/csswg-drafts#2971. Happy to go into those too, but I don't think it should have a strong bearing on this discussion.

[bfgeek]

Right the spec is effectively fine at the moment. Those final issues are important once implementations can support dropping the content after the ellipsis. (Which no implementations can currently support this easily).

Since implementations aren't currently able to support dropping the content after the ellipsis (there isn't anything fundementally bad here, its just a lot of work to do correctly) - the focus of this issue would be getting implementations to be interoperable on everything except for dropping content.

This moves the bar significantly for web developers. Better RTL support, better line-clamping behaviour with multiple boxes which people do complain about.

[foolip]

Right the spec is effectively fine at the moment.

I've removed the requires:spec label based on this. @bfgeek can you also update the issue description?

[gsnedders]

These test the bad "line-clamp each child box individually" which nobody we've talked to wants.

Do the tests match the spec, or does Blink match the spec? Either way, bugs should be filed as appropriate!

The spec is currently aspirational, in that it requires dropping children after when the line-clamp is applied.

By this you mean the behaviour defined by continue: -webkit-discard, right? I'd kinda like some clearer definition for the purposes of Interop 2022 about what exact behaviour we're considering out of scope. Are we just assuming that content after the fragmentation break is not rendered, and avoiding making any assumption about anything else? (Also plausible I've misunderstood the legacy behaviour!)

[bfgeek]

Do the tests match the spec, or does Blink match the spec? Either way, bugs should be filed as appropriate!

Blink matches the spec here. I've got it on my list to update the noted tests above in the repo.

By this you mean the behaviour defined by continue: -webkit-discard, right? I'd kinda like some clearer definition for the purposes of Interop 2022 about what exact behaviour we're considering out of scope. Are we just assuming that content after the fragmentation break is not rendered, and avoiding making any assumption about anything else? (Also plausible I've misunderstood the legacy behaviour!)

Correct. Basically dropping content as described by continue: -webkit-discard would be out of scope for interop 2022.
All engines today will render content after the ellipsis, but all web developers place a overflow: hidden on the box to hide the excess content.

E.g.

<!DOCTYPE html>
<div style="display: -webkit-inline-box; -webkit-box-orient: vertical; -webkit-line-clamp: 3; border: solid;">
one<br>two<br>three<br>four
</div>

[foolip]

Based on the Dec 9 meeting, with outcomes summarized in #39 (comment), we won't include -webkit-line-clamp in Interop 2022.

[foolip]

In case we want to revisit this next year, does anyone see a need for spec change in order to ship the unprefixed line-clamp? If no implementer thinks it's worth the investment near term to implement the "dropping content" bits, could those be bumped to another level in the spec?

Or, more simply: what is a credible path to getting both -webkit-line-clamp and line-clamp working the same way in all browsers?

[jensimmons]

If we want to revisit this for Interop 2023, now would be a great time to figure out the state of standardization — or what credibly path to line-clamp interop.

[foolip]

I'll go ahead and close this. This was an Interop 2022 proposal, and we should have a new issue for revisiting for Interop 2023.

[jonrimmer]

Disappointing that this never got re-proposed for Interop 2023. This remains one of the most cited CSS compatibility problem areas: https://2022.stateofcss.com/en-US/usage/#interoperability_features_freeform

[chrishtr]

@jonrimmer I agree it's an important problem area. One reason it wasn't proposed for Interop 2023 was that we don't (yet) have a solution for the problem. One promising approach is described here; do you think it would meet your needs if that was the solution?

[gsnedders]

FTR, the spec is now in L4: https://drafts.csswg.org/css-overflow-4/#propdef--webkit-line-clamp

[Mouvedia]

Can it be reopened?

[jensimmons]

Not reopened, but someone can propose this for Interop 2025 in the fall.

[Mouvedia]

It seems to be covered by #702.