[css-overflow] Is continue: discard working in the fragment tree useful?

[emilio]

The main usefulness of it is clipping overflowing content from e.g. line-clamp, but it seems it'd be easier (and more compatible with how -webkit-line-clamp works now) if this behaved more like visibility: hidden (i.e., stop painting them) rather than display: none on the overflowing items?

It'd also be easier to implement, generally, and I'm not sure when it'd be less useful. It might be that I'm missing something obvious?

cc @bfgeek @frivoal @fantasai

[tabatkins]

If it just stopped painting them, then the content would still be overflowing, but scrolling would just reveal a big empty area, yeah? I'm not sure why that would be preferable.

(-webkit-line-clamp is incredibly hacky and broken, I wouldn't look to it for guidance in any respect.)

[emilio]

Well, we could spec that line-clamp affects the scrollable overflow, by not accounting for overflow caused by clamped lines, the same way it affects the auto block size, right? I think that'd still be much easier to implement and maybe more intuitive to authors

[tabatkins]

At that point, what's making it different from discarding the fragments after the break, then? You already have the ability to shift the fragments to the next rendering context, so I'm not clear what the problem you're trying to solve here is.

[emilio]

Well, for once, it doesn't change the interactions with the OM (e.g., getBoundingClientRect() etc keep behaving as if they were in non-fragmented contexts). FWIW in Gecko there's a difference between "pushing stuff to the next page / column" and "making it disappear into the void". We have no precedent for the later I don't think.

[tabatkins]

So you're proposing we define that the overflow after the break opportunity doesn't break, but instead becomes invisible ink overflow?

(I'm also curious what the essential difference is between those two cases, btw. I would naively think that "push these to nowhere" is similar in difficulty, if not easier?)

[bfgeek]

One specific difference is the OOFs would propagate up from the clamped content.

[tabatkins]

Ah, in the "become invisible ink overflow" case? Whereas in the "drop the fragments" case the OOFs after the break would just be gone?

[bfgeek]

Ah, in the "become invisible ink overflow" case? Whereas in the "drop the fragments" case the OOFs after the break would just be gone?

Yup that's correct.

[bfgeek]

The other difference/side-effect is the geometry APIs

[css-meeting-bot]

The CSS Working Group just discussed continue:discard in the fragment tree.

The full IRC log of that discussion

<TabAtkins> Topic: continue:discard in the fragment tree
<astearns> github: https://github.com//issues/7708
<TabAtkins> emilio: making line-clamp work using continue:discard has some side effects
<andreubotella> q+
<TabAtkins> emilio: Based on fragmetnation implies the boxes you clamp don't exist, so OM APIs return 0 sizes, etc
<florian> q+
<TabAtkins> emilio: And implies that like border-bottom disappears due to box-decoration-break
<heycam> q+
<TabAtkins> emilio: I think it would be both easier and more useful to impl line-clamp by clamping both content-height, as it does now, and the scrolalble overflow, and hiding the clamped lines rather thand iscarding fragments
<TabAtkins> emilio: There's been some discussion - I think in general it's a lot easier to implement but similarly useful
<TabAtkins> emilio: So easier to reach unprefixed line-clamp
<iank_> q+
<TabAtkins> emilio: We could decide to ship line-clamp as a longhand for now and decide what to do about shorthands later
<astearns> ack andreubotella
<TabAtkins> andreubotella: it's not clear how line-clamp would work with editting (?)
<astearns> s/(?)/(!)/
<TabAtkins> andreubotella: Not clear where carat woudl go if you move past the clamped line
<TabAtkins> andreubotella: Would be less of an issue with emilio's model
<astearns> ack florian
<TabAtkins> florian: We'd also need to define how padding/etc will work. using fragmentation gets us that, it defines those
<TabAtkins> florian: One of the goals is to avoid reinventing all that
<TabAtkins> florian: It's true that the discarded part, we have incomplete answers about what to do with abspos in there, what happens to the caret, etc
<TabAtkins> florian: So maybe we do use fragmentation, but rather than discard the post-fragmentation is invisible
<TabAtkins> florian: but saying that it's easier to do it visually is in conflict with the existing knowledge that it's in conflict with visual stuff
<TabAtkins> florian: like bidi content
<TabAtkins> florian: in the fragment model, in document order, hen we have enough content to place the ellipsis; that's different from hiding characters at the end of the line
<TabAtkins> florian: another complaint about visual aspect is you hvae no control over what gets elided and whether it happens at sensible line-break points
<TabAtkins> florian: If using fragmentation, the line breaking properties work
<TabAtkins> florian: Another thing which is useful under the current model (and maybe usable under your new model), a lot of people want to clamp at 3 lines, but a lot want to clamp at 100px
<TabAtkins> iank_: still possible
<TabAtkins> florian: Not impossibl, but undefined. Defined with fragmentation, but not defined without.
<TabAtkins> florian: Don't want to display a half-line, for example
<TabAtkins> florian: So I think we can find ways to define things in terms of fragmentation that are less mysterious
<TabAtkins> florian: And also make some statements about "allowable approximations".
<TabAtkins> florian: But I think entirely discard fragmentation would be unfortunate
<TabAtkins> iank_: clarification, the visual model is purely about subsequent lines
<TabAtkins> iank_: Still do layout placement of ellipsis, etc
<TabAtkins> iank_: So not necessarily in conflict with what you want to achieve
<astearns> q?
<TabAtkins> iank_: I don't wanna have a spec where all the impls do emilio's model, and there's a bunch of soft wording about how it's allowed
<emilio> q+
<TabAtkins> florian: yeah point is not to write fiction, it's just that if we do emilio's model because it's more useful, we shouldn't omit the useful properties of the current spec
<TabAtkins> florian: If we treat it as something like a multicol where additional cols aren't painted, you can have an answer to all the API questions
<TabAtkins> iank_: there's still subtle diffs
<TabAtkins> iank_: in emilio's model it's actually desirable that you don't fragment the borders
<TabAtkins> emilio: say you calmp in a nested block with border/padding.
<TabAtkins> emilio: it has five lines, you clamp at 3, per fragmentation you're supposed to hide the border padding at the bottom
<TabAtkins> fantasai: which element has line-clamp here?
<TabAtkins> emilio: the bfc
<TabAtkins> fantasai: so inside the bfc you have a text with 5 text lines
<TabAtkins> fantasai: the bfc says line-clamp:3
<TabAtkins> fantasai: so you clamp after three lines, then what's after is clamped
<TabAtkins> emilio: no
<TabAtkins> iank_: You're just clamping the content box. You set the content box to the size afte clamping and then layout as normal.
<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10735
<TabAtkins> [retreading the previous example]
<TabAtkins> emilio: the auto height of the inner box is 3 lines tall (plus mbp)
<TabAtkins> florian: So you're reinventing fragmentation...
<TabAtkins> emilio: no fragment would crop the border
<TabAtkins> florian: yeah we have box-decoration-break that lets you control it
<TabAtkins> iank_: well they're not repeated, because this *isn't* fragmentation
<TabAtkins> [missed]
<TabAtkins> florian: If we do it with fragmentation you can choose whether to clip those borders or not
<TabAtkins> iank_: You can here, with border:0
<TabAtkins> florian: No you can't, you can't predict whther the clamp activates or not
<TabAtkins> florian: fragmentation already solved this, dunno why we're reinventing
<TabAtkins> iank_: I think this is a small edge case and most people would expect the behavior from emilio's model
<TabAtkins> astearns: agree this is probably small, but there are tons of decisions in this space about what to do after a fragment break, and we'd have to reinvent all of these
<TabAtkins> emilio: don't think it's reinventing, we just do what we do if you clamp the auto size and visually hide the overlap
<TabAtkins> iank_: very similar to empty-cells on tables, or similar to visibility:hidden but not quite
<TabAtkins> astearns: ther'es a long queue
<florian> q+
<florian> ?
<TabAtkins> heycam: it's probably more like visibility:collapse on those additional lines at the end, they take up no space and aren't rendered
<TabAtkins> iank_: a little diff bc collapse applies to a container, and it of ten gets smushed in size and ther'es some other effects, but yeah
<astearns> ack heycam
<TabAtkins> iank_: the way we'd implement is exactly like empty-cells
<TabAtkins> heycam: at a high level in wk, i think we support getting to the full fragmentation model
<TabAtkins> heycam: But we'll need an interim solution, maybe emilio's or similar
<TabAtkins> heycam: think it would be useful to enumerate the diff between this and the full fragment solution so we can see what it's most similar to
<TabAtkins> heycam: and how likely it is we run into compat issue in the future
<TabAtkins> heycam: like gBCR() effects, etc
<TabAtkins> heycam: If that would change between the two solutions, that might be risky
<astearns> ack iank_
<TabAtkins> iank_: broadly i'm supportive of emilio's suggestion
<TabAtkins> iank_: webdevs strongly desire an unprefixed line-clamp
<TabAtkins> iank_: We, Blink, are probably the closest to ahving a fragmentation solution, but still a ways away
<TabAtkins> iank_: emilio's suggestion means all engines can ship something highly interoperable fairly quickly that will satisfy webdev demands
<TabAtkins> iank_: dont' want fiction, so if we do emilio's, want it in the spec
<TabAtkins> iank_: emilio's gets us there very quickly
<TabAtkins> iank_: I don't think emilio's and fragmentation are exclusive
<TabAtkins> astearns: If we come up with a list of things that are going to be different, how can we move from one to the other?
<TabAtkins> iank_: I don't think that we will
<TabAtkins> iank_: I think we'll be shipping whichever we start with
<TabAtkins> iank_: So like, I don't believe3 we'll be able to straight unprefix -webkit-line-clamp even with emilio's solution, bc devs are already depending on scrollable overlow returning a particular value to tell if clamping applied
<TabAtkins> iank_: I suspect we'll get somethign similar
<TabAtkins> iank_: with abspos at the end, for example
<TabAtkins> heycam: so what i'm hearing is that if we come to the full solution it will need a switch
<TabAtkins> iank_: I think that's ok; they're related problems but not necessarily the same
<TabAtkins> iank_: When we want to truncate content and continue it in a different fragmentatin, i wouldn't be sad if that was a different set of fragmentation properties
<TabAtkins> iank_: people are today using prefixed line-clamp and unhappy about it, we can all ship an unprefixed line-clamp with emilio's solution
<TabAtkins> astearns: but it's still different than emilio's?
<TabAtkins> iank_: P sure we can translate most of it over, only big compat change will be the scrollable overflow size change
<astearns> ack emilio
<astearns> ack florian
<TabAtkins> florian: I don't want fiction either, so I'm happy to make accommodations so we can match impls
<TabAtkins> florian: but i wanted to circle back to one potential differenence, because i didn't understand an earlier answer
<TabAtkins> florian: with emilio's, is it possible to "clamp after however many lines it takes to reach 300px"?
<TabAtkins> emilio: could be feasible, define that instead of "hide lines after the third" you'd hide all lines whose block-end edge is after 300px
<TabAtkins> florian: so you'd size the container to 300px, fill it in, start filling in content, then remove after...
<TabAtkins> emilio: not remove
<TabAtkins> florian: you said you'd draw the mbp of children at the bottom, so you'll need to make room to insert those back
<TabAtkins> florian: Note it's not the containr border i'm talking about, it's the content element's border
<TabAtkins> florian: before ocunting lines you don't know how many lines you'll take
<TabAtkins> fremy: you add both top and bottom mbp as you add it, then fill in lines until you hit the limit
<TabAtkins> iank_: yup
<TabAtkins> iank_: our -webkit-line-clamp will already abort and retry for compliated reasons. this is fine
<TabAtkins> florian: what troubles me is not that it's undoable, clearly it is and is even simpler, but it will have something *very similar* to fragmentation which isn't quite fragmentation.
<TabAtkins> astearns: which makes you uneasy
<TabAtkins> florian: yeah
<TabAtkins> florian: The bidi part I'm not sure how you solve
<TabAtkins> florian: we don't control what chunk of text on the last line is okay to remove
<TabAtkins> florian: this is a known problm of the existing paint-based ellipsis
<TabAtkins> emilio: i think blink does layout-time ellipsis
<TabAtkins> emilio: presuambly they ahve to reshpare arbitrary content when inserting it to avoid clipping
<TabAtkins> florian: and it can push content around?
<andreubotella> q+
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<TabAtkins> iank_: I'll ahve to double check, but i think we'll reshape, like if you land on a bad ligature we'll go back and split it
<TabAtkins> florian: it's not just painting a ligature, it's about dropping letters or a whole word
<TabAtkins> florian: simila for an abspos in the content, the static position changes depending on whether it's pushed to the next line or not
<TabAtkins> iank_: I think abspos are break oppos in our impl for this reason
<TabAtkins> astearns: next queue
<astearns> ack fantasai
<TabAtkins> fantasai: there's a number of directions people ahve wanted to extend this in, and starting from fragmentation model gets you to a bunch of different places that we want to end up
<TabAtkins> fantasai: while starting from a visual model doesn't
<TabAtkins> fantasai: I also pasted a funny test case
<TabAtkins> fantasai: it's p weird
<fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10738
<fantasai> fantasai: This is the model we *want*?
<TabAtkins> andreubotella: regarding ellipsis, in current fragmentation there's block-ellipsis where youc an repalce the final lines with something
<TabAtkins> andreubotella: how would this work?
<TabAtkins> andreubotella: if the string has rtl and ltr characters?
<TabAtkins> florian: It's specified, i don't recall the details. I think we insert the string as a string without wrapping oppo and with bidi isolation

[frivoal]

We've had good discussions during TPAC breaks about what a simpler mechanism than the one currently specified might be, and I have been trying to understand in detail what the suggested approach means.

As a placeholder, let's call this new approach continue: collapse, in contrast to continue: discard.

Prior to trying to spec it out, I'd like to make sure we're all on the same page. Here's a collection of situations which I hope will help us confirm whether we agree about the behavior we're talking about, maybe explore some possible variants, and help us evaluate whether we like the resulting behavior. (We might need a break-out session to go through this.)

(In the examples below, a / indicates where the cut-off point would fall.)

1. The base case is something like this: an otherwise unstyled article with a bunch of lines, cut after 3 lines, or after 300px

   <article style="continue: collapse; max-lines: 3">.../..</article>

   <article style="continue: collapse; max-height: 300px">.../..</article>

   I think in this situation, there would be no visible difference between the proposed behavior for continue: collapse and continue: discard. Right?

2. If the article itself has a margin/border/padding, what does that do? Nothing special I expect, as it's the content of the article that's getting cliped/discarded/collapsed, and the article itself is unaffected and nothing happens to its m/b/p.

3. If the article contains a div (which itself contains all the content) which has m/b/p, what does that do?

   <article …>
     <div style="border: solid red">../.</div>
   </article>

   In particular:

   1. Is the bottom border kept or not?
   2. Is the height of this border taken into account when determining how much content to collapse/discard under the max-height constraint?
   3. Is the answer the same for padding (probably)?
   4. Is the answer the same for margins (maybe)?

4. If the article contains a div which has m/b/p, and there's some more text nodes after that, what does that do?

   <article …>.
     ...
     <div style="border: solid red">../.</div>
     ...
   </article>

   Same question as the (3), but taking into account the presence of text nodes outside of the div.

5. If the article has several child elements with m/b/p, and we're dropping content from several of them. Do you keep the (now empty) divs after the clamping point at all? if yes, what happens to their m/b/p ?

   <article …>
     <div style="border: solid red">...</div>
     <div style="border: solid red">../.</div>
     <div style="border: solid red">...</div>
     <div style="border: solid red">...</div>
   </article>

6. How do the previous 3 questions (and any other that seems relevant) interact with box-decoration-break? Note: box-decoration-break is already shipping in a least one Browser (Firefox), so while we can retro-fit an initial auto value if needed, we cannot not skip thinking about it altogether.

7. If there's a rel-pos anchored in the discarded/collapsed lines, what happens to it?

8. If there's a rel-pos anchored in the retained lines, shifted far enough down that it would be visually after the cut-off point, what happens to it?

9. If there's a float anchored in the discarded/collapsed lines. What happens to it?

10. If there's a replaced float anchored in the a retained line. What happens to it? Does it get truncated? Does it stay entirely? What effect does it have on the height of its containing block?

11. If there's a non-replaced float anchored in an retained line. What happens to it? Does it get truncated? Does it stay entirely? What effect does it have on the height of its containing block?

12. If there's an tall inline-level box (image, inline-block, orthogonal inline-level box…) in a retained line, does it simply grow the line and the discarding/collapsing works on that bigger line, or something else?

13. If there's a abspos anchored in the discarded/collapsed lines. What happens to it? If not disappear, what is its static position? Does bottom:0 take it to the bottom of the box as trucated, or the the (invisible) bottom of the theoretical box?

14. If you're capping by max-lines, and there are block-level descendants of the continue:collapse element with more structure than just a pile of lines (nestbed BFCs, block-level orthogonal flow, a table, a grid, a block level image…), do you simply ignore them when counting lines, or something else?

15. If you're capping by max-height, and the cut-off point falls into something that has more structure than just a pile of lines (nestbed BFCs, block-level orthogonal flow, a table, a grid, a block level image…), what do you do?

16. What do you get if you use any of the JS APIs to query about the geometry of boxes entirely within the discarded/collapsed content?

17. What do you get if you use any of the JS APIs to query about the geometry of boxes partially within the discarded/collapsed content?

18. How do the intrisinsic size keywords resolve on the height of the truncating/containing box?

19. How do the intrisinsic size keywords resolve on the truncated box?

20. How do you insert the ellipsis text on the last line that remains:

    1. Does it remove text in logical or visual order (before/after bidi reordering)?
    2. Where does the ellipsis get placed, if inserted in a complicated bidi phrase?
    3. To make room for the ellipsis text, do we remove any number of individual grapheme cluster or do we respect the various css-text properties governing what are acceptable line-breaking opportunities?
    4. Is the content removed from the last line to make room for the ellipsis pushed to the discarded lines? That could for example be observed through the static position of abspos elements anchored in the discarded/collapsed content.
    5. Is the ellipsis text drawn in the block's font/font-size, the removed text's font/font-size, or something else?
    6. Does ellipsis text affect the height of the line it's injected in if it happens to be the tallest (or only thing) on that line?
    7. What happens if ellipsis text is too long to fit the line?

21. What happens when you select all on the page and copy to the clipboard? Do we get the hidden content? What about the ellipsis?

22. Is the discarded content in the accessibility tree?

If anyone has questions in the same vein, that would help explore the behavior (including but not limited to exposing differences between continue: collapse and continue: discard), feel free to add some more.

[andreubotella]

I've been toying with a prototype implementation of continue: collapse in Chromium with max-lines, built on top of the existing -webkit-line-clamp code. The existing -webkit-line-clamp behavior is to set the intrinsic size of the element to the block offset of the last line before clamping (plus bottom p/b of that line's ancestor elements, see below), and my prototype additionally skips painting any line boxes, block-level boxes and floats (but not abspos) which are after the clamp point in the layout tree.

With that, this is how this prototype handles some of these questions.

3. If the article contains a div (which itself contains all the content) which has m/b/p, what does that do?

   <article …>
     <div style="border: solid red">../.</div>
   </article>

   In particular:

   1. Is the bottom border kept or not?
   2. Is the height of this border taken into account when determining how much content to collapse/discard under the max-height constraint?
   3. Is the answer the same for padding (probably)?
   4. Is the answer the same for margins (maybe)?

The bottom padding and border is kept, but the bottom margin isn't. (This is something that is currently observable in Chromium's implementation of -webkit-line-clamp.)

In particular, if you have a div with m/b/p whose only content is a div with m/b/p, and the clamping happens in the inner div, the inner div will also not keep its margin. If the m/b/p for both elements are symmetric, you can observe that as a difference in the actual spacing between the top and bottom:

4. If the article contains a div which has m/b/p, and there's some more text nodes after that, what does that do?

   <article …>.
     ...
     <div style="border: solid red">../.</div>
     ...
   </article>

   Same question as the (3), but taking into account the presence of text nodes outside of the div.

The line count is part of the formatting context, so if you have max-lines: 3 and there's a line before the div, the div will clamp after 2 lines. If the clamp point is inside the div, it will behave as in (3). If it's before it, the border will not be painted.

5. If the article has several child elements with m/b/p, and we're dropping content from several of them. Do you keep the (now empty) divs after the clamping point at all? if yes, what happens to their m/b/p ?

   <article …>
     <div style="border: solid red">...</div>
     <div style="border: solid red">../.</div>
     <div style="border: solid red">...</div>
     <div style="border: solid red">...</div>
   </article>

Same as above: the line count adds up across the divs, and any divs after the clamped line will be completely hidden.

7. If there's a rel-pos anchored in the discarded/collapsed lines, what happens to it?

8. If there's a rel-pos anchored in the retained lines, shifted far enough down that it would be visually after the cut-off point, what happens to it?

My implementation so far hides things that are after the clamp point in the layout tree, regardless of where they show up visually. So (7) is hidden, (8) is shown outside the element.

9. If there's a float anchored in the discarded/collapsed lines. What happens to it?

10. If there's a replaced float anchored in the a retained line. What happens to it? Does it get truncated? Does it stay entirely? What effect does it have on the height of its containing block?

11. If there's a non-replaced float anchored in an retained line. What happens to it? Does it get truncated? Does it stay entirely? What effect does it have on the height of its containing block?

Same as above, floats anchored in retained lines are shown, even if they visually overflow or show completely outside of the element's bounds. Floats in the discarded lines are hidden. Whether they're replaced or not doesn't make a difference.

12. If there's an tall inline-level box (image, inline-block, orthogonal inline-level box…) in a retained line, does it simply grow the line and the discarding/collapsing works on that bigger line, or something else?

As far as max-lines is concerned, it simply grows the line. It's not clear to me how this should work for max-height.

13. If there's a abspos anchored in the discarded/collapsed lines. What happens to it? If not disappear, what is its static position? Does bottom:0 take it to the bottom of the box as trucated, or the the (invisible) bottom of the theoretical box?

Currently I'm always showing abspos. If the block inset properties are not set, the abspos will show up wherever it would without continue: collapse, even if it's outside of the article. bottom: 0 takes it to the bottom of the "collapsed" article box.

