Skip to content
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

Speculatively test :has-slotted() flattened through multiple slot elements #1

Merged
merged 1 commit into from
Sep 23, 2024

Conversation

Westbrook
Copy link
Owner

  • slotted content flattened through many slots
  • :has-slotted in parsing and visual tests

@Westbrook Westbrook merged commit e1e16ca into has-slotted Sep 23, 2024
@Westbrook Westbrook deleted the has-slotted-expanded branch September 23, 2024 18:56
Westbrook pushed a commit that referenced this pull request Nov 21, 2024
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 web-platform-tests#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}
Westbrook pushed a commit that referenced this pull request Nov 21, 2024
This implements the core Sanitizer logic. This is still missing
spec-mandated handling of "javascript:" URLs, and will have to be
updated as the spec develops. But other than that, the basics are now
there.

------------------

This a re-land of crrev.com/c/5922125. Patch set #1 is the original version,
as reviewed and submitted there. Patch set web-platform-tests#2 contains the fix. Analysis of
the bug is in https://issues.chromium.org/issues/356601280#comment16

Bug: 356601280, 379235386, 379246316
Change-Id: I06d4a9a378330cc76015e3922b9e288d9503881a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6021482
Reviewed-by: Yifan Luo <[email protected]>
Reviewed-by: Joey Arhar <[email protected]>
Commit-Queue: Daniel Vogelheim <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1385522}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant