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

Fix WPT CSS Counters test #41799

Merged
merged 1 commit into from
Oct 3, 2023
Merged

Conversation

chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented Sep 4, 2023

As per:
https://drafts.csswg.org/css-contain/#example-6932a400
and
w3c/csswg-drafts#9116
counter() and counters() can cross the style containment boundary,
so the result should be 13 from the body's counter-reset.

Bug: 990657
Change-Id: Iee313a5ed6f487865b1b7c754aa45b736f6b8f15
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4836162
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Daniil Sakhapov <sakhapov@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1204571}

Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The review process for this patch is being conducted in the Chromium project.

Comment on lines 65 to 68
<!-- 4 span inside the <p>. However, since div isn't a sibling of spans,
it creates a new counter.
it creates a new counter, which is allowed to access the 13 from the
counter-reset on the body as per example at:
https://drafts.csswg.org/css-contain/#containment-style
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can seem to mean that the new counter is instantiated on the div. Maybe

  <!-- The <span> aren't allowed to modify the counter instantiated on the <body>,
       so a new instance of the counter is created.
       Since the <div> isn't a sibling of the <span>, it will not inherit this new instance,
       and instead it will read the original counter from the <body>, with value 13.
       This is per example at: https://drafts.csswg.org/css-contain/#containment-style

Also noting that even if the div were a sibling of the span, I think that currently it wouldn't inherit the nested counter due to #5477, but this was a bad decision that I want to revert.

@@ -63,9 +63,11 @@
<p> <span></span> <span></span> <span></span> <span></span>

<!-- 4 span inside the <p>. However, since div isn't a sibling of spans,
it creates a new counter.
it creates a new counter, which is allowed to access the 13 from the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The GH UI for suggestions is broken so I can't actually drop a suggestion here, but the text should instead say:

However, since div isn't a sibling of the spans,
it sees the original counter value on body, as per example at:

Copy link
Contributor

@tabatkins tabatkins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit on the comment wording, which is somewhat misleading, but otherwise R+

@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-4836162 branch 2 times, most recently from 489ed01 to 6660f02 Compare October 2, 2023 12:59
As per:
https://drafts.csswg.org/css-contain/#example-6932a400
and
w3c/csswg-drafts#9116
counter() and counters() can cross the style containment boundary,
so the result should be 13 from the body's counter-reset.

Bug: 990657
Change-Id: Iee313a5ed6f487865b1b7c754aa45b736f6b8f15
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4836162
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Daniil Sakhapov <sakhapov@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1204571}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants