Intent to Ship: SVG2 CSS Cascading

[Rune Lillesveen]

Contact emails

fut...@chromium.org

Specification

https://www.w3.org/TR/SVG2/struct.html#UseElement

Summary

Align the Blink implementation with the SVG2 specification for matching CSS rules in <use> element trees.

Match selectors against the <use> instantiation elements instead of the originating element subtree. This means selectors will no longer match ancestor and sibling elements outside the cloned subtree. More importantly, state selectors like :hover will now start matching in <use> instances.

Blink component

Blink>SVG

Web Feature ID

Missing feature

Motivation

CSS selectors match against the wrong tree for <use> instantiations, which means selectors do not match correctly for structural relationships and user interaction state (see :hover issue that will be fixed shipping this feature: https://crbug.com/40663285)

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Firefox has shipped the SVG2 behavior for years. Bug for WebKit: https://bugs.webkit.org/show_bug.cgi?id=249080

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=265894#c190) Shipped in Firefox 56

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/571)

Web developers: Positive 44 votes on the crbug issue, and additional 5 votes on the :hover bug https://crbug.com/40663285

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/svg/linking/reftests/use-descendant-combinator-003.html

https://wpt.fyi/svg/struct/reftests/use-inheritance-001.svg

https://wpt.fyi/svg/struct/reftests/use-inheritance-nth-child-of.svg

https://wpt.fyi/svg/struct/reftests/use-inheritance-nth-last-child-of.svg

https://wpt.fyi/svg/styling/use-element-attr-selector-transition.tentative.html

https://wpt.fyi/svg/styling/use-element-id-selector-transition.tentative.html

Flag name on about://flags

#enable-experimental-web-platform-features

Finch feature name

Svg2Cascade

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://crbug.com/40550039

Estimated milestones

Shipping on desktop	144
Shipping on Android	144
Shipping on WebView	144

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5134266027606016?gate=6607474169872384

This intent message was generated by Chrome Platform Status.

--

Rune Lillesveen

[Philip Jägenstedt]

LGTM1

The WebKit standards position was only filed yesterday, but this seems straightforward and aligns with spec+Firefox, so I don't think we should wait on it. In the unlikely event there is feedback, please ping this thread.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeQQp_NW%3DnoTwk2jpcjGzMb6wFyqj4KGm%3DqpMVyAM767tg%40mail.gmail.com.

[Rick Byers]

This has some risk of being a breaking change, right? How would you characterize that risk? Firefox having this is obviously a good sign, but any other data or arguments on the risk? I imagine SVG use is fairly rare, and any selector mismatch would most likely be a minor formatting issue, right?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcTTt4PNoX7oxUT_bTN2QGhbELKgFK7M_ojnne1NZgTfQ%40mail.gmail.com.

[Rune Lillesveen]

On Sat, Nov 8, 2025 at 12:59 AM Rick Byers <rby...@chromium.org> wrote:

This has some risk of being a breaking change, right? How would you characterize that risk? Firefox having this is obviously a good sign, but any other data or arguments on the risk? I imagine SVG use is fairly rare, and any selector mismatch would most likely be a minor formatting issue, right?

An instantiated subtree will no longer be able to do selector matching against the surrounding elements from where it was instantiated from.

In the following case, the use instance of the rect would no longer be red:

<!DOCTYPE html>
<style>
  .original rect { fill: red; }
  rect { fill: green; }
</style>
<svg>
  <defs class="original">
    <rect id="r" x="0" y="0" width="100" height="100" />
  </defs>
  <use href="#r"></use>
</svg>

I think this is unlikely to break real sites.

In order to use-count this, we would have to run both ways of cascading (or at least selector matching) to detect such cases.

The main benefit from this change, I think, is that it fixes https://crbug.com/40663285 which is about :hover and other state selector matching which is currently broken in <use> instances.

--

Rune Lillesveen

[Rune Lillesveen]

On Fri, Nov 7, 2025 at 10:51 AM Philip Jägenstedt <foo...@chromium.org> wrote:

LGTM1

The WebKit standards position was only filed yesterday, but this seems straightforward and aligns with spec+Firefox, so I don't think we should wait on it. In the unlikely event there is feedback, please ping this thread.

Unlikely?: https://github.com/WebKit/standards-positions/issues/571#issuecomment-3514586032

--

Rune Lillesveen

[Mike Taylor]

On 11/10/25 7:22 p.m., Rune Lillesveen wrote:

On Sat, Nov 8, 2025 at 12:59 AM Rick Byers <rby...@chromium.org> wrote:

This has some risk of being a breaking change, right? How would you characterize that risk? Firefox having this is obviously a good sign, but any other data or arguments on the risk? I imagine SVG use is fairly rare, and any selector mismatch would most likely be a minor formatting issue, right?

That, or some display:none rule that didn't work before, starts working now, which could be a major or minor issue.

An instantiated subtree will no longer be able to do selector matching against the surrounding elements from where it was instantiated from.

In the following case, the use instance of the rect would no longer be red:

<!DOCTYPE html>
<style>
  .original rect { fill: red; }
  rect { fill: green; }
</style>
<svg>
  <defs class="original">
    <rect id="r" x="0" y="0" width="100" height="100" />
  </defs>
  <use href="#r"></use>
</svg>

I think this is unlikely to break real sites.

I spent some time poking through the Firefox bug and its various associated bugs. I think it's a pretty good sign that this landed 8 years ago and the reported regressions were due to implementation bugs that were quickly fixed. 

The absence of bugs in Bugzilla isn't a perfect compat signal, but it's at least promising.

In order to use-count this, we would have to run both ways of cascading (or at least selector matching) to detect such cases.

This sounds like a lot of complexity (but feel free to respond telling me it's trivial to implement). So, LGTM2 and hopefully I'm not wrong about the risk here.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeR81uK_Rof9VxTX97BtB_QnCxFZ2sjHQDDRoT%2BgrWwsOA%40mail.gmail.com.

[Daniel Bratell]

LGTM3 - Risk seems manageable even though it's unfortunately hard to measure. That it has worked for such a long time in Gecko without major push towards something else is a good sign. Good luck. We're all counting on you.

/Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2bb4f387-a3f5-4838-b23c-8e1817ad0499%40chromium.org.