Testing Rust XML parsing with SVG images at 1% before I2R of inline XSLT in SVG images?

[Dominik Röttsches]

Hi API Owners,

I would like to accelerate the collection of reliable metrics on real-world performance and compatibility of XML parsing through the Rust backend.

I am asking for your support to run an experiment that risks breaking a likely completely unused, or otherwise extremely niche feature for an experiment population of 1% of users.

Currently, without known breakage enabling Rust XML parsing is only possible for two scenarios: using the DOMParser JS API usage, and access to XMLHTTPRequest responseDocument.

In a Finch trial testing XML Rust parsing, in addition to those, we would also like to include Rust XML parsing for SVG standalone and SVG in external images. 

However, in principle we currently allow inline XSLT processing in those, which we can't support with the new Rust parser.

The metrics usage metrics of this of this extremely niche feature were only added recently in 176280de7eaf6 and first released in 146.0.7650.0.

Very early UseCounter data (internal link) indicates that usage of this functionality is absolutely 0. UMA timeline data already contains a few releases which have the metrics and on those the value is 0.

The metrics are clearly not yet in stable. Thus I have too little data to prove that this is really unused and to publish a full I2R. 

Would you support my intention to roll out Rust XML parsing for SVG standalone docs and externally referenced images at a 1% Finch trial to collect more meaningful performance and compat data, based on the assumption that usage stays 0 or extremely low? From my f2f discussion with resident SVG expert pdr@ yesterday, he is supportive of this approach. 

At the same time, I plan to track the metrics and publish the I2R, once I have sufficiently reliable info.The I2R is already prepared in https://chromestatus.com/feature/5143784390262784 - but is not not published on blink-dev yet while I wait for more reliable use counter data.

The alternative is to wait until the metrics reach stable, then publish the I2R, then waiting for that to reach stable and follow it with the more widely enabled XML Rust parsing, delaying wider exposure and testing of the Rust XML parser by several milestones.

Further details in internal doc.

Dominik

 

[Mike Taylor]

On 2/6/26 7:16 a.m., 'Dominik Röttsches' via blink-api-owners-discuss wrote:

Would you support my intention to roll out Rust XML parsing for SVG standalone docs and externally referenced images at a 1% Finch trial to collect more meaningful performance and compat data, based on the assumption that usage stays 0 or extremely low? From my f2f discussion with resident SVG expert pdr@ yesterday, he is supportive of this approach. 

I think the best path forward would be to send an Intent to Experiment (which is typically how we reason about and approve experiments like this), and include some more info on possible breakage scenarios (is it inline XSLT in SVG? It's not very clear to me from this email). That would help me (and other API owners) to better understand the risk - but in principle I'm supportive of stable experimentation.

thanks!

At the same time, I plan to track the metrics and publish the I2R, once I have sufficiently reliable info.The I2R is already prepared in https://chromestatus.com/feature/5143784390262784 - but is not not published on blink-dev yet while I wait for more reliable use counter data.

The alternative is to wait until the metrics reach stable, then publish the I2R, then waiting for that to reach stable and follow it with the more widely enabled XML Rust parsing, delaying wider exposure and testing of the Rust XML parser by several milestones.

Further details in internal doc.

Dominik

 

--
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/CAN6muBuqLMD00h6Aju%2B%2B9Yvc6XqYuvmkVoSEUx7yt8bBz%2Ber0g%40mail.gmail.com.

[Philip Jägenstedt]

I think the plan sounds good. https://www.chromium.org/blink/launching-features/#origin-trials says "Experimentation on 1% of Stable channel population requires an Intent to Experiment approval" so that sounds like the next step.

Would the use counter reach stable in the same milestone that you'd run the experiment in? If so I think risk can be further reduced by just letting the use counter collect data for 1-2 weeks to confirm ~0 usage in stable before turning the Finch experiment to 1%.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/e9e8f4e3-9bed-44a1-abb9-2411b33d7378%40chromium.org.

[Dominik Röttsches]

Hi Mike,

On Fri, Feb 6, 2026 at 6:39 PM Mike Taylor <mike...@chromium.org> wrote:

On 2/6/26 7:16 a.m., 'Dominik Röttsches' via blink-api-owners-discuss wrote:

Would you support my intention to roll out Rust XML parsing for SVG standalone docs and externally referenced images at a 1% Finch trial to collect more meaningful performance and compat data, based on the assumption that usage stays 0 or extremely low? From my f2f discussion with resident SVG expert pdr@ yesterday, he is supportive of this approach. 

I think the best path forward would be to send an Intent to Experiment (which is typically how we reason about and approve experiments like this), and include some more info on possible breakage scenarios (is it inline XSLT in SVG? It's not very clear to me from this email). That would help me (and other API owners) to better understand the risk - but in principle I'm supportive of stable experimentation.

Thanks, ok, I'll send the intent to experiment to blink-dev. Unfortunately, I don't find a way to use chromestatus for that (am I missing something?) as I don't think it shows and Origin Trial stage for feature deprecations (Deprecate XSLT in SVG) and for non-functional "PSA-style" changes (Rust XML Parser rollout). I'll write it manually.

Dominik

[Mike Taylor]

On 2/9/26 12:51 p.m., Dominik Röttsches wrote:

Hi Mike,

On Fri, Feb 6, 2026 at 6:39 PM Mike Taylor <mike...@chromium.org> wrote:

On 2/6/26 7:16 a.m., 'Dominik Röttsches' via blink-api-owners-discuss wrote:

Would you support my intention to roll out Rust XML parsing for SVG standalone docs and externally referenced images at a 1% Finch trial to collect more meaningful performance and compat data, based on the assumption that usage stays 0 or extremely low? From my f2f discussion with resident SVG expert pdr@ yesterday, he is supportive of this approach. 

I think the best path forward would be to send an Intent to Experiment (which is typically how we reason about and approve experiments like this), and include some more info on possible breakage scenarios (is it inline XSLT in SVG? It's not very clear to me from this email). That would help me (and other API owners) to better understand the risk - but in principle I'm supportive of stable experimentation.

Thanks, ok, I'll send the intent to experiment to blink-dev. Unfortunately, I don't find a way to use chromestatus for that (am I missing something?) as I don't think it shows and Origin Trial stage for feature deprecations (Deprecate XSLT in SVG) and for non-functional "PSA-style" changes (Rust XML Parser rollout). I'll write it manually.

(cc Jason to note the use-case gap)

Thanks!

[Dominik Röttsches]

This is now posted to blink-dev: Intent to Experiment: Ship Rust XML Parser to 1% stable for non XSLT scenarios 

[Dominik Röttsches]

On Sat, Feb 7, 2026 at 10:35 AM Philip Jägenstedt <foo...@chromium.org> wrote:

I think the plan sounds good. https://www.chromium.org/blink/launching-features/#origin-trials says "Experimentation on 1% of Stable channel population requires an Intent to Experiment approval" so that sounds like the next step.

Would the use counter reach stable in the same milestone that you'd run the experiment in? If so I think risk can be further reduced by just letting the use counter collect data for 1-2 weeks to confirm ~0 usage in stable before turning the Finch experiment to 1%.

Yes, M147, true, we can introduce a short delay between those two. 

Dominik