-
Notifications
You must be signed in to change notification settings - Fork 719
[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
Comments
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
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 IshiiCommit-Queue: Andreu Botella Reviewed-by: Ian Kilpatrick Cr-Commit-Position: refs/heads/main@{#1358023}
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 IshiiCommit-Queue: Andreu Botella Reviewed-by: Ian Kilpatrick Cr-Commit-Position: refs/heads/main@{#1358023}
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 IshiiCommit-Queue: Andreu Botella Reviewed-by: Ian Kilpatrick Cr-Commit-Position: refs/heads/main@{#1358023}
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? |
…, 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 IshiiCommit-Queue: Andreu Botella Reviewed-by: Ian Kilpatrick Cr-Commit-Position: refs/heads/main@{#1358023} -- wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01 wpt-pr: 48282
…, 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 IshiiCommit-Queue: Andreu Botella Reviewed-by: Ian Kilpatrick Cr-Commit-Position: refs/heads/main{#1358023} -- wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01 wpt-pr: 48282 UltraBlame original commit: 1a1e7abe3b39cb004302723d5ffb138bd189383c
…, 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 IshiiCommit-Queue: Andreu Botella Reviewed-by: Ian Kilpatrick Cr-Commit-Position: refs/heads/main{#1358023} -- wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01 wpt-pr: 48282 UltraBlame original commit: 1a1e7abe3b39cb004302723d5ffb138bd189383c
…, 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 IshiiCommit-Queue: Andreu Botella Reviewed-by: Ian Kilpatrick Cr-Commit-Position: refs/heads/main{#1358023} -- wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01 wpt-pr: 48282 UltraBlame original commit: 1a1e7abe3b39cb004302723d5ffb138bd189383c
…, 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 IshiiCommit-Queue: Andreu Botella Reviewed-by: Ian Kilpatrick Cr-Commit-Position: refs/heads/main@{#1358023} -- wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01 wpt-pr: 48282
…, 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 IshiiCommit-Queue: Andreu Botella Reviewed-by: Ian Kilpatrick Cr-Commit-Position: refs/heads/main@{#1358023} -- wpt-commits: 865ba121f136d8fcc8a4f81517119029cc177a01 wpt-pr: 48282
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:
|
Uh oh!
There was an error while loading. Please reload this page.
block-ellipsis
, which is one of the properties thatline-clamp
is a shorthand for, creates an ellipsis on the last line before clamp, if that line box "immediately precedes" the region break. Sincemax-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:
But there wouldn't be an ellipsis if an entire box sits in between:
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 ofcontinue: collapse
in Chromium, though, and it would need some heavy refactoring before it would be possible.)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.
cc @frivoal @bfgeek @emilio
The text was updated successfully, but these errors were encountered: