[go: nahoru, domu]
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.

Sign up for GitHub

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

Jump to bottom

[css-pseudo] Highlight pseudos and forced-color-adjust #7264

Closed
dandclark opened this issue May 10, 2022 · 5 comments
Closed

[css-pseudo] Highlight pseudos and forced-color-adjust #7264

dandclark opened this issue May 10, 2022 · 5 comments
Labels
Closed Accepted by CSSWG Resolution Commenter Response Pending css-pseudo-4 Current Work

Comments

@dandclark
Copy link
Contributor

I'd like to try to clarify how forced-color-adjust should apply to highlight pseudos.

In crbug.com/1309835, @andruud raised the question of how forced-color-adjust:preserve-parent-color should interact with the special definition of currentColor used with highlight inheritance. Normally preserve-parent-color has currentColor compute to the used value of the parent's color, but with highlights it's not so clear what this value should resolve to. Making it dependent on which highlight overlays are active could be problematic as that info may not be readily available until paint-time.

A simple way to resolve any strangeness could be to just treat forced-color-adjust:preserve-parent-color as forced-color-adjust:none for highlights. The motivating use case for preserve-parent-color involving SVG icons doesn't seem to be applicable to highlight pseudos as far as I can tell.

Considering things more broadly, does it make sense to allow forced-color-adjust in highlight pseudos at all? It is not one of the properties listed at https://drafts.csswg.org/css-pseudo-4/#highlight-styling, but Chrome allows it to be used with ::selection and the other highlight pseudos when --enable-blink-features=HighlightInheritance is enabled. Example here. (When HighlightInheritance is not enabled, Chrome looks like it always ignores forced colors for ::selection pseudos, which seems clearly wrong).

Perhaps highlights should always just use the forced-colors state of the originating element. Does it actually make sense to allow authors to opt out of forced colors for highlights but not the element containing the underlying text? Or vice versa?

cc @alisonmaher @delan @mrego
@dandclark dandclark added the css-pseudo-4 Current Work label May 10, 2022
@delan
Copy link
Contributor
delan commented May 10, 2022

(ping @fantasai, @frivoal)

@css-meeting-bot
Copy link
Member
css-meeting-bot commented May 18, 2022 •
edited by fantasai
Loading

The CSS Working Group just discussed [css-pseudo] Highlight pseudos and forced-color-adjust, and agreed to the following:

  • RESOLVED: forced-color-adjust doesn't do anything on highlight pseudos, and highlight pseudos take their forced color state from the originating element
The full IRC log of that discussion <dbaron> Topic: [css-pseudo] Highlight pseudos and forced-color-adjust
<emilio> (I guess that's what chrishtr just said)
<dbaron> github: https://github.com//issues/7264
<dbaron> dandclark: question about how forced-color-adjust:preserve-parent-color should work with highlight inheritance
<dbaron> dandclark: this interaction is potentially problematic.
<fantasai> emilio, yeah, and it's obnoxious when I try to load a page and it gives me a blank forever even though I know the text is loaded
<dbaron> dandclark: Prereq: consider wether forced-color-adjust should be allowed in highlight pseudos.
<dbaron> dandclark: List of properties. Currently not allowed there.
<Rossen_> q?
<dbaron> s/Prereq/Prerequisite/
<dbaron> s/List/The spec gives a list/
<dbaron> s/wether/whether/
<dbaron> fantasai: I think the idea of having it not apply and just applying the forced-color-adjust effect of the originating element makes sense to me.
<dbaron> fantasai: I think that was mentioned in the post as a way to deal with this.
<dbaron> dandclark: I think that's a good outcome... seems simplest.
<dbaron> dandclark: For all other color based properties the highlights are sort of an independent cascade. But I think it makes sense here. Seems odd that the originating element would take forced colors and the highlights not.
<dbaron> dandclark: If the originating element has forced-color-adjust:preserve-parent-color, what does that mean for highlight pseudos that are active over that originating element?
<dbaron> fantasai: Effect is that the color property is able to inherit from the parent the actual color of the parent... and that doesn't really impact the highlight pseudos ... which doesn't matter for highlight pseudos where the currentcolor keyword comes from the previous layer. So the keyword wouldn't have an effect.
<dbaron> dandclark: so then try to resolve that forced-color-adjust doesn't do anything on highlight pseudos, and that highlight pseudos take forced color state of originating element
<dbaron> Rossen: Proposed resolution: forced-color-adjust doesn't do anything on highlight pseudos, and highlight pseudos take their forced color state from the originating element
<dbaron> RESOLVED: forced-color-adjust doesn't do anything on highlight pseudos, and highlight pseudos take their forced color state from the originating element

See official minutes

@mozilla-apprentice mozilla-apprentice mentioned this issue May 18, 2022
Open
@dandclark
Copy link
Contributor Author

@fantasai Could you help me understand what these tags mean?
I'm guessing that Needs Edits means that a spec change is needed to reflect the meeting resolution, but I'm not sure about Closed Accepted by CSSWG Resolution.

Sorry if these are documented somewhere; I looked but couldn't find anything.

@astearns astearns removed the Agenda+ label May 18, 2022
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 26, 2022
@dandclark @chromium-wpt-export-bot
Highlight pseudos use the forced-color status of their originating el…
279e1cc 
…ement

Per the resolution in [1], forced-color-adjust should not be one of the
supported properties [2] in highlight pseudos, and the forced-color
state of highlights should be taken from the originating element. This
change updates the HighlightInheritance implementation to match the
resolution.

There are a few parts to this:
- css_properties.json5 is updated so that forced-color-adjust is no
  longer a valid property for highlight pseudos. But, since shipping
  this change for ::selection may cause compatibility issues, we
  introduce a new valid_for_highlight_legacy parameter that maintains
  the old behavior and we update valid_for_highlight, which will be used
  only for highlights with the new inheritance model enabled, to use the
  new behavior.
- This uncovered an older bug where DetermineValidPropertyFilter wasn't
  using any filter at all for ::highlight(), ::spelling-error, and
  ::grammar-error. This is now fixed.
- StyleResolver::ApplyInheritance is updated to propagate forced-colors
  status from the originating element to the corresponding highlight
  pseudo.

The new test is disabled on Mac/Linux due to some small differences
in text decoration painting between those from highlight pseudos
and from non-highlight rules, unrelated to the contents of this change.

[1] w3c/csswg-drafts#7264 (comment)
[2] https://drafts.csswg.org/css-pseudo-4/#highlight-styling

Bug: 1309835, 1024156
Change-Id: I732afd24bbba2619a6718270faa0a1d2fcb98512
Merged
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 31, 2022
@dandclark @chromium-wpt-export-bot
Highlight pseudos use the forced-color status of their originating el…
61a4019 
…ement

Per the resolution in [1], forced-color-adjust should not be one of the
supported properties [2] in highlight pseudos, and the forced-color
state of highlights should be taken from the originating element. This
change updates the HighlightInheritance implementation to match the
resolution.

There are a few parts to this:
- css_properties.json5 is updated so that forced-color-adjust is no
  longer a valid property for highlight pseudos. But, since shipping
  this change for ::selection may cause compatibility issues, we
  introduce a new valid_for_highlight_legacy parameter that maintains
  the old behavior and we update valid_for_highlight, which will be used
  only for highlights with the new inheritance model enabled, to use the
  new behavior.
- This uncovered an older bug where DetermineValidPropertyFilter wasn't
  using any filter at all for ::highlight(), ::spelling-error, and
  ::grammar-error. This is now fixed.
- StyleResolver::ApplyInheritance is updated to propagate forced-colors
  status from the originating element to the corresponding highlight
  pseudo.

The new test is disabled on Mac/Linux due to some small differences
in text decoration painting between those from highlight pseudos
and from non-highlight rules, unrelated to the contents of this change.

[1] w3c/csswg-drafts#7264 (comment)
[2] https://drafts.csswg.org/css-pseudo-4/#highlight-styling

Bug: 1309835, 1024156
Change-Id: I732afd24bbba2619a6718270faa0a1d2fcb98512
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 31, 2022
@dandclark @chromium-wpt-export-bot
Highlight pseudos use the forced-color status of their originating el…
98d285d 
…ement

Per the resolution in [1], forced-color-adjust should not be one of the
supported properties [2] in highlight pseudos, and the forced-color
state of highlights should be taken from the originating element. This
change updates the HighlightInheritance implementation to match the
resolution.

There are a few parts to this:
- css_properties.json5 is updated so that forced-color-adjust is no
  longer a valid property for highlight pseudos. But, since shipping
  this change for ::selection may cause compatibility issues, we
  introduce a new valid_for_highlight_legacy parameter that maintains
  the old behavior and we update valid_for_highlight, which will be used
  only for highlights with the new inheritance model enabled, to use the
  new behavior.
- This uncovered an older bug where DetermineValidPropertyFilter wasn't
  using any filter at all for ::highlight(), ::spelling-error, and
  ::grammar-error. This is now fixed.
- StyleResolver::ApplyInheritance is updated to propagate forced-colors
  status from the originating element to the corresponding highlight
  pseudo.

The new test is disabled on Mac/Linux due to some small differences
in text decoration painting between those from highlight pseudos
and from non-highlight rules, unrelated to the contents of this change.

[1] w3c/csswg-drafts#7264 (comment)
[2] https://drafts.csswg.org/css-pseudo-4/#highlight-styling

Bug: 1309835, 1024156
Change-Id: I732afd24bbba2619a6718270faa0a1d2fcb98512
aarongable pushed a commit to chromium/chromium that referenced this issue Jun 1, 2022
@dandclark
Highlight pseudos use the forced-color status of their originating el…
e3dd441 
…ement

Per the resolution in [1], forced-color-adjust should not be one of the
supported properties [2] in highlight pseudos, and the forced-color
state of highlights should be taken from the originating element. This
change updates the HighlightInheritance implementation to match the
resolution.

There are a few parts to this:
- css_properties.json5 is updated so that forced-color-adjust is no
  longer a valid property for highlight pseudos. But, since shipping
  this change for ::selection may cause compatibility issues, we
  introduce a new valid_for_highlight_legacy parameter that maintains
  the old behavior and we update valid_for_highlight, which will be used
  only for highlights with the new inheritance model enabled, to use the
  new behavior.
- This uncovered an older bug where DetermineValidPropertyFilter wasn't
  using any filter at all for ::highlight(), ::spelling-error, and
  ::grammar-error. This is now fixed.
- StyleResolver::ApplyInheritance is updated to propagate forced-colors
  status from the originating element to the corresponding highlight
  pseudo.

The new test is disabled on Mac/Linux due to some small differences
in text decoration painting between those from highlight pseudos
and from non-highlight rules, unrelated to the contents of this change.

[1] w3c/csswg-drafts#7264 (comment)
[2] https://drafts.csswg.org/css-pseudo-4/#highlight-styling


Bug: 1309835, 1024156
Change-Id: I732afd24bbba2619a6718270faa0a1d2fcb98512
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3665644
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Delan Azabani <dazabani@igalia.com>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1009639}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 1, 2022
@dandclark @chromium-wpt-export-bot
Highlight pseudos use the forced-color status of their originating el…
7208741 
…ement

Per the resolution in [1], forced-color-adjust should not be one of the
supported properties [2] in highlight pseudos, and the forced-color
state of highlights should be taken from the originating element. This
change updates the HighlightInheritance implementation to match the
resolution.

There are a few parts to this:
- css_properties.json5 is updated so that forced-color-adjust is no
  longer a valid property for highlight pseudos. But, since shipping
  this change for ::selection may cause compatibility issues, we
  introduce a new valid_for_highlight_legacy parameter that maintains
  the old behavior and we update valid_for_highlight, which will be used
  only for highlights with the new inheritance model enabled, to use the
  new behavior.
- This uncovered an older bug where DetermineValidPropertyFilter wasn't
  using any filter at all for ::highlight(), ::spelling-error, and
  ::grammar-error. This is now fixed.
- StyleResolver::ApplyInheritance is updated to propagate forced-colors
  status from the originating element to the corresponding highlight
  pseudo.

The new test is disabled on Mac/Linux due to some small differences
in text decoration painting between those from highlight pseudos
and from non-highlight rules, unrelated to the contents of this change.

[1] w3c/csswg-drafts#7264 (comment)
[2] https://drafts.csswg.org/css-pseudo-4/#highlight-styling

Bug: 1309835, 1024156
Change-Id: I732afd24bbba2619a6718270faa0a1d2fcb98512
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3665644
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Delan Azabani <dazabani@igalia.com>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1009639}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 1, 2022
@dandclark @chromium-wpt-export-bot
Highlight pseudos use the forced-color status of their originating el…
2350576 
…ement

Per the resolution in [1], forced-color-adjust should not be one of the
supported properties [2] in highlight pseudos, and the forced-color
state of highlights should be taken from the originating element. This
change updates the HighlightInheritance implementation to match the
resolution.

There are a few parts to this:
- css_properties.json5 is updated so that forced-color-adjust is no
  longer a valid property for highlight pseudos. But, since shipping
  this change for ::selection may cause compatibility issues, we
  introduce a new valid_for_highlight_legacy parameter that maintains
  the old behavior and we update valid_for_highlight, which will be used
  only for highlights with the new inheritance model enabled, to use the
  new behavior.
- This uncovered an older bug where DetermineValidPropertyFilter wasn't
  using any filter at all for ::highlight(), ::spelling-error, and
  ::grammar-error. This is now fixed.
- StyleResolver::ApplyInheritance is updated to propagate forced-colors
  status from the originating element to the corresponding highlight
  pseudo.

The new test is disabled on Mac/Linux due to some small differences
in text decoration painting between those from highlight pseudos
and from non-highlight rules, unrelated to the contents of this change.

[1] w3c/csswg-drafts#7264 (comment)
[2] https://drafts.csswg.org/css-pseudo-4/#highlight-styling

Bug: 1309835, 1024156
Change-Id: I732afd24bbba2619a6718270faa0a1d2fcb98512
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3665644
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Delan Azabani <dazabani@igalia.com>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1009639}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jun 10, 2022
@dandclark @moz-wptsync-bot
Bug 1771389 [wpt PR 34223] - Highlight pseudos use the forced-color s…
4020774 
…tatus of their originating element, a=testonly

Automatic update from web-platform-tests
Highlight pseudos use the forced-color status of their originating element

Per the resolution in [1], forced-color-adjust should not be one of the
supported properties [2] in highlight pseudos, and the forced-color
state of highlights should be taken from the originating element. This
change updates the HighlightInheritance implementation to match the
resolution.

There are a few parts to this:
- css_properties.json5 is updated so that forced-color-adjust is no
  longer a valid property for highlight pseudos. But, since shipping
  this change for ::selection may cause compatibility issues, we
  introduce a new valid_for_highlight_legacy parameter that maintains
  the old behavior and we update valid_for_highlight, which will be used
  only for highlights with the new inheritance model enabled, to use the
  new behavior.
- This uncovered an older bug where DetermineValidPropertyFilter wasn't
  using any filter at all for ::highlight(), ::spelling-error, and
  ::grammar-error. This is now fixed.
- StyleResolver::ApplyInheritance is updated to propagate forced-colors
  status from the originating element to the corresponding highlight
  pseudo.

The new test is disabled on Mac/Linux due to some small differences
in text decoration painting between those from highlight pseudos
and from non-highlight rules, unrelated to the contents of this change.

[1] w3c/csswg-drafts#7264 (comment)
[2] https://drafts.csswg.org/css-pseudo-4/#highlight-styling

Bug: 1309835, 1024156
Change-Id: I732afd24bbba2619a6718270faa0a1d2fcb98512
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3665644
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Delan Azabani <dazabani@igalia.com>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1009639}

--

wpt-commits: 23505765f04099bac1909b4a1400eb0c02829061
wpt-pr: 34223
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
@dandclark
Highlight pseudos use the forced-color status of their originating el…
f3d6440 
…ement

Per the resolution in [1], forced-color-adjust should not be one of the
supported properties [2] in highlight pseudos, and the forced-color
state of highlights should be taken from the originating element. This
change updates the HighlightInheritance implementation to match the
resolution.

There are a few parts to this:
- css_properties.json5 is updated so that forced-color-adjust is no
  longer a valid property for highlight pseudos. But, since shipping
  this change for ::selection may cause compatibility issues, we
  introduce a new valid_for_highlight_legacy parameter that maintains
  the old behavior and we update valid_for_highlight, which will be used
  only for highlights with the new inheritance model enabled, to use the
  new behavior.
- This uncovered an older bug where DetermineValidPropertyFilter wasn't
  using any filter at all for ::highlight(), ::spelling-error, and
  ::grammar-error. This is now fixed.
- StyleResolver::ApplyInheritance is updated to propagate forced-colors
  status from the originating element to the corresponding highlight
  pseudo.

The new test is disabled on Mac/Linux due to some small differences
in text decoration painting between those from highlight pseudos
and from non-highlight rules, unrelated to the contents of this change.

[1] w3c/csswg-drafts#7264 (comment)
[2] https://drafts.csswg.org/css-pseudo-4/#highlight-styling

Bug: 1309835, 1024156
Change-Id: I732afd24bbba2619a6718270faa0a1d2fcb98512
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3665644
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Delan Azabani <dazabani@igalia.com>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1009639}
NOKEYCHECK=True
GitOrigin-RevId: e3dd4411efafbe9d4c285898e2c195c55612fe89
fantasai added a commit that referenced this issue Dec 29, 2022
@fantasai
[css-pseudo-4] Define forced colors mode on highlight pseudo-elements. …
05e463d 
…#7264
@fantasai
Copy link
Collaborator

@dandclark The Needs Edits label, as you guessed, means that the spec needs edits to reflect the resolution; Closed Accepted by CSSWG Resolution means that the issue was resolved by a CSSWG decision. There's other Closed labels that reflect whether it was accepted or rejected, and what type of acceptance... these are currently only documented in https://github.com/w3c/csswg-drafts/blob/main/bin/issuegen.pl#L104 and I mainly use it as a forcing function to think about what kind of decision or review might be needed.

The resolution is now edit in as 05e463d ; please let me know if that reflects your understanding of the resolution of this issue! Thanks!

@dandclark
Copy link
Contributor Author

Thanks for clarifying! 05e463d looks right to me, so I'll go ahead and fully Close this.

jakearchibald pushed a commit to jakearchibald/csswg-drafts that referenced this issue Jan 16, 2023
@fantasai @jakearchibald
[css-pseudo-4] Define forced colors mode on highlight pseudo-elements. …
e21feda 
…w3c#7264
@delan delan mentioned this issue Feb 8, 2023
Open
@delan delan mentioned this issue Jun 6, 2023
Open
@spectranaut spectranaut mentioned this issue Jul 12, 2023
Closed
Merged
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 21, 2023
@spectranaut @chromium-wpt-export-bot
Update test: forced-color-adjust does not apply to pseudo-highlights
98b4122 
The updated tests relied on ‘forced-color-adjust’ being applicable
to highlight pseudos, which is no longer the case as of:
w3c/csswg-drafts#7264

Bug: 1400970
Change-Id: I0872a85903f2abf73edd50429be83a48c3bc735e
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 24, 2023
@spectranaut @chromium-wpt-export-bot
Update test: forced-color-adjust does not apply to pseudo-highlights
8475d09 
The updated tests relied on ‘forced-color-adjust’ being applicable
to highlight pseudos, which is no longer the case as of:
w3c/csswg-drafts#7264

