-
Notifications
You must be signed in to change notification settings - Fork 669
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-pseudo] ::selection style propagation section doesn't reflect reality in any way. #2474
Comments
That depends: do we want (The current spec, btw, is an attempt to reflect these discussions.) |
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 Also, just tested Edge, and it seems to do the same thing WebKit and Blink do. |
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 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 |
The Working Group just discussed
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. 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
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
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:
will render equivalent to the page whose markup is:
? The first line has red text on a blue background and the second line has black text on a blue background. |
@dbates-wk I don't think it necessarily does. The resolution comes to say that selection for a |
…echanism and make everything fit together into some kind of coherent model. #2474
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. |
The CSS Working Group just discussed
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 |
@emilio I think we're closed out on this issue, but I wanted to check with you if the edits are acceptable. Lmk? |
Yes, the edits look sensible, thanks! |
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
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
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
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 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 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
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
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
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
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 <andruud@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Delan Azabani <dazabani@igalia.com> 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: • #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 <andruud@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Delan Azabani <dazabani@igalia.com> 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 <andruud@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Delan Azabani <dazabani@igalia.com> Cr-Commit-Position: refs/heads/main@{#923485} -- wpt-commits: 4eb26e6225ed30a6cfc73eb743eaf9f59086521c wpt-pr: 30813
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 <andruud@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Delan Azabani <dazabani@igalia.com> Cr-Commit-Position: refs/heads/main@{#923485} -- wpt-commits: 4eb26e6225ed30a6cfc73eb743eaf9f59086521c wpt-pr: 30813
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 <andruud@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Delan Azabani <dazabani@igalia.com> Cr-Commit-Position: refs/heads/main@{#923485} -- wpt-commits: 4eb26e6225ed30a6cfc73eb743eaf9f59086521c wpt-pr: 30813
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 <andruud@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Delan Azabani <dazabani@igalia.com> 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 <andruud@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Delan Azabani <dazabani@igalia.com> 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 <andruud@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Delan Azabani <dazabani@igalia.com> Cr-Commit-Position: refs/heads/main@{#923485} NOKEYCHECK=True GitOrigin-RevId: 92c8bb15f9bf75db2b114bd5a401610963c2ebad
https://drafts.csswg.org/css-pseudo/#highlight-pseudos currently says in https://drafts.csswg.org/css-pseudo/#highlight-cascade:
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?
The text was updated successfully, but these errors were encountered: