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-4] system colors for ::search-text #10329
Major impls that use a fixed background color to highlight search results also use a fixed foreground color (demo). Firefox uses fixed background and foreground colors, but swaps them if that would improve contrast, which is allowed for UA styles per #6150. Safari uses fixed background and foreground colors for the current search result (black on yellow NSTextFinder bubble), but does not use color to highlight other search results.
As a result, one drawback of this approach is, in browsers like Safari that don’t use color to highlight search results, the new system colors won’t mimic the UA default colors for search results, because such UAs would need to define ‘Search’ and ‘SearchText’ as ‘transparent’ and ‘currentColor’ respectively, and I’m not sure that’s allowed. But I would argue against allowing that anyway, in favour of just accepting the inconsistency, for two reasons:
If authors mimic the UA default colors of ‘currentColor’ on a ‘transparent’ background in userland search results, without also being able to mimic the other parts of the UA default appearance (such as Safari’s page dimming), their search results would be invisible, which is counterproductive
One note on this: if a user has chosen the system colors (think of Windows High Contrast Mode / Contrast Themes), then the user may have intentionally chosen low contrast pairings (to reduce halation or being stuck working with a migraine).
As long as a user has an interface to select these colors (and Windows 11 Contrast Themes does not offer the granularity that prior versions did), then the must statement should be about honoring the user choice versus ensuring a minimum contrast.
Since Windows 11 lets users choose Highlight and HighlightText, those might be your defaults for now (until Windows 11 provides users a way to set any new color keywords you propose).
The CSS Working Group just discussed [css-pseudo-4] system colors for ::search-text.
The full IRC log of that discussion
<fantasai> schenney: system colors for spelling, highlights, etc.
<fantasai> schenney: but we need colors for find-in-page
<fantasai> fantasai: How would that work on systems that don't have such colors?
<fantasai> dbaron: My memory is that the implementation needs to make something up
<fantasai> dbaron: preferably something reasonable in the context of the other colors
<fantasai> schenney: I think Chrome has ...
<fantasai> schenney: I think it would be ok to substitute browser-chosen colors
<fantasai> schenney: Assuming you have ::search-text pseudo-styling, and the browser chooses to support this, the author would be able to refer to the default system color
<fantasai> fantasai: couldn't they just say `revert`?
<fantasai> schenney: That would solve the problem
<fantasai> florian: if only about reverting the color, then `revert` works. But if want to use the same color because related ot search functionality, then you need to know what color that is
<emilio> Yeah, I thought the point of these is something like github implementing their own find-in-page looking like the browser
<florian> fantasai: I am hesitant to introduce this because, if it's use for revert, we should just use revert. However, if it is meant to be used in some other part of the UI to remind of the search color, we need a good story in UAs that don't use a color to signify the search
<florian> fantasai: until we've explored those use cases explicitly, I don't think we should add that.
<khush> q+
<fantasai> schenney: I suggest table this for now, and add to the discussion in the issue to bring up use cases for having the system color
<fantasai> schenney: so we have more information before trying to resolve
<annevk> fserb, yeah, you can organize a meeting through whatwg/html (I mentioned this last time we had the larger 2d canvas meeting as well); that's also a good place to make these proposals as they will impact the <canvas> and 2D API
<astearns> ack khush
<fantasai> khush: Is there a platform that doesn't use highlight colors?
<fantasai> khush: what happens in that case?
<fantasai> schenney: A browser that doesn't use color highlighting, then it doesn't support ::search-text
<fantasai> khush: If a browser is not able to support it, would ignore the declaration
<fantasai> khush: would it make sense for such a browser to just say that it's not supported in @supports?
<emeyer> fantasai: I guess you could put the search color as an unsupported thing
<emeyer> fantasai: Will take this one back to the Safari team and see what they think
Activity
CSS Color: add internal colors for ::search-text defaults
aardrian commentedon May 18, 2024
One note on this: if a user has chosen the system colors (think of Windows High Contrast Mode / Contrast Themes), then the user may have intentionally chosen low contrast pairings (to reduce halation or being stuck working with a migraine).
As long as a user has an interface to select these colors (and Windows 11 Contrast Themes does not offer the granularity that prior versions did), then the must statement should be about honoring the user choice versus ensuring a minimum contrast.
Since Windows 11 lets users choose
HighlightandHighlightText, those might be your defaults for now (until Windows 11 provides users a way to set any new color keywords you propose).css-meeting-bot commentedon Jun 12, 2024
The CSS Working Group just discussed
[css-pseudo-4] system colors for ::search-text.The full IRC log of that discussion
<fantasai> schenney: system colors for spelling, highlights, etc.<fantasai> schenney: but we need colors for find-in-page
<fantasai> fantasai: How would that work on systems that don't have such colors?
<fantasai> dbaron: My memory is that the implementation needs to make something up
<fantasai> dbaron: preferably something reasonable in the context of the other colors
<fantasai> schenney: I think Chrome has ...
<fantasai> schenney: I think it would be ok to substitute browser-chosen colors
<fantasai> schenney: Assuming you have ::search-text pseudo-styling, and the browser chooses to support this, the author would be able to refer to the default system color
<fantasai> fantasai: couldn't they just say `revert`?
<fantasai> schenney: That would solve the problem
<fantasai> florian: if only about reverting the color, then `revert` works. But if want to use the same color because related ot search functionality, then you need to know what color that is
<emilio> Yeah, I thought the point of these is something like github implementing their own find-in-page looking like the browser
<florian> fantasai: I am hesitant to introduce this because, if it's use for revert, we should just use revert. However, if it is meant to be used in some other part of the UI to remind of the search color, we need a good story in UAs that don't use a color to signify the search
<florian> fantasai: until we've explored those use cases explicitly, I don't think we should add that.
<khush> q+
<fantasai> schenney: I suggest table this for now, and add to the discussion in the issue to bring up use cases for having the system color
<fantasai> schenney: so we have more information before trying to resolve
<annevk> fserb, yeah, you can organize a meeting through whatwg/html (I mentioned this last time we had the larger 2d canvas meeting as well); that's also a good place to make these proposals as they will impact the <canvas> and 2D API
<astearns> ack khush
<fantasai> khush: Is there a platform that doesn't use highlight colors?
<fantasai> khush: what happens in that case?
<fantasai> schenney: A browser that doesn't use color highlighting, then it doesn't support ::search-text
<fantasai> khush: If a browser is not able to support it, would ignore the declaration
<fantasai> khush: would it make sense for such a browser to just say that it's not supported in @supports?
<emeyer> fantasai: I guess you could put the search color as an unsupported thing
<emeyer> fantasai: Will take this one back to the Safari team and see what they think