[text-box-trim] More spec-compliant first/last formatted line. #48815
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
See https://drafts.csswg.org/css-pseudo-4/#first-text-line 1. For a block container that establishes an inline formatting context, the "first formatted line" is its first line box, if it has one. Otherwise, there is no first formatted line. 2. Otherwise, for a block container that has block children, look inside the first in-flow block child (if any) and do #1 if it establishes an inline formatting context. Otherwise, do #2. In short, we don't need to search for line boxes in blocks after the first block child. If there is no line in the first child, there's no "first formatted line". There's no spec for "last formatted line", but apply the same logic. I.e. if the last block child has no line, there's no "last formatted line". This allows us to simplify things a bit, especially when it comes to re-laying out (kTextBoxTrimEndDidNotApply). The only case where we need this now is for blocks inside inlines: If the last formatted line is inside a block-in-inline, we need to go back and re-lay it out if it turns out to be the last line (which isn't something we can check inside block-in-inline layout). Note: When adding support for block fragmentation, trimming at a fragmentainer's block end will be another case where we need to re-lay out. The motivation for this change was text box trimming inside block fragmentation (upcoming CL), and be able to add support for that and still be reasonably confident that it won't become too complicated. This fixes one existing test. Some other existing tests had to be updated because of this change (they were making incorrect assumptions about first/last formatted line). As a result of that, some new refs had to be added, since other tests were piggy-backing on the same ref. Bug: 40254880, 367766472 Change-Id: I3fcc53af86353725b1f5705a5528493a72bf2e69 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952979 Commit-Queue: Morten Stenshorne <[email protected]> Reviewed-by: Koji Ishii <[email protected]> Cr-Commit-Position: refs/heads/main@{#1373765}
wpt-pr-bot
approved these changes
Oct 25, 2024
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-5952979
branch
from
9d70db7 to
3ba844c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See https://drafts.csswg.org/css-pseudo-4/#first-text-line
For a block container that establishes an inline formatting context,
the "first formatted line" is its first line box, if it has one.
Otherwise, there is no first formatted line.
Otherwise, for a block container that has block children, look inside
the first in-flow block child (if any) and do Aryeh's submission #1 if it establishes an
inline formatting context. Otherwise, do Apple's submission #2.
In short, we don't need to search for line boxes in blocks after the
first block child. If there is no line in the first child, there's no
"first formatted line".
There's no spec for "last formatted line", but apply the same logic.
I.e. if the last block child has no line, there's no "last formatted
line".
This allows us to simplify things a bit, especially when it comes to
re-laying out (kTextBoxTrimEndDidNotApply). The only case where we need
this now is for blocks inside inlines: If the last formatted line is
inside a block-in-inline, we need to go back and re-lay it out if it
turns out to be the last line (which isn't something we can check inside
block-in-inline layout). Note: When adding support for block
fragmentation, trimming at a fragmentainer's block end will be another
case where we need to re-lay out.
The motivation for this change was text box trimming inside block
fragmentation (upcoming CL), and be able to add support for that and
still be reasonably confident that it won't become too complicated.
This fixes one existing test. Some other existing tests had to be
updated because of this change (they were making incorrect assumptions
about first/last formatted line). As a result of that, some new refs had
to be added, since other tests were piggy-backing on the same ref.
Bug: 40254880, 367766472
Change-Id: I3fcc53af86353725b1f5705a5528493a72bf2e69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952979
Commit-Queue: Morten Stenshorne <[email protected]>
Reviewed-by: Koji Ishii <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1373765}