Skip to content

[css-overflow] What counts as "immediately preceding" for block-ellipsis? #10868

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
andreubotella opened this issue Sep 11, 2024 · 7 comments

Comments

@andreubotella
Copy link
Member

andreubotella commented Sep 11, 2024

block-ellipsis, which is one of the properties that line-clamp is a shorthand for, creates an ellipsis on the last line before clamp, if that line box "immediately precedes" the region break. Since max-lines creates a region break after a line box, when that property is used, the immediately preceding line box is clear. But when clamping by height, the interpretation of that isn't always clear.

My expectation is that a line box would get ellipsized if there is no content between it and the clamp point in the box tree, except that ancestor boxes of the line box can end in between:

.clamp {
  line-clamp: auto;
  max-height: calc(5lh + 2 * 5px);  /* account for .inner's border */
  background-color: yellow;
  border: 5px solid black;
  padding: 5px;
}
.inner {
  background-color: orange;
  border: 5px solid brown;
}
<div class="clamp">
  Line 1 <br>
  Line 2 <br>
  Line 3
  <div class="inner">
    Line 4 <br>
    Line 5
  div>
  Line 6
div>

image

But there wouldn't be an ellipsis if an entire box sits in between:

.clamp {
  line-clamp: auto;
  max-height: 4lh;
  /* ... */
}
.h {
  height: 1lh;
  background-color: orange;
}
<div class="clamp">
  Line 1 <br>
  Line 2 <br>
  Line 3 <br>
  <div class="h">div>
  Line 4
div>

image

My expectation is also that a line box would be ellipsized even it is contained inside a box with a non-overflowing height property. (This does not currently work in my in-progress implementation of continue: collapse in Chromium, though, and it would need some heavy refactoring before it would be possible.)

.clamp {
  line-clamp: auto;
  max-height: calc(6lh + 2 * 5px);
  /* ... */
}
.inner {
  height: 3lh;
  /* ... */
}

image

One interesting question is what to do when there are out-of-flow block-level elements, between the last line box and the clamp point. By the above definition, the line box shouldn't be ellipsized in that case. However, especially for an abspos box which is positioned elsewhere, this might not be intuitive to authors.

.clamp {
  position: relative;
  line-clamp: auto;
  max-height: 4lh;
  /* ... */
}
.abspos {
  position: absolute;
  top: 0;
  right: 0;
  width: 50px;
  height: 50px;
  background-color: orange;
}
<div class="clamp">
  Line 1 <br>
  Line 2 <br>
  Line 3 <br>
  Line 4
  <div class="abspos">div>
  Line 5
div>

image

cc @frivoal @bfgeek @emilio

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 20, 2024
The current way `line-clamp: auto` works is by checking at every line
and after every (line) box whether the box has reached the clamp
point's BFC offset, and place an ellipsis or hide the box depending on
it. For line boxes, this comparison requires computing the BFC offset
at which the line will finish, before it is computed naturally as part
of the inline layout algorithm. And if no box ends right at the clamp
offset, which is almost every time, the layout has to be redone.

An alternative way of doing this work would be by always doing a
relayout: the first pass computes which line number to clamp at, and
the second pass can behave the same as `line-clamp: 3`.

A complication is that with `line-clamp: auto`, unlike with
`line-clamp: 3`, it is possible to break between two lineless boxes.
To account for this, we store both a number of lines until clamp, as
well as a number of remaining boxes between the last line and the
clamp point. We pack the lines and the remaining boxes into a
`LineClampData::UntilClamp` struct.

Since the previous implementation ellipsized lines based on whether
they end at the clamp point, it means that a line could have an
ellipsis even when it was followed by a zero-height block. It also
meant that if a line inside a block with a set `height` might not have
an ellipsis even if it was the last line before clamp, because it did
not end at the clamp point. This patch fixes those bugs, and adds (or
in the case of `line-clamp-auto-032.tentative.html`, fixes) tests for
them.

In cases where the last line before clamp is followed by an abspos,
however, it seems like it would be unexpected for the line to not have
the ellipsis. This remains to be discussed with the CSS Working Group
(see w3c/csswg-drafts#10868), but since
there are previously written tests that rely on this behavior, we have
chosen to special case abspos so such a line is ellipsized.

Bug: 40336192, 367892771
Change-Id: I45881ce76b7b23de731ae69ef5c947957cc7cf93
aarongable pushed a commit to chromium/chromium that referenced this issue Sep 20, 2024
The current way `line-clamp: auto` works is by checking at every line
and after every (line) box whether the box has reached the clamp
point's BFC offset, and place an ellipsis or hide the box depending on
it. For line boxes, this comparison requires computing the BFC offset
at which the line will finish, before it is computed naturally as part
of the inline layout algorithm. And if no box ends right at the clamp
offset, which is almost every time, the layout has to be redone.

An alternative way of doing this work would be by always doing a
relayout: the first pass computes which line number to clamp at, and
the second pass can behave the same as `line-clamp: 3`.

A complication is that with `line-clamp: auto`, unlike with
`line-clamp: 3`, it is possible to break between two lineless boxes.
To account for this, we store both a number of lines until clamp, as
well as a number of remaining boxes between the last line and the
clamp point. We pack the lines and the remaining boxes into a
`LineClampData::UntilClamp` struct.

Since the previous implementation ellipsized lines based on whether
they end at the clamp point, it means that a line could have an
ellipsis even when it was followed by a zero-height block. It also
meant that if a line inside a block with a set `height` might not have
an ellipsis even if it was the last line before clamp, because it did
not end at the clamp point. This patch fixes those bugs, and adds (or
in the case of `line-clamp-auto-032.tentative.html`, fixes) tests for
them.

In cases where the last line before clamp is followed by an abspos,
however, it seems like it would be unexpected for the line to not have
the ellipsis. This remains to be discussed with the CSS Working Group
(see w3c/csswg-drafts#10868), but since
there are previously written tests that rely on this behavior, we have
chosen to special case abspos so such a line is ellipsized.

Bug: 40336192, 367892771
Change-Id: I45881ce76b7b23de731ae69ef5c947957cc7cf93
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5868971
Reviewed-by: Koji Ishii 
Commit-Queue: Andreu Botella 
Reviewed-by: Ian Kilpatrick 
Cr-Commit-Position: refs/heads/main@{#1358023}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 20, 2024
The current way `line-clamp: auto` works is by checking at every line
and after every (line) box whether the box has reached the clamp
point's BFC offset, and place an ellipsis or hide the box depending on
it. For line boxes, this comparison requires computing the BFC offset
at which the line will finish, before it is computed naturally as part
of the inline layout algorithm. And if no box ends right at the clamp
offset, which is almost every time, the layout has to be redone.

An alternative way of doing this work would be by always doing a
relayout: the first pass computes which line number to clamp at, and
the second pass can behave the same as `line-clamp: 3`.

A complication is that with `line-clamp: auto`, unlike with
`line-clamp: 3`, it is possible to break between two lineless boxes.
To account for this, we store both a number of lines until clamp, as
well as a number of remaining boxes between the last line and the
clamp point. We pack the lines and the remaining boxes into a
`LineClampData::UntilClamp` struct.

Since the previous implementation ellipsized lines based on whether
they end at the clamp point, it means that a line could have an
ellipsis even when it was followed by a zero-height block. It also
meant that if a line inside a block with a set `height` might not have
an ellipsis even if it was the last line before clamp, because it did
not end at the clamp point. This patch fixes those bugs, and adds (or
in the case of `line-clamp-auto-032.tentative.html`, fixes) tests for
them.

In cases where the last line before clamp is followed by an abspos,
however, it seems like it would be unexpected for the line to not have
the ellipsis. This remains to be discussed with the CSS Working Group
(see w3c/csswg-drafts#10868), but since
there are previously written tests that rely on this behavior, we have
chosen to special case abspos so such a line is ellipsized.

Bug: 40336192, 367892771
Change-Id: I45881ce76b7b23de731ae69ef5c947957cc7cf93
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5868971
Reviewed-by: Koji Ishii 
Commit-Queue: Andreu Botella 
Reviewed-by: Ian Kilpatrick 
Cr-Commit-Position: refs/heads/main@{#1358023}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 20, 2024
The current way `line-clamp: auto` works is by checking at every line
and after every (line) box whether the box has reached the clamp
point's BFC offset, and place an ellipsis or hide the box depending on
it. For line boxes, this comparison requires computing the BFC offset
at which the line will finish, before it is computed naturally as part
of the inline layout algorithm. And if no box ends right at the clamp
offset, which is almost every time, the layout has to be redone.

An alternative way of doing this work would be by always doing a
relayout: the first pass computes which line number to clamp at, and
the second pass can behave the same as `line-clamp: 3`.

A complication is that with `line-clamp: auto`, unlike with
`line-clamp: 3`, it is possible to break between two lineless boxes.
To account for this, we store both a number of lines until clamp, as
well as a number of remaining boxes between the last line and the
clamp point. We pack the lines and the remaining boxes into a
`LineClampData::UntilClamp` struct.

Since the previous implementation ellipsized lines based on whether
they end at the clamp point, it means that a line could have an
ellipsis even when it was followed by a zero-height block. It also
meant that if a line inside a block with a set `height` might not have
an ellipsis even if it was the last line before clamp, because it did
not end at the clamp point. This patch fixes those bugs, and adds (or
in the case of `line-clamp-auto-032.tentative.html`, fixes) tests for
them.

In cases where the last line before clamp is followed by an abspos,
however, it seems like it would be unexpected for the line to not have
the ellipsis. This remains to be discussed with the CSS Working Group
(see w3c/csswg-drafts#10868), but since
there are previously written tests that rely on this behavior, we have
chosen to special case abspos so such a line is ellipsized.

Bug: 40336192, 367892771
Change-Id: I45881ce76b7b23de731ae69ef5c947957cc7cf93
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5868971
Reviewed-by: Koji Ishii 
Commit-Queue: Andreu Botella 
Reviewed-by: Ian Kilpatrick 
Cr-Commit-Position: refs/heads/main@{#1358023}
@andreubotella
Copy link
Member Author

andreubotella commented Sep 23, 2024

cc @frivoal @fantasai @emilio @bfgeek

Talking with Florian earlier, it looks like the "immediately preceding" spec text might have been written in the context of clamping by a number of lines, and the possibility of clamping by a height was not considered at that time. Given that, should the last line box before the clamp point always be ellipsized?

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Sep 25, 2024
…, a=testonly

Automatic update from web-platform-tests
[line-clamp] Refactor `line-clamp: auto`

The current way `line-clamp: auto` works is by checking at every line
and after every (line) box whether the box has reached the clamp
point's BFC offset, and place an ellipsis or hide the box depending on
it. For line boxes, this comparison requires computing the BFC offset
at which the line will finish, before it is computed naturally as part
of the inline layout algorithm. And if no box ends right at the clamp
offset, which is almost every time, the layout has to be redone.

An alternative way of doing this work would be by always doing a
relayout: the first pass computes which line number to clamp at, and
the second pass can behave the same as `line-clamp: 3`.

A complication is that with `line-clamp: auto`, unlike with
`line-clamp: 3`, it is possible to break between two lineless boxes.
To account for this, we store both a number of lines until clamp, as
well as a number of remaining boxes between the last line and the
clamp point. We pack the lines and the remaining boxes into a
`LineClampData::UntilClamp` struct.

Since the previous implementation ellipsized lines based on whether
they end at the clamp point, it means that a line could have an
ellipsis even when it was followed by a zero-height block. It also
meant that if a line inside a block with a set `height` might not have
an ellipsis even if it was the last line before clamp, because it did
not end at the clamp point. This patch fixes those bugs, and adds (or
in the case of `line-clamp-auto-032.tentative.html`, fixes) tests for
them.

In cases where the last line before clamp is followed by an abspos,
however, it seems like it would be unexpected for the line to not have
the ellipsis. This remains to be discussed with the CSS Working Group
(see w3c/csswg-drafts#10868), but since
there are previously written tests that rely on this behavior, we have
chosen to special case abspos so such a line is ellipsized.

Bug: 40336192, 367892771
Change-Id: I45881ce76b7b23de731ae69ef5c947957cc7cf93
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5868971
Reviewed-by: Koji Ishii 
Commit-Queue: Andreu Botella 
Reviewed-by: Ian Kilpatrick 
Cr-Commit-Position: refs/heads/main@{#1358023}

--

wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01
wpt-pr: 48282
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Sep 26, 2024
…, a=testonly

Automatic update from web-platform-tests
[line-clamp] Refactor `line-clamp: auto`

The current way `line-clamp: auto` works is by checking at every line
and after every (line) box whether the box has reached the clamp
point's BFC offset, and place an ellipsis or hide the box depending on
it. For line boxes, this comparison requires computing the BFC offset
at which the line will finish, before it is computed naturally as part
of the inline layout algorithm. And if no box ends right at the clamp
offset, which is almost every time, the layout has to be redone.

An alternative way of doing this work would be by always doing a
relayout: the first pass computes which line number to clamp at, and
the second pass can behave the same as `line-clamp: 3`.

A complication is that with `line-clamp: auto`, unlike with
`line-clamp: 3`, it is possible to break between two lineless boxes.
To account for this, we store both a number of lines until clamp, as
well as a number of remaining boxes between the last line and the
clamp point. We pack the lines and the remaining boxes into a
`LineClampData::UntilClamp` struct.

Since the previous implementation ellipsized lines based on whether
they end at the clamp point, it means that a line could have an
ellipsis even when it was followed by a zero-height block. It also
meant that if a line inside a block with a set `height` might not have
an ellipsis even if it was the last line before clamp, because it did
not end at the clamp point. This patch fixes those bugs, and adds (or
in the case of `line-clamp-auto-032.tentative.html`, fixes) tests for
them.

In cases where the last line before clamp is followed by an abspos,
however, it seems like it would be unexpected for the line to not have
the ellipsis. This remains to be discussed with the CSS Working Group
(see w3c/csswg-drafts#10868), but since
there are previously written tests that rely on this behavior, we have
chosen to special case abspos so such a line is ellipsized.

Bug: 40336192, 367892771
Change-Id: I45881ce76b7b23de731ae69ef5c947957cc7cf93
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5868971
Reviewed-by: Koji Ishii 
Commit-Queue: Andreu Botella 
Reviewed-by: Ian Kilpatrick 
Cr-Commit-Position: refs/heads/main{#1358023}

--

wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01
wpt-pr: 48282

UltraBlame original commit: 1a1e7abe3b39cb004302723d5ffb138bd189383c
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Sep 26, 2024
…, a=testonly

Automatic update from web-platform-tests
[line-clamp] Refactor `line-clamp: auto`

The current way `line-clamp: auto` works is by checking at every line
and after every (line) box whether the box has reached the clamp
point's BFC offset, and place an ellipsis or hide the box depending on
it. For line boxes, this comparison requires computing the BFC offset
at which the line will finish, before it is computed naturally as part
of the inline layout algorithm. And if no box ends right at the clamp
offset, which is almost every time, the layout has to be redone.

An alternative way of doing this work would be by always doing a
relayout: the first pass computes which line number to clamp at, and
the second pass can behave the same as `line-clamp: 3`.

A complication is that with `line-clamp: auto`, unlike with
`line-clamp: 3`, it is possible to break between two lineless boxes.
To account for this, we store both a number of lines until clamp, as
well as a number of remaining boxes between the last line and the
clamp point. We pack the lines and the remaining boxes into a
`LineClampData::UntilClamp` struct.

Since the previous implementation ellipsized lines based on whether
they end at the clamp point, it means that a line could have an
ellipsis even when it was followed by a zero-height block. It also
meant that if a line inside a block with a set `height` might not have
an ellipsis even if it was the last line before clamp, because it did
not end at the clamp point. This patch fixes those bugs, and adds (or
in the case of `line-clamp-auto-032.tentative.html`, fixes) tests for
them.

In cases where the last line before clamp is followed by an abspos,
however, it seems like it would be unexpected for the line to not have
the ellipsis. This remains to be discussed with the CSS Working Group
(see w3c/csswg-drafts#10868), but since
there are previously written tests that rely on this behavior, we have
chosen to special case abspos so such a line is ellipsized.

Bug: 40336192, 367892771
Change-Id: I45881ce76b7b23de731ae69ef5c947957cc7cf93
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5868971
Reviewed-by: Koji Ishii 
Commit-Queue: Andreu Botella 
Reviewed-by: Ian Kilpatrick 
Cr-Commit-Position: refs/heads/main{#1358023}

--

wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01
wpt-pr: 48282

UltraBlame original commit: 1a1e7abe3b39cb004302723d5ffb138bd189383c
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Sep 26, 2024
…, a=testonly

Automatic update from web-platform-tests
[line-clamp] Refactor `line-clamp: auto`

The current way `line-clamp: auto` works is by checking at every line
and after every (line) box whether the box has reached the clamp
point's BFC offset, and place an ellipsis or hide the box depending on
it. For line boxes, this comparison requires computing the BFC offset
at which the line will finish, before it is computed naturally as part
of the inline layout algorithm. And if no box ends right at the clamp
offset, which is almost every time, the layout has to be redone.

An alternative way of doing this work would be by always doing a
relayout: the first pass computes which line number to clamp at, and
the second pass can behave the same as `line-clamp: 3`.

A complication is that with `line-clamp: auto`, unlike with
`line-clamp: 3`, it is possible to break between two lineless boxes.
To account for this, we store both a number of lines until clamp, as
well as a number of remaining boxes between the last line and the
clamp point. We pack the lines and the remaining boxes into a
`LineClampData::UntilClamp` struct.

Since the previous implementation ellipsized lines based on whether
they end at the clamp point, it means that a line could have an
ellipsis even when it was followed by a zero-height block. It also
meant that if a line inside a block with a set `height` might not have
an ellipsis even if it was the last line before clamp, because it did
not end at the clamp point. This patch fixes those bugs, and adds (or
in the case of `line-clamp-auto-032.tentative.html`, fixes) tests for
them.

In cases where the last line before clamp is followed by an abspos,
however, it seems like it would be unexpected for the line to not have
the ellipsis. This remains to be discussed with the CSS Working Group
(see w3c/csswg-drafts#10868), but since
there are previously written tests that rely on this behavior, we have
chosen to special case abspos so such a line is ellipsized.

Bug: 40336192, 367892771
Change-Id: I45881ce76b7b23de731ae69ef5c947957cc7cf93
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5868971
Reviewed-by: Koji Ishii 
Commit-Queue: Andreu Botella 
Reviewed-by: Ian Kilpatrick 
Cr-Commit-Position: refs/heads/main{#1358023}

--

wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01
wpt-pr: 48282

UltraBlame original commit: 1a1e7abe3b39cb004302723d5ffb138bd189383c
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Sep 26, 2024
…, a=testonly

Automatic update from web-platform-tests
[line-clamp] Refactor `line-clamp: auto`

The current way `line-clamp: auto` works is by checking at every line
and after every (line) box whether the box has reached the clamp
point's BFC offset, and place an ellipsis or hide the box depending on
it. For line boxes, this comparison requires computing the BFC offset
at which the line will finish, before it is computed naturally as part
of the inline layout algorithm. And if no box ends right at the clamp
offset, which is almost every time, the layout has to be redone.

An alternative way of doing this work would be by always doing a
relayout: the first pass computes which line number to clamp at, and
the second pass can behave the same as `line-clamp: 3`.

A complication is that with `line-clamp: auto`, unlike with
`line-clamp: 3`, it is possible to break between two lineless boxes.
To account for this, we store both a number of lines until clamp, as
well as a number of remaining boxes between the last line and the
clamp point. We pack the lines and the remaining boxes into a
`LineClampData::UntilClamp` struct.

Since the previous implementation ellipsized lines based on whether
they end at the clamp point, it means that a line could have an
ellipsis even when it was followed by a zero-height block. It also
meant that if a line inside a block with a set `height` might not have
an ellipsis even if it was the last line before clamp, because it did
not end at the clamp point. This patch fixes those bugs, and adds (or
in the case of `line-clamp-auto-032.tentative.html`, fixes) tests for
them.

In cases where the last line before clamp is followed by an abspos,
however, it seems like it would be unexpected for the line to not have
the ellipsis. This remains to be discussed with the CSS Working Group
(see w3c/csswg-drafts#10868), but since
there are previously written tests that rely on this behavior, we have
chosen to special case abspos so such a line is ellipsized.

Bug: 40336192, 367892771
Change-Id: I45881ce76b7b23de731ae69ef5c947957cc7cf93
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5868971
Reviewed-by: Koji Ishii 
Commit-Queue: Andreu Botella 
Reviewed-by: Ian Kilpatrick 
Cr-Commit-Position: refs/heads/main@{#1358023}

--

wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01
wpt-pr: 48282
i3roly pushed a commit to i3roly/firefox-dynasty that referenced this issue Sep 27, 2024
…, a=testonly

Automatic update from web-platform-tests
[line-clamp] Refactor `line-clamp: auto`

The current way `line-clamp: auto` works is by checking at every line
and after every (line) box whether the box has reached the clamp
point's BFC offset, and place an ellipsis or hide the box depending on
it. For line boxes, this comparison requires computing the BFC offset
at which the line will finish, before it is computed naturally as part
of the inline layout algorithm. And if no box ends right at the clamp
offset, which is almost every time, the layout has to be redone.

An alternative way of doing this work would be by always doing a
relayout: the first pass computes which line number to clamp at, and
the second pass can behave the same as `line-clamp: 3`.

A complication is that with `line-clamp: auto`, unlike with
`line-clamp: 3`, it is possible to break between two lineless boxes.
To account for this, we store both a number of lines until clamp, as
well as a number of remaining boxes between the last line and the
clamp point. We pack the lines and the remaining boxes into a
`LineClampData::UntilClamp` struct.

Since the previous implementation ellipsized lines based on whether
they end at the clamp point, it means that a line could have an
ellipsis even when it was followed by a zero-height block. It also
meant that if a line inside a block with a set `height` might not have
an ellipsis even if it was the last line before clamp, because it did
not end at the clamp point. This patch fixes those bugs, and adds (or
in the case of `line-clamp-auto-032.tentative.html`, fixes) tests for
them.

In cases where the last line before clamp is followed by an abspos,
however, it seems like it would be unexpected for the line to not have
the ellipsis. This remains to be discussed with the CSS Working Group
(see w3c/csswg-drafts#10868), but since
there are previously written tests that rely on this behavior, we have
chosen to special case abspos so such a line is ellipsized.

Bug: 40336192, 367892771
Change-Id: I45881ce76b7b23de731ae69ef5c947957cc7cf93
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5868971
Reviewed-by: Koji Ishii 
Commit-Queue: Andreu Botella 
Reviewed-by: Ian Kilpatrick 
Cr-Commit-Position: refs/heads/main@{#1358023}

--

wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01
wpt-pr: 48282
@frivoal
Copy link
Collaborator

frivoal commented Nov 4, 2024

I've been going back and forth about this, and I think we should mostly keep the existing definition, but make an exception allowing for the anchor of out of flow elements (floats or abspos) and invisible lines between the last line and the clamp point.

I think the alternatives would be:

  • have the ellipsis in the last line anyway, regardless of subsequent content

    If there is content after the last line box and before the clamp point, it can get quite strange to put the ellipsis on the last line anyway: Imagine a (block) image, a table, a flexbox… having the ellipsis, then some more content, then the break, is confusing.

    More over, as currently defined, this is an inheritable property, which affects all block containers. If we don't limit ourselves to the line immediately before the clamp point, then the last line of each clamped block would get an ellipsis, which would be very wrong in case of nested blocks.