[css-pseudo] add highlight tests for paired cascade #30688
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
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.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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
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.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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
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.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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
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.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}
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
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.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}
|
There are no reviewers for this pull request. Please reach out on W3C's irc server (irc.w3.org, port 6665) on channel #testing (web client) to get help with this. Thank you! |
|
Closing for now, because adding tests in two places causes problems like #30905. |
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this pull request
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.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
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this pull request
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.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
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this pull request
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.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
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this pull request
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.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
Gabisampaio
pushed a commit
to Gabisampaio/wpt
that referenced
this pull request
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.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}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Note: these tests were merged in #30813!
This patch adds six reftests for the “paired cascade” rule at the end of #highlight-cascade:
The tests and their tentativeness represent the current state of discussion in w3c/csswg-drafts#6386. They are reftests because paired cascade happens in used-value space. We might also want tests asserting that paired cascade applies to non-UA origins like author or animation or transition, but I’ll look into that separately.
Other changes that the UA makes to authors highlight colors (this comment describes three) can still cause unwanted failures in this kind of test. For example, Chromium currently fails 002 because it inverts background-color based on similarity with the foreground color. It might be possible to find clever workarounds for some of these tests, but I don’t know how to solve this problem for all #highlight-styling tests in general, nor do I know how to make these tests impervious to arbitrary UA changes to used highlight colors (rather than specific known changes).