14. If you're capping by max-lines, and there are block-level descendants of the continue:collapse element with more structure than just a pile of lines (nestbed BFCs, block-level orthogonal flow, a table, a grid, a block level image…), do you simply ignore them when counting lines, or something else?

Chromium's implementation of -webkit-line-clamp ignores all of those, so my prototype does as well.

[bfgeek]

15. If you're capping by max-height, and the cut-off point falls into something that has more structure than just a pile of lines (nestbed BFCs, block-level orthogonal flow, a table, a grid, a block level image…), what do you do?

If the content isn't on a line it will cut off the content outside the formatting context - this is similar to monolithic content. As with 14 they aren't considered for lines.

16. What do you get if you use any of the JS APIs to query about the geometry of boxes entirely within the discarded/collapsed content?

You get the standard geometry as you'd expect if they weren't hidden. This is similar to how visibility: hidden works.

17. What do you get if you use any of the JS APIs to query about the geometry of boxes partially within the discarded/collapsed content?

Same as above. They will be visible if not hidden, and same the same geometry.

18. How do the intrisinsic size keywords resolve on the height of the truncating/containing box?

Unclear what you mean by truncating here, but I'll assume this is the box with line-clamp on it. It'll be the height of it in the clamped state.

19. How do the intrisinsic size keywords resolve on the truncated box?

