Intent to Ship: Support width and height as presentation attributes on nested <svg> elements

Contact emails

dma...@microsoft.com

Explainer

None

Specification

https://svgwg.org/svg2-draft/geometry.html#Sizing

Summary

This feature supports applying width and height as presentation attributes on nested <svg> elements through both SVG markup and CSS. This dual approach provides even greater flexibility for developers, allowing them to manage and style SVG elements more efficiently within complex designs.

With this feature the below two html will now have the same output:

With CSS Properties for nested <svg> element:

<svg width="100px" height="100px">

  <svg style="width:50px;height:50px;">

    <circle cx="50px" cy="50px" r="40px" fill="green" />

  </svg>

</svg>

Without CSS Properties for nested <svg> element:

<svg width="100px" height="100px">

  <svg width="50px" height="50px">

    <circle cx="50px" cy="50px" r="40px" fill="green" />

  </svg>

</svg>

Blink component

Blink>SVG

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko : No signal ( https://github.com/mozilla/standards-positions/issues/1243 )
In Firefox, the width and height attributes cannot be applied on nested <svg> elements as styles

WebKit : Neutral  ( https://github.com/WebKit/standards-positions/issues/509 )
In Safari, the width and height attributes cannot be applied on nested <svg> elements as styles

Web developers : Positive 7 people have upvoted this in the chromium issue.

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?

None

Debuggability

Existing Devtools capabilities already support this feature.

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

WPTs in chromium:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/svg/styling/nested-svg-sizing.svg
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/svg/styling/nested-svg-sizing-with-use.svg

Flag name on about://flags

None

Finch feature name

WidthAndHeightAsPresentationAttributesOnNestedSvg

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/40409865

Estimated milestones

Shipping on desktop	139
Shipping on Android	139
Shipping on WebView	139
Shipping on iOS	139

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).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5178789386256384?gate=5132029741760512

This intent message was generated by  Chrome Platform Status

Not all of these are required, and if I had to pick a single one that was most important, it would be expanded web platform test coverage.

Hi Dominic, thanks for your suggestions in the I2S
As suggested, our current action involves writing WPTs to better understand the expected behavior of missing CSS values. This will enable us to present more informed and concrete results to the CSSWG and other platforms, fostering clearer discussions and more consistent implementations.

We will update the I2S once that step that done.

+Vladimir Levin +Chris Harrelson  - what would it take to add these to the CSSWG agenda? (and maybe get eyes on the WPT review)

There's been some recent discussion on the issue, so I would like to give other people an opportunity to weigh in before putting this on the agenda.

For posterity, there's also an issue at svgwg for this:  http://github.com/w3c/svgwg/issues/984 (mostly the same content as the csswg issue)

But then I noticed that 16 hours ago, a Firefox engineer has chimed in on the CSSWG thread , and sounds interested in collaborating toward interop on this issue.

I don't think we should hold up this intent much longer, but let's take advantage of this to try to get more signals from Firefox. I'll add my thoughts to that thread to try to help things along.

• What they implemented and are proposing to ship in this Intent is fully aligned with the CSSWG resolution
• There are full WPTs for what they implemented and are proposing to ship
• Additionally, the CSSWG resolution contained more change suggestions in this area ("defaulting of content based keywords as auto")
• This intent does not cover those additional changes, and does not change the behavior of those cases. (That is, there is no risk of going current_behavior -> behavior_after_I2S -> third_behavior_implementing_CSSWG_resolution.)
• There are WPTs for these cases, which Chromium is currently failing.
• In the future, Divyansh hopes to work on those additional changes as well.

So, I agree that this feature is basically ready to ship. However, it'd be ideal if we had clarity on how the CSSWG plans to move from a "Needs Edits" resolution to merged spec text somewhere. So, I'll refrain from giving the LGTM for a few more days to see if there's any progress on that front.

Hi Domenic, yes, all the points that you mentioned are correct and describe the current state of the I2S perfectly.

As for the plans of merging the CSS resolution in a spec, we have already started the communications with relevant people and on that front, we are expected to edit the resolution in the SVG2.0 specification - Geometry Properties — SVG 2 .
I have taken on the responsibility of making the edit myself and have raised a PR to achieve that: 
Adding resolution of content dependent units used in sizing properties for inner SVG elements by goldenboy777 · Pull Request #999 · w3c/svgwg

I would like to point that the SVG spec is currently not maintained very actively, in fact there are talks of even publishing the draft SVG2.0 or respec it, so I expect a delay in getting the above PR actually merged. I also lack certain permissions to add the reviewers currently.
(For more details, please follow the conversations in the public email list public...@w3.org from July to September 2025: by date )

Given the time invested in this I2S already and the above raised spec PR, I think it would be ok to move forward with this intent. Let me know your thoughts here, or if you have any questions.

With Regards
Divyansh

From:  Domenic Denicola < dom...@chromium.org >
Sent:  Friday, August 22, 2025 10:19
To:  Divyansh Mangal < dma...@microsoft.com >
Cc:  blink-dev < blin...@chromium.org >; dom...@chromium.org < dom...@chromium.org >; Chris Harrelson < chri...@chromium.org >; vmp...@chromium.org < vmp...@chromium.org >; yoav...@chromium.org < yoav...@chromium.org >
Subject:  Re: [blink-dev] Re: [EXTERNAL] Re: Intent to Ship: Support width and height as presentation attributes on nested <svg> elements

Hi Mike,
I followed the current pattern of adding resolutions/annotations in SVG2.0 draft.
For example, if you see the annotation in  Document Structure — SVG 2 , my PR change will look identical to that. I believe any newly made resolutions are mainly in non-normative note/form because SVG2.0 is still in draft mode. I wanted to maintain the current structure so I kept the resolution in this form.

As for the linked irc log, they take a little time to load but they should be viewable  irc.w3.org #css

With Regards
Divyansh

From:  Mike Taylor < mike...@chromium.org >
Sent:  Tuesday, August 26, 2025 14:17
To:  Divyansh Mangal < dma...@microsoft.com >; Domenic Denicola < dom...@chromium.org >
Cc:  blink-dev < blin...@chromium.org >; Chris Harrelson < chri...@chromium.org >; vmp...@chromium.org < vmp...@chromium.org >; yoav...@chromium.org < yoav...@chromium.org >