Repository navigation
[css-pseudo] highlight pseudos and compat stroke/fill properties #7580
Description
https://drafts.csswg.org/css-pseudo-4/#highlight-styling
The following properties apply to the highlight pseudo-elements:
- […]
- stroke-color, fill-color, and stroke-width
‘-webkit-text-fill-color’, ‘-webkit-text-stroke-color’, ‘-webkit-text-stroke-width’, and ‘-webkit-text-stroke’ are unrelated to those SVG-only properties, but they work roughly the same way and are supported interoperably. WPT even has a test for ::selection with ‘-webkit-text-fill-color’. Should we make these properties applicable to highlights?
Activity
HighlightInheritance: compat stroke properties valid_for_highlight
HighlightInheritance: compat stroke properties valid_for_highlight
HighlightInheritance: compat stroke properties valid_for_highlight
HighlightInheritance: compat stroke properties valid_for_highlight
HighlightInheritance: compat stroke properties valid_for_highlight
HighlightInheritance: compat stroke properties valid_for_highlight
Bug 1803502 [wpt PR 37270] - HighlightInheritance: compat stroke prop…
HighlightInheritance: compat stroke properties valid_for_highlight
Bug 1803502 [wpt PR 37270] - HighlightInheritance: compat stroke prop…
css-meeting-bot commentedon Jul 19, 2023
The CSS Working Group just discussed
[css-pseudo] highlight pseudos and compat stroke/fill properties, and agreed to the following:RESOLVED: Do not support them until unprefixedThe full IRC log of that discussion
<emilio> schenney: Simple question: -webkit- prefixed stroke / fill properties are interoperable and supported across browsers, but not supported in highlights<emilio> ... question is should they?
<bramus> emilio: I think they are not synonymous with their unprefixed versions. some are not impl as aliases
<schenney> q+
<bramus> emilio: I think it is worth trying not to support them
<TabAtkins> agree
<Rossen_> ack fantasai
<emilio> fantasai: I think the intention was that they would eventually be synonymous
<emilio> ... we should look into whether we can make them aliases
<florian> q+
<emilio> ... up until we do that I'm fine with them not being supported
<emilio> ack schenney
<GameMaker> q+
<emilio> schenney: I'd support not supporting them but could in the future if appropriate
<emilio> ack florian
<Rossen_> ack florian
<fantasai> s/if appropriate/if unprefixing them becomes appropriate/
<emilio> florian: the compat spec isn't entirely clear between the interaction between these and the unprefixed versions
<emilio> ... we should be looking into doing this
<emilio> ... and if they end up being aliases then yeah they should work
<emilio> fantasai: makes sense, I guess that means TabAtkins and I are responsible for that
<emilio> ... if/when we can make them aliases then they'd start working
<emilio> ack GameMaker
<Rossen_> ack GameMaker
<emilio> GameMaker: I'm agreeing with fantasai, support them once unprefixed, not support them until then
<TabAtkins> (elika and I stopped working on fill-stroke because there was no one biting on implementation)
<TabAtkins> (we're happy to pick it up again)
<emilio> RESOLVED: Do not support them until unprefixed
<GameMaker> WebKit obviously has an implementation, and we were just looking at supporting these in highlights, so I would love if we can move forward with the unprefixed versions
fantasai commentedon Jul 19, 2023
This needs a clarifying note.
[css-pseudo-4] Prefixed properties don't apply to highlights. #7580
Bug 1803502 [wpt PR 37270] - HighlightInheritance: compat stroke prop…