Reflecting on nested svg size breaking change

[Rick Byers]

Hey,

As part of a mini-postmortem for an emergency finch flag deployment I just want to flag that I think we (API owners) missed a chance to predict a breaking change on this intent thread. On the surface it's just shipping a new already-specified feature. But with the benefit of hindsight it seems like the sort of thing that we could have predicted developers might already have applied to their code (and sometimes applied incorrectly) and so something we should consider from a breaking-change risk perspective. Eg. ask for a github or HTTPArchive search or (if we could find any anecdotal evidence of breakage) possibly a UseCounter prior to approving. 

It was a pretty minor issue and we certainly don't want to over-compensate. I don't think it's possible to always predict these things. But, like with the more extreme window.Report issue, I think it's a good one for us as API owners to all be reflecting on as we reason about risk tradeoffs going forward.

Any disagreements or other reflections on learnings from this one?

Thanks!

   Rick

[Daniel Bratell]

Should "part" have been a link to something? Maybe the post-mortem, or is it secret?

But yes, it seems obvious in hindsight that there would be rules like

svg {width: 100px}

near SVGs with inner SVG elements. I think we got a bit distracted by some other issues, less important than web compatibility, and overlooked that big part. Personally I think I mentally disconnected it from CSS too because the intent used the SVG terminology "presentation attributes". 

The lesson I take away is that the risk section, and in particular the compatibility section, has to be considered carefully. I think we already know that, but a reminder is good.

(While I was not one of the LGTMs, I probably would have been hadn't there already been three of them)

/Daniel

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

[Rick Byers]

On Fri, Oct 31, 2025 at 5:14 AM Daniel Bratell <brat...@gmail.com> wrote:

Should "part" have been a link to something? Maybe the post-mortem, or is it secret?

Sorry, no secret. Meant to link https://crbug.com/450283949

But yes, it seems obvious in hindsight that there would be rules like

svg {width: 100px}

near SVGs with inner SVG elements. I think we got a bit distracted by some other issues, less important than web compatibility, and overlooked that big part. Personally I think I mentally disconnected it from CSS too because the intent used the SVG terminology "presentation attributes". 

The lesson I take away is that the risk section, and in particular the compatibility section, has to be considered carefully. I think we already know that, but a reminder is good.

Agreed, thanks! 

(While I was not one of the LGTMs, I probably would have been hadn't there already been three of them)

Yeah, me too I think...