Reflections from prompt API I2S

[Rick Byers]

Hey,

A few of us at Google have been reflecting on what lessons we can take away from the prompt API I2S. I won't detail everything here, but I took away two specific lessons that I feel apply to my role as an API owner. 

First there's broad agreement that it would have been helpful if API owners had pushed harder for concrete developer signals. I know Alex has made a point of requesting these signals for any API where Chromium is going first. I resolved to follow his lead and do this more myself, especially for potentially riskier / controversial APIs. What do others think? Is this something we should strive to do more consistently?

Secondly, while we're good at ensuring we have signals from other engines regarding cross-engine interoperability, it's rare that we need to explicitly think about chromium cross-embedder interoperability. In this case I definitely screwed up by not thinking to ask someone from Edge to chime in before giving my LGTM. I knew it was an area of concern, but also I thought I had heard there was alignment (and even incorrectly claimed so in the Mozilla Standards position debate). We have a question in the I2S template: "Does this feature require code in src/chrome" but what we really want to know is, "How hard would it be for multiple Chromium embedders to support this API compatibly". In the very rare cases where it seems potentially difficult, perhaps we should request explicit public signals from at least one other Chromium embedder?

Thanks,

   Rick

[Dan Clark]

Thanks Rick for starting this discussion!

I agree that we can do more to push for concrete developer signals. I'll resolve to do this more myself. "Concrete" seems like the operative word here. A concern about some of the early signals with the Prompt API was that it was hard to tell how much of the developer interest around the feature was along the lines of "this is neat tech" rather than "here's how this solves this specific problem I have in a way that aligns with the stated goals of the feature". Both are good data points to note but we should be really clear we have evidence of the latter type especially when this needs to be weighed against browser compatibility risk.

In addition to the "Requires code in //chrome" question in the I2S template, there's also the "Non-OSS dependencies" question which gets at the same thing ("Would it be difficult for multiple Chromium embedders to support this API compatibly"). I think it would be reasonable to build a step into the process to ask for embedder public signals if the answer to either is true. Maybe there'd be some discretion like for TAG review where if the answers to the questions are yes but the feature poses no real challenge for embedders, a public signal is not needed -- but the feature owners could be asked to at least explain why that's the case.

In cases where the embedder interop risk seems high, we should be asking feature owners for evidence that interoperability can be achieved. Open benchmark comparisons of existing downstream implementations could be one kind of evidence. Another could be testimony from developers who have experimented with the feature and verified that their use cases work across the existing embedder implementations. This assessment should include the full range of the capabilities that are asked to be shipped. For example with Prompt API, Edge doesn’t support image and audio input, making the use case and API shape for those difficult to evaluate for interop. In the future I hope we’d aim to approve only the interoperable set of functionality for shipping while keeping other capabilities in OT until there are multiple implementations that can be assessed.

-- Dan

[Daniel Bratell]

My own reflections here, from outside either of Google and Microsoft.

I did not specifically look for developer signals in this case just because I interpreted it as a "build it and they will come" feature. That might have been a flawed attitude kept over from the Intent to Experiment which had me quite curious. "Intent to Experiment" is the phase where "they should come" and if that does not happen, then that is a concern, and that is something I will take with me.

As for compatibility, purely speaking for myself, there is so much that changes so quickly that I think shipping something without 100% confidence might be necessary to even learn about what the next generation actually needs. It is not perfect, it is far from perfect, but it is by the web's tradition (also see LiveScript/JavaScript/ECMAScript...). In a way I was happy that Google was willing, and strong enough, to take the risk since it could cause some push-back.

To be clear, I would not want that to be seen as any kind of precedence and I consider this an exception rather than the rule. We are in a time where the whole world is uncertain, curious and scared about what LLMs can, and will, do. Barring some kind of overall ban, exploration seems to be the only real option.

The one concern I had, which I think I've voiced, is that it should be possible for other Chromium vendors to ship something. That "something" would have such a large quality difference that developers would consider it useless I did not really consider. That was an obvious mistake. I did try to informally check what Opera was planning but did not learn anything.

It seems Microsoft and Edge were the ones furthest along but I did not hear any worries from that direction, probably(?) because any worries were kept internally(?). 

I do wonder what the answer would have been if the question had been "can other vendors ship this as well, in a state that is good enough". I suspect that the answer would have downplayed the risk, because of ignorance rather than anything else, but it might have gotten people thinking.

/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/2d2bedc1-54bc-46a8-b2d7-ecd8d37d2990n%40chromium.org.

[Rick Byers]

Thanks guys, inline:

On Fri, Jun 12, 2026 at 4:24 AM Daniel Bratell <brat...@gmail.com> wrote:

My own reflections here, from outside either of Google and Microsoft.

I did not specifically look for developer signals in this case just because I interpreted it as a "build it and they will come" feature. That might have been a flawed attitude kept over from the Intent to Experiment which had me quite curious. "Intent to Experiment" is the phase where "they should come" and if that does not happen, then that is a concern, and that is something I will take with me.

As for compatibility, purely speaking for myself, there is so much that changes so quickly that I think shipping something without 100% confidence might be necessary to even learn about what the next generation actually needs. It is not perfect, it is far from perfect, but it is by the web's tradition (also see LiveScript/JavaScript/ECMAScript...). In a way I was happy that Google was willing, and strong enough, to take the risk since it could cause some push-back.

To be clear, I would not want that to be seen as any kind of precedence and I consider this an exception rather than the rule. We are in a time where the whole world is uncertain, curious and scared about what LLMs can, and will, do. Barring some kind of overall ban, exploration seems to be the only real option.

100% agreed, thank you! 

The one concern I had, which I think I've voiced, is that it should be possible for other Chromium vendors to ship something. That "something" would have such a large quality difference that developers would consider it useless I did not really consider. That was an obvious mistake. I did try to informally check what Opera was planning but did not learn anything.

It seems Microsoft and Edge were the ones furthest along but I did not hear any worries from that direction, probably(?) because any worries were kept internally(?). 

I do wonder what the answer would have been if the question had been "can other vendors ship this as well, in a state that is good enough". I suspect that the answer would have downplayed the risk, because of ignorance rather than anything else, but it might have gotten people thinking.

Yes that's always the tension we struggle with around interop risk. Just like we don't wait for WebKit or Gecko to PROVE interoperability of an API before shipping one in Chromium (thereby giving them veto power over the velocity of Chromium), I don't think we should hold such a high bar in these Chromium embedder interoperability cases either. But we do ask people to make a serious effort on demonstrating a solid conformance test suite, and in looking at results wherever another implementation does happen to already exist. I pushed on this a little prior to my LGTM in this case, but in retrospect I think I should have held a higher bar (a repeatable system in an open place, not just a one-off test). 

/Daniel

On 2026-06-12 02:43, 'Dan Clark' via blink-api-owners-discuss wrote:

Thanks Rick for starting this discussion!

I agree that we can do more to push for concrete developer signals. I'll resolve to do this more myself. "Concrete" seems like the operative word here. A concern about some of the early signals with the Prompt API was that it was hard to tell how much of the developer interest around the feature was along the lines of "this is neat tech" rather than "here's how this solves this specific problem I have in a way that aligns with the stated goals of the feature". Both are good data points to note but we should be really clear we have evidence of the latter type especially when this needs to be weighed against browser compatibility risk.

In addition to the "Requires code in //chrome" question in the I2S template, there's also the "Non-OSS dependencies" question which gets at the same thing ("Would it be difficult for multiple Chromium embedders to support this API compatibly"). I think it would be reasonable to build a step into the process to ask for embedder public signals if the answer to either is true. Maybe there'd be some discretion like for TAG review where if the answers to the questions are yes but the feature poses no real challenge for embedders, a public signal is not needed -- but the feature owners could be asked to at least explain why that's the case.

Right, good point. I like the idea of API owners asking for embedder signals for non-trivial cases when either is true. Is it worth perhaps reviewing a few recent ones where "has code in //chrome" is true and asking whether we think we would have gotten additional useful information from such signals? I don't have a good sense myself, but anecdotes like these make me suspect we would. 

In cases where the embedder interop risk seems high, we should be asking feature owners for evidence that interoperability can be achieved. Open benchmark comparisons of existing downstream implementations could be one kind of evidence. Another could be testimony from developers who have experimented with the feature and verified that their use cases work across the existing embedder implementations. This assessment should include the full range of the capabilities that are asked to be shipped. For example with Prompt API, Edge doesn’t support image and audio input, making the use case and API shape for those difficult to evaluate for interop. In the future I hope we’d aim to approve only the interoperable set of functionality for shipping while keeping other capabilities in OT until there are multiple implementations that can be assessed.

Personally I think asking for proof of actual interoperability is too high of a bar (as I said above).