forked from mozilla/gecko-dev
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Checklist #1
Comments
aubymori
pushed a commit
that referenced
this issue
Nov 18, 2024
…t/last formatted line., a=testonly Automatic update from web-platform-tests [text-box-trim] More spec-compliant first/last formatted line. 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-commits: 274bd0d593efebce81292bc6f9a8ca58c578e343 wpt-pr: 48815
hi :3 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Here's a list of things that need to be done for Nara, in no particular order:
-moz-outline-radius
-moz-image-region
prefpane
)prefpane
control and also seem to be gone. Will not add this as a task for now. We'll see when the time comes.*There are two ways to go about this:
The text was updated successfully, but these errors were encountered: