CSS highlight processing model #30813
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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}