You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-pseudo] [css-highlight-api] defaults and inheritance for ::spelling-error + ::grammar-error + ::highlight #6779
(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.
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.
…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.
A custom highlight pseudo-element inherits the styles of its originating element.
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).
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.
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.
If the author does not specify a custom highlight pseudo-element's color, the text is painted using the color of the next highlight pseudo-element layer below, or if none exists, the colors that would otherwise have been used (those applied by the originating element or an intervening pseudo-element such as ::first-line or ::first-letter). If the author does not specify a custom highlight pseudo-element's background-color, the UA must paint the highlight pseudo-element's background using the value 'transparent'.
I had written the spec text with the legacy ::selection behavior in mind, so it doesn't fit with the new #highlight-cascade behavior.
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?
Activity
dandclark commentedon Nov 17, 2021
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:
fix problems with ::{spelling,grammar}-error + ::highlight (w3c#6779)
delan commentedon 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?
dandclark commentedon Nov 18, 2021
Ah, I'd missed that #6665 was also addressing this for custom highlights. It looks great to me!
astearns commentedon Dec 7, 2021
We probably don’t need agenda time for this if @frivoal and/or @fantasai could review the PR
Highlight API: Don't paint unstyled custom highlights
Highlight API: Don't paint unstyled custom highlights
Highlight API: Don't paint unstyled custom highlights
Highlight API: Don't paint unstyled custom highlights
Highlight API: Don't paint unstyled custom highlights
Bug 1754327 [wpt PR 32759] - Highlight API: Don't paint unstyled cust…
Highlight API: Don't paint unstyled custom highlights
Bug 1754327 [wpt PR 32759] - Highlight API: Don't paint unstyled cust…
Bug 1754327 [wpt PR 32759] - Highlight API: Don't paint unstyled cust…
Bug 1754327 [wpt PR 32759] - Highlight API: Don't paint unstyled cust…
[css-pseudo] clarify paired cascade (#6386 + #6779 + #6774 + #7837) (#…
delan commentedon Oct 6, 2022
#6665 makes the edits for these questions.
Bug 1754327 [wpt PR 32759] - Highlight API: Don't paint unstyled cust…
Bug 1754327 [wpt PR 32759] - Highlight API: Don't paint unstyled cust…