Bug: 1400970
Change-Id: I0872a85903f2abf73edd50429be83a48c3bc735e
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 24, 2023
@spectranaut @chromium-wpt-export-bot
Update test: forced-color-adjust does not apply to pseudo-highlights
899634e 
The updated tests relied on ‘forced-color-adjust’ being applicable
to highlight pseudos, which is no longer the case as of:
w3c/csswg-drafts#7264

Bug: 1400970
Change-Id: I0872a85903f2abf73edd50429be83a48c3bc735e
aarongable pushed a commit to chromium/chromium that referenced this issue Jul 25, 2023
@spectranaut
Update test: forced-color-adjust does not apply to pseudo-highlights
9b8121f 
The updated tests relied on ‘forced-color-adjust’ being applicable
to highlight pseudos, which is no longer the case as of:
w3c/csswg-drafts#7264

Bug: 1400970
Change-Id: I0872a85903f2abf73edd50429be83a48c3bc735e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4705311
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1175025}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 25, 2023
@spectranaut @chromium-wpt-export-bot
Update test: forced-color-adjust does not apply to pseudo-highlights
54fc4ef 
The updated tests relied on ‘forced-color-adjust’ being applicable
to highlight pseudos, which is no longer the case as of:
w3c/csswg-drafts#7264

Bug: 1400970
Change-Id: I0872a85903f2abf73edd50429be83a48c3bc735e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4705311
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1175025}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 25, 2023
@spectranaut @chromium-wpt-export-bot
Update test: forced-color-adjust does not apply to pseudo-highlights
2217dea 
The updated tests relied on ‘forced-color-adjust’ being applicable
to highlight pseudos, which is no longer the case as of:
w3c/csswg-drafts#7264

Bug: 1400970
Change-Id: I0872a85903f2abf73edd50429be83a48c3bc735e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4705311
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1175025}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Aug 2, 2023
@spectranaut @moz-wptsync-bot
Bug 1844703 [wpt PR 41140] - Update test: forced-color-adjust does no…
b2fef98 
…t apply to pseudo-highlights, a=testonly

Automatic update from web-platform-tests
Update test: forced-color-adjust does not apply to pseudo-highlights

The updated tests relied on ‘forced-color-adjust’ being applicable
to highlight pseudos, which is no longer the case as of:
w3c/csswg-drafts#7264

Bug: 1400970
Change-Id: I0872a85903f2abf73edd50429be83a48c3bc735e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4705311
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1175025}

--

wpt-commits: 2217dea6028932dbda4f7188ddd275cac80c82fb
wpt-pr: 41140
ErichDonGubler pushed a commit to ErichDonGubler/firefox that referenced this issue Aug 4, 2023
@spectranaut @moz-wptsync-bot
Bug 1844703 [wpt PR 41140] - Update test: forced-color-adjust does no…
3a20184 
…t apply to pseudo-highlights, a=testonly

Automatic update from web-platform-tests
Update test: forced-color-adjust does not apply to pseudo-highlights

The updated tests relied on ‘forced-color-adjust’ being applicable
to highlight pseudos, which is no longer the case as of:
w3c/csswg-drafts#7264

Bug: 1400970
Change-Id: I0872a85903f2abf73edd50429be83a48c3bc735e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4705311
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1175025}

--

wpt-commits: 2217dea6028932dbda4f7188ddd275cac80c82fb
wpt-pr: 41140
Lightning00Blade pushed a commit to Lightning00Blade/wpt that referenced this issue Dec 11, 2023
@spectranaut @Lightning00Blade
Update test: forced-color-adjust does not apply to pseudo-highlights
443df77 
The updated tests relied on ‘forced-color-adjust’ being applicable
to highlight pseudos, which is no longer the case as of:
w3c/csswg-drafts#7264

Bug: 1400970
Change-Id: I0872a85903f2abf73edd50429be83a48c3bc735e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4705311
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1175025}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution Commenter Response Pending css-pseudo-4 Current Work
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@delan @fantasai @astearns @dandclark @css-meeting-bot