[css-pseudo] [css-highlight-api] defaults and inheritance for ::spelling-error + ::grammar-error + ::highlight #6779
Labels
Comments
|
Thanks for pointing this out! For custom highlights at least, the original intention of the custom highlight #default-styles was indeed for an unstyled ::highlight to yield no visible change in rendering. I had written the spec text with the legacy ::selection behavior in mind, so it doesn't fit with the new #highlight-cascade behavior. Maybe we could change #default-styles to something like the following, borrowing some language from #highlight-text:
|
delan
added a commit
to delan/csswg-drafts
that referenced
this issue
Nov 18, 2021
Fair enough, that makes sense. I think that proposed wording is a good start, but I think it fails to account for the special relationship between ‘color’ and ‘background-color’ (paired cascade), and suffers from the same problems as “specified by the author” does in #highlight-cascade (#6386). e6ec959ad9fb3 attempts to word this in a way that builds on the clarifications I’ve proposed in #6665, what do you think? |
|
Ah, I'd missed that #6665 was also addressing this for custom highlights. It looks great to me! |
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Feb 9, 2022
The custom highlight API spec [1] currently states that an unstyled custom highlight should inherit the styles of its originating element. The Blink implementation follows this. However, this behavior can lead to some unintuitive results where unstyled highlights can affect the painting of the originating element, or paint over other highlights. This issue was pointed out in [2], and spec changes to fix this are pending editor review. A goal of these changes are that unstyled custom highlights do not affect rendering at all. This change updates the custom highlights implementation to achieve this by giving them a default 'transparent' foreground and background color. Some of our tests were validating the earlier unintuitive behavior involving overlapping ranges. These are updated, along with the addition of a new test to validate that a single unstyled highlight doesn't affect rendering. [1] https://drafts.csswg.org/css-highlight-api-1/#default-styles [2] w3c/csswg-drafts#6779 Bug: 1295271 Change-Id: Id7dc877c90c08240fbe79edeeeec551cdc5508c1
aarongable
pushed a commit
to chromium/chromium
that referenced
this issue
Feb 9, 2022
The custom highlight API spec [1] currently states that an unstyled custom highlight should inherit the styles of its originating element. The Blink implementation follows this. However, this behavior can lead to some unintuitive results where unstyled highlights can affect the painting of the originating element, or paint over other highlights. This issue was pointed out in [2], and spec changes to fix this are pending editor review. A goal of these changes are that unstyled custom highlights do not affect rendering at all. This change updates the custom highlights implementation to achieve this by giving them a default 'transparent' foreground and background color. Some of our tests were validating the earlier unintuitive behavior involving overlapping ranges. These are updated, along with the addition of a new test to validate that a single unstyled highlight doesn't affect rendering. [1] https://drafts.csswg.org/css-highlight-api-1/#default-styles [2] w3c/csswg-drafts#6779 Bug: 1295271 Change-Id: Id7dc877c90c08240fbe79edeeeec551cdc5508c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449336 Reviewed-by: Delan Azabani <dazabani@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#969007}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Feb 9, 2022
The custom highlight API spec [1] currently states that an unstyled custom highlight should inherit the styles of its originating element. The Blink implementation follows this. However, this behavior can lead to some unintuitive results where unstyled highlights can affect the painting of the originating element, or paint over other highlights. This issue was pointed out in [2], and spec changes to fix this are pending editor review. A goal of these changes are that unstyled custom highlights do not affect rendering at all. This change updates the custom highlights implementation to achieve this by giving them a default 'transparent' foreground and background color. Some of our tests were validating the earlier unintuitive behavior involving overlapping ranges. These are updated, along with the addition of a new test to validate that a single unstyled highlight doesn't affect rendering. [1] https://drafts.csswg.org/css-highlight-api-1/#default-styles [2] w3c/csswg-drafts#6779 Bug: 1295271 Change-Id: Id7dc877c90c08240fbe79edeeeec551cdc5508c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449336 Reviewed-by: Delan Azabani <dazabani@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#969007}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Feb 9, 2022
The custom highlight API spec [1] currently states that an unstyled custom highlight should inherit the styles of its originating element. The Blink implementation follows this. However, this behavior can lead to some unintuitive results where unstyled highlights can affect the painting of the originating element, or paint over other highlights. This issue was pointed out in [2], and spec changes to fix this are pending editor review. A goal of these changes are that unstyled custom highlights do not affect rendering at all. This change updates the custom highlights implementation to achieve this by giving them a default 'transparent' foreground and background color. Some of our tests were validating the earlier unintuitive behavior involving overlapping ranges. These are updated, along with the addition of a new test to validate that a single unstyled highlight doesn't affect rendering. [1] https://drafts.csswg.org/css-highlight-api-1/#default-styles [2] w3c/csswg-drafts#6779 Bug: 1295271 Change-Id: Id7dc877c90c08240fbe79edeeeec551cdc5508c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449336 Reviewed-by: Delan Azabani <dazabani@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#969007}
mattwoodrow
pushed a commit
to mattwoodrow/wpt
that referenced
this issue
Feb 15, 2022
The custom highlight API spec [1] currently states that an unstyled custom highlight should inherit the styles of its originating element. The Blink implementation follows this. However, this behavior can lead to some unintuitive results where unstyled highlights can affect the painting of the originating element, or paint over other highlights. This issue was pointed out in [2], and spec changes to fix this are pending editor review. A goal of these changes are that unstyled custom highlights do not affect rendering at all. This change updates the custom highlights implementation to achieve this by giving them a default 'transparent' foreground and background color. Some of our tests were validating the earlier unintuitive behavior involving overlapping ranges. These are updated, along with the addition of a new test to validate that a single unstyled highlight doesn't affect rendering. [1] https://drafts.csswg.org/css-highlight-api-1/#default-styles [2] w3c/csswg-drafts#6779 Bug: 1295271 Change-Id: Id7dc877c90c08240fbe79edeeeec551cdc5508c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449336 Reviewed-by: Delan Azabani <dazabani@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#969007}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Feb 26, 2022
…om highlights, a=testonly Automatic update from web-platform-tests Highlight API: Don't paint unstyled custom highlights The custom highlight API spec [1] currently states that an unstyled custom highlight should inherit the styles of its originating element. The Blink implementation follows this. However, this behavior can lead to some unintuitive results where unstyled highlights can affect the painting of the originating element, or paint over other highlights. This issue was pointed out in [2], and spec changes to fix this are pending editor review. A goal of these changes are that unstyled custom highlights do not affect rendering at all. This change updates the custom highlights implementation to achieve this by giving them a default 'transparent' foreground and background color. Some of our tests were validating the earlier unintuitive behavior involving overlapping ranges. These are updated, along with the addition of a new test to validate that a single unstyled highlight doesn't affect rendering. [1] https://drafts.csswg.org/css-highlight-api-1/#default-styles [2] w3c/csswg-drafts#6779 Bug: 1295271 Change-Id: Id7dc877c90c08240fbe79edeeeec551cdc5508c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449336 Reviewed-by: Delan Azabani <dazabani@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#969007} -- wpt-commits: 40d5e6da07fc061a6d81f081c3c16eafc10b54ce wpt-pr: 32759
DanielRyanSmith
pushed a commit
to DanielRyanSmith/wpt
that referenced
this issue
Feb 28, 2022
The custom highlight API spec [1] currently states that an unstyled custom highlight should inherit the styles of its originating element. The Blink implementation follows this. However, this behavior can lead to some unintuitive results where unstyled highlights can affect the painting of the originating element, or paint over other highlights. This issue was pointed out in [2], and spec changes to fix this are pending editor review. A goal of these changes are that unstyled custom highlights do not affect rendering at all. This change updates the custom highlights implementation to achieve this by giving them a default 'transparent' foreground and background color. Some of our tests were validating the earlier unintuitive behavior involving overlapping ranges. These are updated, along with the addition of a new test to validate that a single unstyled highlight doesn't affect rendering. [1] https://drafts.csswg.org/css-highlight-api-1/#default-styles [2] w3c/csswg-drafts#6779 Bug: 1295271 Change-Id: Id7dc877c90c08240fbe79edeeeec551cdc5508c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449336 Reviewed-by: Delan Azabani <dazabani@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#969007}
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this issue
Mar 1, 2022
…om highlights, a=testonly Automatic update from web-platform-tests Highlight API: Don't paint unstyled custom highlights The custom highlight API spec [1] currently states that an unstyled custom highlight should inherit the styles of its originating element. The Blink implementation follows this. However, this behavior can lead to some unintuitive results where unstyled highlights can affect the painting of the originating element, or paint over other highlights. This issue was pointed out in [2], and spec changes to fix this are pending editor review. A goal of these changes are that unstyled custom highlights do not affect rendering at all. This change updates the custom highlights implementation to achieve this by giving them a default 'transparent' foreground and background color. Some of our tests were validating the earlier unintuitive behavior involving overlapping ranges. These are updated, along with the addition of a new test to validate that a single unstyled highlight doesn't affect rendering. [1] https://drafts.csswg.org/css-highlight-api-1/#default-styles [2] w3c/csswg-drafts#6779 Bug: 1295271 Change-Id: Id7dc877c90c08240fbe79edeeeec551cdc5508c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449336 Reviewed-by: Delan Azabani <dazabani@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#969007} -- wpt-commits: 40d5e6da07fc061a6d81f081c3c16eafc10b54ce wpt-pr: 32759
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Mar 8, 2022
…om highlights, a=testonly Automatic update from web-platform-tests Highlight API: Don't paint unstyled custom highlights The custom highlight API spec [1] currently states that an unstyled custom highlight should inherit the styles of its originating element. The Blink implementation follows this. However, this behavior can lead to some unintuitive results where unstyled highlights can affect the painting of the originating element, or paint over other highlights. This issue was pointed out in [2], and spec changes to fix this are pending editor review. A goal of these changes are that unstyled custom highlights do not affect rendering at all. This change updates the custom highlights implementation to achieve this by giving them a default 'transparent' foreground and background color. Some of our tests were validating the earlier unintuitive behavior involving overlapping ranges. These are updated, along with the addition of a new test to validate that a single unstyled highlight doesn't affect rendering. [1] https://drafts.csswg.org/css-highlight-api-1/#default-styles [2] w3c/csswg-drafts#6779 Bug: 1295271 Change-Id: Id7dc877c90c08240fbe79edeeeec551cdc5508c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449336 Reviewed-by: Delan Azabani <dazabani@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#969007} -- wpt-commits: 40d5e6da07fc061a6d81f081c3c16eafc10b54ce wpt-pr: 32759
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this issue
Mar 8, 2022
…om highlights, a=testonly Automatic update from web-platform-tests Highlight API: Don't paint unstyled custom highlights The custom highlight API spec [1] currently states that an unstyled custom highlight should inherit the styles of its originating element. The Blink implementation follows this. However, this behavior can lead to some unintuitive results where unstyled highlights can affect the painting of the originating element, or paint over other highlights. This issue was pointed out in [2], and spec changes to fix this are pending editor review. A goal of these changes are that unstyled custom highlights do not affect rendering at all. This change updates the custom highlights implementation to achieve this by giving them a default 'transparent' foreground and background color. Some of our tests were validating the earlier unintuitive behavior involving overlapping ranges. These are updated, along with the addition of a new test to validate that a single unstyled highlight doesn't affect rendering. [1] https://drafts.csswg.org/css-highlight-api-1/#default-styles [2] w3c/csswg-drafts#6779 Bug: 1295271 Change-Id: Id7dc877c90c08240fbe79edeeeec551cdc5508c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449336 Reviewed-by: Delan Azabani <dazabani@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#969007} -- wpt-commits: 40d5e6da07fc061a6d81f081c3c16eafc10b54ce wpt-pr: 32759
|
#6665 makes the edits for these questions. |
mjfroman
pushed a commit
to mjfroman/moz-libwebrtc-third-party
that referenced
this issue
Oct 14, 2022
The custom highlight API spec [1] currently states that an unstyled custom highlight should inherit the styles of its originating element. The Blink implementation follows this. However, this behavior can lead to some unintuitive results where unstyled highlights can affect the painting of the originating element, or paint over other highlights. This issue was pointed out in [2], and spec changes to fix this are pending editor review. A goal of these changes are that unstyled custom highlights do not affect rendering at all. This change updates the custom highlights implementation to achieve this by giving them a default 'transparent' foreground and background color. Some of our tests were validating the earlier unintuitive behavior involving overlapping ranges. These are updated, along with the addition of a new test to validate that a single unstyled highlight doesn't affect rendering. [1] https://drafts.csswg.org/css-highlight-api-1/#default-styles [2] w3c/csswg-drafts#6779 Bug: 1295271 Change-Id: Id7dc877c90c08240fbe79edeeeec551cdc5508c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449336 Reviewed-by: Delan Azabani <dazabani@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#969007} NOKEYCHECK=True GitOrigin-RevId: 6ebd27596486309c18c3961b90bfb86cba62d3b8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem 1: UA default highlight colors(this problem turned out to effectively be the same as #6774)
If I understand conventional behaviour and #highlight-ua-styles correctly, the intended default behaviour of ::spelling-error and ::grammar-error is to decorate the highlighted text without changing the foreground color.Similarly, if I understand #6375 correctly, the intended default behaviour of an unstyled ::highlight is to yield no visible change in rendering, or at least not change the foreground color.But given the following statements…Highlight pseudo computed styles inherit all properties from the same highlight’s styles in the parent, eventually defaulting to initial values (#highlight-cascade). Used values can differ due to paired cascade ([css-pseudo] clarify paired-cascading behavior #6386).color:currentColor is the only way to grab the foreground color from lower layers, that is to say, “don’t change the color compared to if this text was unhighlighted” (#highlight-text).The initial value of color is a UA-defined ordinary color (css-color-3) or CanvasText (css-color-4), not currentColor.There are no recommended UA default highlight colors for ::spelling-error + ::grammar-error (#highlight-ua-styles), be they magic used colors via paired cascade or just declarations in the UA stylesheet, and UA default highlight colors are forbidden for ::highlight as of [css-highlight-api-1] Specify that custom highlights have no UA styles #6375 #6534 (#default-styles).…then by default, these three highlight pseudos will effectively reset the foreground color of highlighted text to initial (usually black), which is probably not what we want.Problem 2: custom highlight inheritance clause
As of #6534, #default-styles says:
I don’t think this really makes sense, because taken at face value, it essentially clobbers highlight inheritance (#highlight-cascade) in favour of the legacy behaviour (like how ::selection currently works in most impls).
Possible solutions
(see #6774 for solution to problem 1)
I think #highlight-ua-styles and #default-styles should explicitly recommend (or require) UA defaults for these three highlight pseudos that behave like color:currentColor. I believe the defaults should come from magic paired cascade, not UA stylesheet rules, to keep paired cascade as consistent and predictable as possible.No change is needed for the other highlight color (background-color), because its initial value is transparent.I think the spec text in Problem 2 should be removed.
The text was updated successfully, but these errors were encountered: