Skip to content
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

Closed
emilio opened this issue Mar 25, 2018 · 11 comments
Assignees
Labels
Closed Accepted by CSSWG Resolution Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-pseudo-4 Current Work Needs Testcase (WPT)

Comments

@emilio
Copy link
Collaborator

emilio commented Mar 25, 2018

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
Copy link
Collaborator

fantasai commented Mar 26, 2018

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.)

@tabatkins tabatkins added the css-pseudo-4 Current Work label Mar 26, 2018
@emilio
Copy link
Collaborator Author

emilio commented Apr 2, 2018

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
Copy link
Collaborator

frivoal commented Apr 2, 2018

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
Copy link
Member

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.

@frivoal frivoal self-assigned this Apr 11, 2018
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue May 10, 2018
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
emilio added a commit to emilio/servo that referenced this issue May 15, 2018
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
emilio added a commit to emilio/servo that referenced this issue May 15, 2018
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
emilio added a commit to emilio/servo that referenced this issue May 19, 2018
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
Copy link

dbates-wk commented Oct 25, 2018

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
Copy link
Collaborator Author

emilio commented Oct 30, 2018

@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.

fantasai added a commit that referenced this issue Dec 31, 2018
…echanism and make everything fit together into some kind of coherent model. #2474
@fantasai
Copy link
Collaborator

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
Copy link
Member

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
Copy link
Collaborator

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

@emilio
Copy link
Collaborator Author

emilio commented Jan 10, 2019

Yes, the edits look sensible, thanks!

@dbaron
Copy link
Member

dbaron commented Jan 16, 2019

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.

@fantasai fantasai added the Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. label Jan 22, 2019
lissyx pushed a commit to lissyx/mozilla-central that referenced this issue Jun 24, 2019
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
emilio pushed a commit to emilio/servo that referenced this issue Jun 24, 2019
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
emilio pushed a commit to emilio/servo that referenced this issue Jun 25, 2019
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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Oct 3, 2019
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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Oct 3, 2019
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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Oct 3, 2019
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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Oct 4, 2019
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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Oct 4, 2019
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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Oct 4, 2019
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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 16, 2021
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.htmlhttps://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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 16, 2021
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.htmlhttps://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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 16, 2021
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.htmlhttps://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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 16, 2021
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.htmlhttps://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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 16, 2021
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.htmlhttps://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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 16, 2021
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.htmlhttps://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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 20, 2021
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.htmlhttps://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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 20, 2021
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.htmlhttps://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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 20, 2021
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.htmlhttps://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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 22, 2021
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.htmlhttps://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}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 22, 2021
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.htmlhttps://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}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Oct 3, 2021
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.htmlhttps://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#30688web-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
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Oct 4, 2021
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.htmlhttps://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#30688web-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
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Oct 4, 2021
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.htmlhttps://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#30688web-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
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Oct 6, 2021
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.htmlhttps://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#30688web-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
Gabisampaio pushed a commit to Gabisampaio/wpt that referenced this issue Nov 18, 2021
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.htmlhttps://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#30688web-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}
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
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.htmlhttps://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#30688web-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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted by CSSWG Resolution Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-pseudo-4 Current Work Needs Testcase (WPT)
Projects
None yet
Development

No branches or pull requests

7 participants