[css-pseudo] ::selection style propagation section doesn't reflect reality in any way. #2474

emilio · 2018-03-25T15:27:32Z

https://drafts.csswg.org/css-pseudo/#highlight-pseudos currently says in https://drafts.csswg.org/css-pseudo/#highlight-cascade:

Each element draws its own portion of the highlight overlay, which receives the styles specified by the highlight pseudo-element styles for which that element or one of its ancestors is the originating element. When multiple styles conflict, the winning style is the one belonging to the innermost element after cascading.

Note that even the spec example doesn't work as described on current browsers (the highlight background is definitely not green throughout).

What happens at least in WebKit, Blink and Gecko (haven't tested IE / Edge) is that the closest element ancestor's selection style is matched, inheriting from the ancestor style, and nothing else.

This is nice because what the spec specifies is kind of slow, and changing impls right now may be tedious and prone to compat bugs.

Can we update the spec to reflect reality please?

fantasai · 2018-03-26T16:12:42Z

That depends: do we want p::selection (and p::spelling-error and p::grammar-error) to work as authors would expect, or do we want only unqualified ::selection selectors, which affect the whole document at once, to be usable? In current implementations, the introduction of even an unstyled <span> breaks any form of targeted selection styling. This violates the generally-applied invariant in CSS that an unstyled inline element has no effect on rendering.

(The current spec, btw, is an attempt to reflect these discussions.)

emilio · 2018-04-02T01:47:35Z

I'm intending to unprefix this in Gecko in https://bugzilla.mozilla.org/show_bug.cgi?id=509958.

I'm happy to wait and change to what the spec says if other vendors commit to changing their long-unprefixed implementation, but lacking that having it prefixed is harming Firefox with a slow stream of web-compatibility bugs from people remembering to use ::-moz-selection in some places but not others.

Also, just tested Edge, and it seems to do the same thing WebKit and Blink do.

frivoal · 2018-04-02T04:45:32Z

I cannot speak for the WG, but given that other vendors have shipped unprefixed, I would be in favor of Firefox unprefixing it as well.

Separately from that, I think that we should still look into doing what the spec says (or something close), rather than what legacy implementations do, because the legacy approach makes the pseudo useless for anything other than the unqualified ::selection selector.

This definitely does mean that implementations will have to change, but I am not too worried about web compat, given that we'd be making a previously unusable thing usable.

If the discussion with implentors in the WG confirms that we still want to make ::selection more broadly useful, I'll try to help out with tests.

css-meeting-bot · 2018-04-11T08:24:40Z

The Working Group just discussed :selection style propagation, and agreed to the following resolutions:

RESOLVED: ::selection is cleared for shipping unprefixed even though multiple impl do not follow the spec.
RESOLVED: Switch to using inheritance instead of cascade.

The full IRC log of that discussion

<dael> Topic: :selection style propagation
<dbaron> and so does CSS 2.1 https://www.w3.org/TR/CSS21/cascade.html#specificity
<dael> github: https://github.com//issues/2474
<dael> emilio: No one does what spec says. So I think we should change the spec or all impl.
<dael> rune_: This has been a topic for multiple F2F. I think we covered it in 2010.
<dael> rune_: dbaron has best overview.
<dael> dbaron: Selection was spec in selectors 3, but didn't say what it meant. A bunc hof browsers impl something, then we tried to look at what people wanted and expected and I made a list of requirements of what it should do. I think we picked one but no one adjusted.
<dael> rune_: I'm not sure we picked one.
<dael> dbaron: I don't know. Maybe we didn't. Way selection works in most browsers isn't useful.
<dael> florian: I think based on thebackground fantasai spec a thing that makes sense and is useful, but it's not what browsers do today.
<dael> dbaron: Other question is is the thing spec compat with what's on the web today.
<dael> florian: I think underlying is should we try and make it useful. If we establish that's the goal by applying to qualifying selectors we accept we're willing to go into that level of complexity. If we don't accept hte premise let's not bother. Current spec had the assumption that we wanted to bother. Is that true?
<dael> dbaron: The thing in the spec attempts to do useful thing sfor selections and styles. Also there we features we wanted to build on top of ::selection so we can do things like styling spell check region that are on top of this feature.
<dael> fantasai: We added grammar and spell check.
<dael> emilio: Annoying part of how it's spec is you need to start resolving status to the top.
<dael> fantasai: There's different ways of getting same result. THere was an alternative way to have selection inherit from itself in a sep tree.
<dael> emilio: You have to resolve the entire tree which is different then what browsers do. I could say that, but I care about browser compat.
<dael> emilio: Whoever changes the impl first needs to be aware they might break.
<dael> florian: I don't know. It will do it wrong if you try and use it outside :selection
<dael> tantek: I'd rather see data on actual use.
<dael> TabAtkins: Argument is any current usage that would be effected is almost certainly broken.
<dael> tantek: You'd be fine with blink changing ::selector
<dael> TabAtkins: I would be fine with our impl to change, it would be better for users. Only global selection is useful right now and that wouldn't change.
<dael> emilio: Seems like it would make select-all sort of slow. You need to style whole page again.
<tantek> s/::selector/::selection
<dael> TabAtkins: recascade
<dael> emilio: You pay the cost of selecting the whole page.
<dael> fantasai: Don't have to recascade
<dael> TabAtkins: Track a full cascade
<dael> fantasai: ::selection has 4 properties.
<dael> TabAtkins: True.
<dael> emilio: But then special casing that.
<dael> fantasai: Then you just...instead of using cascading you can use inheritence through selection tree.
<dael> rune_: That's what presto used to do.
<dael> emilio: Somewhat like blink and webkit do for visible
<dael> rune_: Works for limited number of property
<dael> fantasai: Has to be limited because non-layout effecting.
<dael> TabAtkins: Most are already inherited. Others can be shifted.
<fantasai> https://drafts.csswg.org/css-pseudo/#highlight-cascade
<dael> fantasai: And I think there's an open issue about describing it to use inheritence.
<dael> fantasai: WE can do it either cascde or inheritance but you get same behavior. Main difference is if you fail.
<dael> fantasai: Most of the time authors are not setting the inherit keyword. Behavior between cascading and inheritance is that the inherit keywod behaves differently
<dael> emilio: Synth prop that are usuallyr eset but are not inherited for purpose of selection...I don't know.
<dael> TabAtkins: Happy to desc like that.
<dael> emilio: Seems hard.
<dael> TabAtkins: Spec text should be fine.
<dael> tantek: first-line has similar issues
<dael> TabAtkins: NOt a great example
<dael> tantek: Older and has more tests
<dael> florian: Less constrained because compat. Can effect layout.
<dael> tantek: If you look at the ::selection and apply them to first-line you can come up with a reasonable list.
<dael> florian: That the set of properties for ::selection is more constrained means you can use more mech.
<dael> tantek: But from user/author it's not clear it should be different then first-line
<dael> fantasai: I think first-line is not related because it's trying to solve different constraints
<dael> TabAtkins: Pretend everything is inherited make sense?
<dael> emilio: Will people change?
<dael> TabAtkins: WE should try.
<tantek> ::selection is only trying to solve a subset of the constraints of ::first-line, which is why it is related and worth looking at
<dael> florian: Is it priority or disagreement? If browsers agree but don't prioritize there are people that have fixing browsers as a bug. If the browsers will accept that behavior that's different then we would not want to do this.
<dael> emilio: If there's no committment to impl.
<dael> florian: I'm saying that there might be and a patch might be written.
<dael> dbaron: Other option is put a note in a spec saying it hasn't been impl and we want feedback to see if it would work out and desc the other thing.
<dael> florian: Other thing being only global is useful?
<dael> dbaron: Yeah.
<dael> fantasai: It's easy to describe current impl. That's easy to desc in 2 sentences and add another for why it doesn't work well.
<dael> fantasai: I'm with TabAtkins we should try and make it more useful and if that's in terms of inhertence that's fine.I'm with TabAtkins that impl correctly is unlikely to break anybody.
<dael> fantasai: I would say if you impl in a way that makes it work no one will be made at Mozilla not doing it right. You have a problem that it's prefixed in your impl. You've got compat on the basic case that works so you should unprefix. Separately then make it useful.
<dael> tantek: Reasonable approach. We heard existing unprefix impl are willing to change so that adds weight to Moz can unprefix assuming we're willing to change.
<dael> fantasai: Prop: Mozilla should unprefix ::selection impl and the spec should describe how ::selection of a child gets its parent's styles via an incoherence based mechanism
<dael> florian: Our process prevents Mozilla from unprefixing and we need to allow.
<dbaron> s/incoherence/inheritance/
<dael> fantasai: WE generally rec you only ship if you're reasonably complient and people are not and we're saying it's okay.
<dael> fantasai: ::selection is cleared for sipping unprefixed even though multiple impl do not follow the spec.
<dael> Rossen: Obj?
<dael> RESOLVED: ::selection is cleared for shipping unprefixed even though multiple impl do not follow the spec.
<dael> fantasai: Currently ::selection of a child is desc with cascade. There are edge cases that will behave different with inherit.
<dael> fantasai: Prop: is switch to describing using the ihenretenace rather then the cascade.
<dael> Rossen: Current resolution is about cleared for shipping so we need the second resolution to change the spec.
<dael> Rossen: Obj?
<dael> RESOLVED: Switch to using inheritance instead of cascade.

Our implementation is totally not what the spec says, but totally what other UAs do, see w3c/csswg-drafts#2474. So given this is causing webcompat pain, I think we should be pragmatic and just unprefix this. We could keep serialization and getComputedStyle with ::selection working with a bit more effort, like we do for :-moz-placeholder, but I'd prefer not doing at least the serialization bit, and just alias in nsCSSPseudoElements :-moz-selection to selection too. MozReview-Commit-ID: 6lxctozRDqv

Our implementation is totally not what the spec says, but totally what other UAs do, see w3c/csswg-drafts#2474. So given this is causing webcompat pain, I think we should be pragmatic and just unprefix this. We could keep serialization and getComputedStyle with ::selection working with a bit more effort, like we do for :-moz-placeholder, but I'd prefer not doing at least the serialization bit, and just alias in nsCSSPseudoElements :-moz-selection to selection too. Bug: 509958 Reviewed-by: dbaron,xidorn MozReview-Commit-ID: 6lxctozRDqv

dbates-wk · 2018-10-25T18:57:10Z

I just want to clarify that "RESOLVED: Switch to using inheritance instead of cascade" means that ::selection will inherit from ::first-line (if there is one) such that selecting all of the following text in the page whose markup is:

<style>
#test {
    color: black;
}
#test::first-line {
    color: red;
}
#test::selection {
    background-color: blue;
}
</style>
<p id="test">First line of text.<br>Second line of text.</p>

will render equivalent to the page whose markup is:

<style>
#test {
    color: black;
    background-color: blue;
}
</style>
<p id="test"><span style="color: red">First line of text.</span><br>Second line of text.</p>

?

The first line has red text on a blue background and the second line has black text on a blue background.

emilio · 2018-10-30T01:30:25Z

@dbates-wk I don't think it necessarily does. The resolution comes to say that selection for a <span> should inherit from the ::selection pseudo of its parent. Maybe accounting for first-line is fine (but what should win, the ::selection pseudo of the block, or the ::first-line?), but that's not quite what the resolution says.

…echanism and make everything fit together into some kind of coherent model. #2474

fantasai · 2018-12-31T09:49:00Z

OK, I've drafted up the changes. Agenda+ to request review, but otherwise I'm closing this issue in favor of follow-up issues for anything that needs further fixing.

css-meeting-bot · 2019-01-10T00:53:57Z

The CSS Working Group just discussed Switching ::selection to use inheritance rather than cascade for parent-child value propagation, and agreed to the following:

RESOLVED: Accept the edits here: https://drafts.csswg.org/css-pseudo-4/#highlight-cascade

The full IRC log of that discussion

<dael> Topic: Switching ::selection to use inheritance rather than cascade for parent-child value propagation
<dael> github: https://github.com//issues/2474#issuecomment-380369965
<dael> fantasai: I made the edits we resolved on. Wanted to request review b/c it's a significant re-write.
<florian> I did review, and I like it.
<dael> fantasai: If anyone needs time that's fine. But it would be good to do an update WD at some point
<florian> would like to hear from would be implementors
<dael> astearns: Is this informative to have people come back? Or are you okay with Florian's review?
<dael> fantasai: Either is fine
<dael> astearns: Does anyone want more time to read the changes?
<dael> florian: I want impl to read because what's spec is different then what's impl. but what's impl isn't useful so we want them to switch. Based on a previous read of the previous text that was objected to. but reading it and assuming it's fine wouldn't be good
<dael> astearns: Writing tests is easiest way to get impl to pay attention
<dael> florian: That's somewhere on my to do list
<dael> astearns: Let's get a resolution to accept these changes. Follow up issues should be sep file
<dael> astearns: Obj to accepting the edits here https://drafts.csswg.org/css-pseudo-4/#highlight-cascade
<dael> fantasai: Unless emilio comes back and objects
<dael> astearns: Is he tagged in issue?
<dael> fantasai: I did not
<dael> florian: He opened it
<dael> astearns: Okay
<dael> RESOLVED: Accept the edits here: https://drafts.csswg.org/css-pseudo-4/#highlight-cascade

fantasai · 2019-01-10T17:49:52Z

@emilio I think we're closed out on this issue, but I wanted to check with you if the edits are acceptable. Lmk?

emilio · 2019-01-10T22:36:14Z

Yes, the edits look sensible, thanks!

dbaron · 2019-01-16T17:33:51Z

For what it's worth, the way things worked prior to this issue was I think the result of a discussion of which https://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html was an important part.

This patch invalidates the style for `::selection`, which will restore the behavior before the regression. However, it's still not quite correct, because repaint is not triggered. Given that `::selection` requires some major change to implement w3c/csswg-drafts#2474, we can address this problem later. Differential Revision: https://phabricator.services.mozilla.com/D35305

Our implementation is totally not what the spec says, but totally what other UAs do, see w3c/csswg-drafts#2474. So given this is causing webcompat pain, I think we should be pragmatic and just unprefix this. We could keep serialization and getComputedStyle with ::selection working with a bit more effort, like we do for :-moz-placeholder, but I'd prefer not doing at least the serialization bit, and just alias in nsCSSPseudoElements :-moz-selection to selection too. MozReview-Commit-ID: 6lxctozRDqv UltraBlame original commit: 70754a946fde161c04f86df1b67e3913c8ec590a

This patch invalidates the style for `::selection`, which will restore the behavior before the regression. However, it's still not quite correct, because repaint is not triggered. Given that `::selection` requires some major change to implement w3c/csswg-drafts#2474, we can address this problem later. Differential Revision: https://phabricator.services.mozilla.com/D35305 UltraBlame original commit: 52a73b4a9e9cb69d8653acf1f6104a02623df109

This patch implements the inheritance-based propagation for highlight pseudo-elements, as described in css-pseudo’s #highlight-cascade and introduced in w3c/csswg-drafts#2474. Highlight pseudos like ::selection were historically implemented such that only the ::selection selector (*::selection) worked intuitively. The spec’s processing model essentially makes it possible to define both general ::selection styles and more specific ::selection styles. We add a feature (HighlightInheritance) and a new computed style extra field of type scoped_refptr<StyleHighlightData>, which in turn points to four refcounted ComputedStyle instances, one for each highlight. Only a handful of properties are applicable, but reusing ComputedStyle like this simplifies the applying code, and allows us to share many of the field groups between instances anyway. We update the initial style singleton to point to a set of four empty highlight styles, which we only use when the feature is enabled. When the feature is disabled (or resolving custom ::highlight styles), there is no functional change. Highlight styles are lazily computed on paint’s demand, inherit only from the originating element styles, and we store the result in the Element’s pseudo cache (StyleCachedData). When the feature is enabled, we compute highlight styles during the originating element’s recalc (RecalcOwnStyle), skipping any highlight pseudos that the element had no matching rules for (a question that can already be answered thanks to pseudo bits). Style resolution is largely unchanged: we start with default styles, then use output of the cascade to change those styles. But defaulting is much easier for highlight styles: all properties are inherited, so we can simply clone the whole ComputedStyle. Relevant test page and screenshots: • https://bucket.daz.cat/work/igalia/0/8.html • https://bucket.daz.cat/4f37833aa15299a5.png (before) • https://bucket.daz.cat/67d2abdd9bcda17c.png (after) WPT already has some tests (css/css-pseudo/cascade-highlight-*), but more thorough test coverage will land in these patches: • #30688 • #30692 Bug: 1024156 Change-Id: I1f54f36ef2ac80165261a3f80d3a21cdf359c199 Cq-Do-Not-Cancel-Tryjobs: true

This patch implements the inheritance-based propagation for highlight pseudo-elements, as described in css-pseudo’s #highlight-cascade and introduced in w3c/csswg-drafts#2474. Highlight pseudos like ::selection were historically implemented such that only the ::selection selector (*::selection) worked intuitively. The spec’s processing model essentially makes it possible to define both general ::selection styles and more specific ::selection styles. We add a feature (HighlightInheritance) and a new computed style extra field of type scoped_refptr<StyleHighlightData>, which in turn points to four refcounted ComputedStyle instances, one for each highlight. Only a handful of properties are applicable, but reusing ComputedStyle like this simplifies the applying code, and allows us to share many of the field groups between instances anyway. We update the initial style singleton to point to a set of four empty highlight styles, which we only use when the feature is enabled. When the feature is disabled (or resolving custom ::highlight styles), there is no functional change. Highlight styles are lazily computed on paint’s demand, inherit only from the originating element styles, and we store the result in the Element’s pseudo cache (StyleCachedData). When the feature is enabled, we compute highlight styles during the originating element’s recalc (RecalcOwnStyle), skipping any highlight pseudos that the element had no matching rules for (a question that can already be answered thanks to pseudo bits). Style resolution is largely unchanged: we start with default styles, then use output of the cascade to change those styles. But defaulting is much easier for highlight styles: all properties are inherited, so we can simply clone the whole ComputedStyle. Relevant test page and screenshots: • https://bucket.daz.cat/work/igalia/0/8.html • https://bucket.daz.cat/4f37833aa15299a5.png (before) • https://bucket.daz.cat/67d2abdd9bcda17c.png (after) WPT already has some tests (css/css-pseudo/cascade-highlight-*), but more thorough test coverage will land in these patches: • #30688 • #30692 Bug: 1024156 Change-Id: I1f54f36ef2ac80165261a3f80d3a21cdf359c199 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2850068 Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Mason Freed <[email protected]> Commit-Queue: Delan Azabani <[email protected]> Cr-Commit-Position: refs/heads/main@{#923485}

Automatic update from web-platform-tests CSS highlight processing model This patch implements the inheritance-based propagation for highlight pseudo-elements, as described in css-pseudo’s #highlight-cascade and introduced in w3c/csswg-drafts#2474. Highlight pseudos like ::selection were historically implemented such that only the ::selection selector (*::selection) worked intuitively. The spec’s processing model essentially makes it possible to define both general ::selection styles and more specific ::selection styles. We add a feature (HighlightInheritance) and a new computed style extra field of type scoped_refptr<StyleHighlightData>, which in turn points to four refcounted ComputedStyle instances, one for each highlight. Only a handful of properties are applicable, but reusing ComputedStyle like this simplifies the applying code, and allows us to share many of the field groups between instances anyway. We update the initial style singleton to point to a set of four empty highlight styles, which we only use when the feature is enabled. When the feature is disabled (or resolving custom ::highlight styles), there is no functional change. Highlight styles are lazily computed on paint’s demand, inherit only from the originating element styles, and we store the result in the Element’s pseudo cache (StyleCachedData). When the feature is enabled, we compute highlight styles during the originating element’s recalc (RecalcOwnStyle), skipping any highlight pseudos that the element had no matching rules for (a question that can already be answered thanks to pseudo bits). Style resolution is largely unchanged: we start with default styles, then use output of the cascade to change those styles. But defaulting is much easier for highlight styles: all properties are inherited, so we can simply clone the whole ComputedStyle. Relevant test page and screenshots: • https://bucket.daz.cat/work/igalia/0/8.html • https://bucket.daz.cat/4f37833aa15299a5.png (before) • https://bucket.daz.cat/67d2abdd9bcda17c.png (after) WPT already has some tests (css/css-pseudo/cascade-highlight-*), but more thorough test coverage will land in these patches: • web-platform-tests/wpt#30688 • web-platform-tests/wpt#30692 Bug: 1024156 Change-Id: I1f54f36ef2ac80165261a3f80d3a21cdf359c199 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2850068 Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Mason Freed <[email protected]> Commit-Queue: Delan Azabani <[email protected]> Cr-Commit-Position: refs/heads/main@{#923485} -- wpt-commits: 4eb26e6225ed30a6cfc73eb743eaf9f59086521c wpt-pr: 30813

This patch implements the inheritance-based propagation for highlight pseudo-elements, as described in css-pseudo’s #highlight-cascade and introduced in w3c/csswg-drafts#2474. Highlight pseudos like ::selection were historically implemented such that only the ::selection selector (*::selection) worked intuitively. The spec’s processing model essentially makes it possible to define both general ::selection styles and more specific ::selection styles. We add a feature (HighlightInheritance) and a new computed style extra field of type scoped_refptr<StyleHighlightData>, which in turn points to four refcounted ComputedStyle instances, one for each highlight. Only a handful of properties are applicable, but reusing ComputedStyle like this simplifies the applying code, and allows us to share many of the field groups between instances anyway. We update the initial style singleton to point to a set of four empty highlight styles, which we only use when the feature is enabled. When the feature is disabled (or resolving custom ::highlight styles), there is no functional change. Highlight styles are lazily computed on paint’s demand, inherit only from the originating element styles, and we store the result in the Element’s pseudo cache (StyleCachedData). When the feature is enabled, we compute highlight styles during the originating element’s recalc (RecalcOwnStyle), skipping any highlight pseudos that the element had no matching rules for (a question that can already be answered thanks to pseudo bits). Style resolution is largely unchanged: we start with default styles, then use output of the cascade to change those styles. But defaulting is much easier for highlight styles: all properties are inherited, so we can simply clone the whole ComputedStyle. Relevant test page and screenshots: • https://bucket.daz.cat/work/igalia/0/8.html • https://bucket.daz.cat/4f37833aa15299a5.png (before) • https://bucket.daz.cat/67d2abdd9bcda17c.png (after) WPT already has some tests (css/css-pseudo/cascade-highlight-*), but more thorough test coverage will land in these patches: • web-platform-tests#30688 • web-platform-tests#30692 Bug: 1024156 Change-Id: I1f54f36ef2ac80165261a3f80d3a21cdf359c199 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2850068 Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Mason Freed <[email protected]> Commit-Queue: Delan Azabani <[email protected]> Cr-Commit-Position: refs/heads/main@{#923485}

This patch implements the inheritance-based propagation for highlight pseudo-elements, as described in css-pseudo’s #highlight-cascade and introduced in w3c/csswg-drafts#2474. Highlight pseudos like ::selection were historically implemented such that only the ::selection selector (*::selection) worked intuitively. The spec’s processing model essentially makes it possible to define both general ::selection styles and more specific ::selection styles. We add a feature (HighlightInheritance) and a new computed style extra field of type scoped_refptr<StyleHighlightData>, which in turn points to four refcounted ComputedStyle instances, one for each highlight. Only a handful of properties are applicable, but reusing ComputedStyle like this simplifies the applying code, and allows us to share many of the field groups between instances anyway. We update the initial style singleton to point to a set of four empty highlight styles, which we only use when the feature is enabled. When the feature is disabled (or resolving custom ::highlight styles), there is no functional change. Highlight styles are lazily computed on paint’s demand, inherit only from the originating element styles, and we store the result in the Element’s pseudo cache (StyleCachedData). When the feature is enabled, we compute highlight styles during the originating element’s recalc (RecalcOwnStyle), skipping any highlight pseudos that the element had no matching rules for (a question that can already be answered thanks to pseudo bits). Style resolution is largely unchanged: we start with default styles, then use output of the cascade to change those styles. But defaulting is much easier for highlight styles: all properties are inherited, so we can simply clone the whole ComputedStyle. Relevant test page and screenshots: • https://bucket.daz.cat/work/igalia/0/8.html • https://bucket.daz.cat/4f37833aa15299a5.png (before) • https://bucket.daz.cat/67d2abdd9bcda17c.png (after) WPT already has some tests (css/css-pseudo/cascade-highlight-*), but more thorough test coverage will land in these patches: • web-platform-tests/wpt#30688 • web-platform-tests/wpt#30692 Bug: 1024156 Change-Id: I1f54f36ef2ac80165261a3f80d3a21cdf359c199 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2850068 Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Mason Freed <[email protected]> Commit-Queue: Delan Azabani <[email protected]> Cr-Commit-Position: refs/heads/main@{#923485} NOKEYCHECK=True GitOrigin-RevId: 92c8bb15f9bf75db2b114bd5a401610963c2ebad

fantasai added the Agenda+ F2F label Mar 26, 2018

tabatkins added the css-pseudo-4 Current Work label Mar 26, 2018

css-meeting-bot removed the Agenda+ F2F label Apr 11, 2018

frivoal added the Needs Edits label Apr 11, 2018

frivoal self-assigned this Apr 11, 2018

fantasai added a commit that referenced this issue Dec 31, 2018

[css-pseudo-4] Rewrite ::selection et al. cascade using inheritance m…

e842010

…echanism and make everything fit together into some kind of coherent model. #2474

fantasai mentioned this issue Dec 31, 2018

[css-pseudo] Highlight pseudo-el cascade rules doesn't match reality #374

Closed

fantasai added Agenda+ Closed Accepted by CSSWG Resolution and removed Needs Edits labels Dec 31, 2018

css-meeting-bot removed the Agenda+ label Jan 10, 2019

frivoal added the Needs Testcase (WPT) label Jan 10, 2019

fantasai added the Commenter Response Pending label Jan 10, 2019

css-meeting-bot mentioned this issue Jan 16, 2019

[css-pseudo-4]: How should a selected spelling error be painted? #2850

Closed

fantasai added the Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. label Jan 22, 2019

Jul 1, 2021

CSS highlight pseudo system mozilla/standards-positions#548

Open

chromium-wpt-export-bot mentioned this issue Sep 16, 2021

CSS highlight processing model web-platform-tests/wpt#30813

Merged

Oct 28, 2021

[css-pseudo] defaulting ‘color’ in :root highlights #6774

Closed

schenney-chromium mentioned this issue Nov 3, 2023

CSS ::selection Inheritance Model w3ctag/design-reviews#914

Closed

bramus mentioned this issue Feb 13, 2024

Add CSS Highlight Inheritance mdn/browser-compat-data#22218

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-pseudo] ::selection style propagation section doesn't reflect reality in any way. #2474

[css-pseudo] ::selection style propagation section doesn't reflect reality in any way. #2474

emilio commented Mar 25, 2018

fantasai commented Mar 26, 2018 •

edited

Loading

emilio commented Apr 2, 2018

frivoal commented Apr 2, 2018

css-meeting-bot commented Apr 11, 2018

dbates-wk commented Oct 25, 2018 •

edited

Loading

emilio commented Oct 30, 2018

fantasai commented Dec 31, 2018

css-meeting-bot commented Jan 10, 2019

fantasai commented Jan 10, 2019

emilio commented Jan 10, 2019

dbaron commented Jan 16, 2019

[css-pseudo] ::selection style propagation section doesn't reflect reality in any way. #2474

[css-pseudo] ::selection style propagation section doesn't reflect reality in any way. #2474

Comments

emilio commented Mar 25, 2018

fantasai commented Mar 26, 2018 • edited Loading

emilio commented Apr 2, 2018

frivoal commented Apr 2, 2018

css-meeting-bot commented Apr 11, 2018

dbates-wk commented Oct 25, 2018 • edited Loading

emilio commented Oct 30, 2018

fantasai commented Dec 31, 2018

css-meeting-bot commented Jan 10, 2019

fantasai commented Jan 10, 2019

emilio commented Jan 10, 2019

dbaron commented Jan 16, 2019

fantasai commented Mar 26, 2018 •

edited

Loading

dbates-wk commented Oct 25, 2018 •

edited

Loading