[css-pseudo] add highlight tests for custom properties and/or inheritedness #30692
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
Loirooriol
approved these changes
Sep 17, 2021
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}
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
…edness (web-platform-tests#30692) * [css-pseudo] add highlight inheritedness tests * fix link@rel=help and move link@rel=author below title
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.
This patch adds four reftests that assert how highlight pseudos interact with custom properties and/or the concept of “inherited properties”, reflecting recent consensus in w3c/csswg-drafts#6264 and w3c/csswg-drafts#6386 (question 7):