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 highlight processing model #30813

Merged
merged 1 commit into from
Sep 22, 2021

Conversation

chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented 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.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}

Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The review process for this patch is being conducted in the Chromium project.

@delan
Copy link
Member

delan commented Sep 16, 2021

@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-2850068 branch 7 times, most recently from 9e8280f to c114ba6 Compare September 20, 2021 08:05
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}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants