LGTM1; thanks for following up on all of the dangling threads here. On Tuesday, August 26, 2025 at 2:06:26 AM UTC-7 [email protected] wrote:
> 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 > <https://www.w3.org/TR/SVG2/struct.html#SVGElement>, 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 > <https://logs.csswg.org/irc.w3.org/css/2025-08-21/#e1716969> > > With Regards > Divyansh > ------------------------------ > *From:* Mike Taylor <[email protected]> > *Sent:* Tuesday, August 26, 2025 14:17 > *To:* Divyansh Mangal <[email protected]>; Domenic Denicola < > [email protected]> > *Cc:* blink-dev <[email protected]>; Chris Harrelson < > [email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]> > > *Subject:* Re: [blink-dev] Re: [EXTERNAL] Re: Intent to Ship: Support > width and height as presentation attributes on nested <svg> elements > > Is the PR supposed to document the normative requirements of the WG > resolution? Right now it appears to be a non-normative note that links to > some IRC logs (which don't load for me, but that's probably my fault > somehow). > > > On 8/25/25 3:17 p.m., 'Divyansh Mangal' via blink-dev wrote: > > 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 <https://svgwg.org/svg2-draft/geometry.html#Sizing>. > 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 > <https://github.com/w3c/svgwg/pull/999> > > 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 [email protected] from July to September 2025: by date > <https://lists.w3.org/Archives/Public/public-svg-wg/2025JulSep/>) > > 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 <[email protected]> <[email protected]> > *Sent:* Friday, August 22, 2025 10:19 > *To:* Divyansh Mangal <[email protected]> <[email protected]> > *Cc:* blink-dev <[email protected]> <[email protected]>; > [email protected] <[email protected]> <[email protected]>; Chris > Harrelson <[email protected]> <[email protected]>; > [email protected] <[email protected]> <[email protected]>; > [email protected] <[email protected]> <[email protected]> > *Subject:* Re: [blink-dev] Re: [EXTERNAL] Re: Intent to Ship: Support > width and height as presentation attributes on nested <svg> elements > > Divyansh and I discussed this a bit more over Slack. In addition to what > they wrote, let me confirm: > > - 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. > > On Fri, Aug 22, 2025 at 1:23 AM 'Divyansh Mangal' via blink-dev < > [email protected]> wrote: > > Hi all, I have added more WPTs to increase the interop coverage as per the > discussion in the CSSWG issue > <https://github.com/w3c/csswg-drafts/issues/12376>. > These are the WPT PRs that got merged to achieve that: > WPTs for different CSS values of `width` and `height` for SVG elements by > goldenboy777 · Pull Request #53186 · web-platform-tests/wpt > <https://github.com/web-platform-tests/wpt/pull/53186> > Update viewport-units related test cases for nested `svg` element by > goldenboy777 · Pull Request #54128 · web-platform-tests/wpt > <https://github.com/web-platform-tests/wpt/pull/54128/files> > > Furthermore, we have gotten feedback from the CSSWG chairs on the CSSWG > issue <https://github.com/w3c/csswg-drafts/issues/12376>, they have also > given the resolution on content-based keywords like min-content, > max-content which WebKit > <https://github.com/WebKit/standards-positions/issues/509>earlier pointed > out as ambiguous. There was more feedback for the viewport units, and we > plan to follow them with the SVG WG group (once that gets reconstituted). > > Given that the main issue which Webkit pointed out earlier has been > resolved and we are achieving a good coverage of interop with the wpts. I > feel it is safe to move forwards with shipping this in chrome (and edge). > Let me know your thoughts here, or if you have any questions. > > with Regards > Divyansh > On Thursday, July 31, 2025 at 7:45:06 AM UTC+5:30 [email protected] > wrote: > > I was about to LGTM this, noting that you've done a great job with test > coverage, and we've given over a month for the CSSWG to come to a > conclusion but not seen much movement. > > But then I noticed that 16 hours ago, a Firefox engineer has chimed in on > the CSSWG thread > <https://github.com/w3c/csswg-drafts/issues/12376#issuecomment-3135649756>, > 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. > > On Tue, Jul 29, 2025 at 2:45 PM 'Divyansh Mangal' via blink-dev > <[email protected]> <[email protected]> wrote: > > Hello everyone, as per one of the API Owner's suggestions we have > introduced more WPTs to increase the coverage of different CSS values of > width and height properties. The PR > https://github.com/web-platform-tests/wpt/pull/53186 is also merged now. > Also, some amount of discussion is already started on the CSS issue > https://github.com/w3c/csswg-drafts/issues/12376 and only the conclusion > from the CSSWG is still pending. > I am requesting a re-review of this I2S to let us know if more work needs > to be done. > > with Regards > Divyansh > > On Wednesday, July 9, 2025 at 8:41:51 PM UTC+5:30 Chris Harrelson wrote: > > On Tue, Jun 24, 2025 at 1:21 AM Yoav Weiss (@Shopify) > <[email protected]> <[email protected]> wrote: > > Thanks for working on these!! > > +Vladimir Levin +Chris Harrelson - what would it take to add these to the > CSSWG agenda? (and maybe get eyes on the WPT review) > > > https://github.com/w3c/csswg-drafts/issues/12376 has the Agenda+ label, > so it'll get discussed soon. > > > > > On Tue, Jun 24, 2025 at 8:02 AM 'Divyansh Mangal' via blink-dev > <[email protected]> <[email protected]> wrote: > > Hi Dominic, we have incorporated few of the action items that you > suggested. Specially the priority ones: > > I have created a WPT PR to increase the coverage of different values of > width and height CSS properties > https://github.com/web-platform-tests/wpt/pull/53186. > > I have also started a CSS issue > https://github.com/w3c/csswg-drafts/issues/12376 > <https://github.com/w3c/csswg-drafts/issues/12376> > where we are clarifying and getting opinions on what should happen with > the undefined values in the SVG specification. > > > On Friday, June 13, 2025 at 10:18:41 PM UTC+5:30 Divyansh Mangal wrote: > > 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. > > > > *From:* Domenic Denicola <[email protected]> <[email protected]> > *Sent:* Friday, June 13, 2025 7:33 AM > *To:* blink-dev <[email protected]> <[email protected]> > *Cc:* Divyansh Mangal <[email protected]> <[email protected]> > *Subject:* [EXTERNAL] Re: Intent to Ship: Support width and height as > presentation attributes on nested <svg> elements > > > > This intent feels a little risky, because, as WebKit points out > <https://github.com/WebKit/standards-positions/issues/509> in their > standards-positions issue, there isn't really an adequate specification for > how SVG layout works in cases like this. For example, how it will behave > with non-px values. (The WPTs you link only include px values.) > > > > Since SVG2 is a mostly-unmaintained specification, and this feature has at > least some web developer demand, I don't want to require that you specify > everything perfectly here. But I'd like to see at least some of: > > - Discussion with other implementers in the standards positions > issues. (You've started these discussions, but I'd like to give them more > time to settle.) > - More exhaustive web platform test coverage, including values like > `min-content`, `calc-size()`, `20em`, `50%`, `auto`, `stretch`, `50vh`, > etc. > - Some discussion in the CSSWG about how they would like to see this > specified in the future. > - A pull request to update the relevant parts of the SVG2 spec with > some vague language about the expected results; it doesn't have to be > rigorous, but it should be at least enough for other implementers to > understand how to follow our behavior. > > 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. > > > > On Wednesday, June 11, 2025 at 10:28:17 PM UTC+9 [email protected] > wrote: > > *Contact emails* > > [email protected] > > *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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESVG%22> > > *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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>* > *?* > > 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 > <https://chromestatus.com/> > > -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eceef370-1e35-4aa8-87db-724bcfdb4b0dn%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eceef370-1e35-4aa8-87db-724bcfdb4b0dn%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- > 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 [email protected]. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2B1WsiL%3DDwGEuq73%3DE8M%3DCZGhVEtQENyBA7ZKWDWfKsVw%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2B1WsiL%3DDwGEuq73%3DE8M%3DCZGhVEtQENyBA7ZKWDWfKsVw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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 [email protected]. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e86ed6ec-9ffb-4c9e-b0df-f30099951353n%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e86ed6ec-9ffb-4c9e-b0df-f30099951353n%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/caa3d586-5e14-45b3-ac51-da67458e7073n%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/caa3d586-5e14-45b3-ac51-da67458e7073n%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/KUXP153MB1324826C6358931A35CBD167AD3EA%40KUXP153MB1324.APCP153.PROD.OUTLOOK.COM > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/KUXP153MB1324826C6358931A35CBD167AD3EA%40KUXP153MB1324.APCP153.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer> > . > > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d7f07d11-2740-4f1b-b075-dc765625d005n%40chromium.org.