Unclear what tracated box means here, but i'll assume a box that was been hidden. It'll behave the same as if it wasn't truncated.

20. How do you insert the ellipsis text on the last line that remains:

These questions don't seem specific to the "collapse" behaviour.

21. What happens when you select all on the page and copy to the clipboard? Do we get the hidden content? What about the ellipsis?

Unclear - what the expected behaviour would be - this is similar to existing clamping behaviour (e.g. text-overflow).

22. Is the discarded content in the accessibility tree?

Likely yes.

[tabatkins]

So in summary the rules appear to be:

• there is a "cut point" after a certain number of lines or whatever
• everything in-flow after the cut point, or floated after the cut point, has its paint suppressed, and doesn't contribute its geometry to sizing or overflow of the continue element. (but it still has geometry, observable from JS, as if it were visibility:hidden).
• abspos and other out-of-flows still draw as normal, as long as their abspos containing block isn't suppressed after the cut point. They use the actual sizing of the various containers (this isn't overflow) to resolve their insets.
• containers closed before the cut point draw as normal. Containers who are unclosed at the cut point still draw their block-end padding and border, but do not draw their block-end margin.

[andreubotella]

Hey, I recently sent an intent-to-prototype for the collapse variant of line-clamp in Chrome (https://groups.google.com/a/chromium.org/g/blink-dev/c/CWP5rb--Gyk). Although there isn't spec text for this yet, we've set up an explainer with our understanding of the behavior of this variant (https://github.com/Igalia/explainers/blob/main/css/line-clamp/README.md).

The plan is to currently implement only the line-clamp property as a longhand, allowing only the values none | auto | <integer [1,∞]>, and not implementing the continue, max-lines or block-ellipsis properties. The only difference versus what would be possible with these longhands would be removing or customizing the ellipsis text, which seems like a more niche feature. That said, this is just for the purpose of prototyping and we are not locking ourselves into it.

[superuserpro]

Try https://csser.space/questions/challenges-arising-from-the-offset-in-an-overflowing-div

[andreubotella]

I forgot to mention it over here, but I have a PR for continue: collapse up at #10816. PTAL.