Unfortunately, delays elsewhere in our launch process have prevented us from getting developers to try this out so far.
Since the use counters show no usage at all, I would like to request that we adjust this experiment as though it had started in M158, and therefore running until M169 (inclusive). On Wed, Aug 19, 2026 at 7:21 PM Jeremy Roman <[email protected]> wrote: > On Wed, Aug 19, 2026 at 11:28 AM Chris Harrelson <[email protected]> > wrote: > >> >> >> On Wed, Aug 19, 2026 at 8:26 AM Alex Russell <[email protected]> >> wrote: >> >>> Hey Jeremy, >>> >>> We got more context from Rick at this morning's API OWNERS, and now that >>> I understand the situation better, LGTM1. >>> >> >> Note: only one LGTM is needed for an I2E, so this experiment is approved. >> >> >>> >>> On the TAG review, I agree that we can hold updating them until a date >>> when the feature is described more naturally in the Explainer. >>> >>> Until then, it would be helpful to have the Explainer address >>> considerations around page-level developer opt-in. My concern is that the >>> *next >>> *browser that implements something along these lines might not >>> implement image replacement in such an explicit developer opt-in way, >>> leading to user astonishment, potentially in high-stakes or regulated >>> settings. Under those conditions, it seems appropriate to me to have >>> developer controls for opting into (or out of) replacement at the page >>> level, and that's a consideration the Explainer should weigh. >>> >> > Thanks. I've added some text to the explainer. I think this is mostly > future work at this point (i.e., the smaller surface I want to experiment > with right now is useful independent of it) but it's worth making note of > it so it can be considered going forward, as implementations of this API > likely correspond to features that warrant due attention to this. > > Thanks for your patience, >>> >>> Alex >>> >>> On Monday, August 17, 2026 at 11:47:58 AM UTC-7 Alex Russell wrote: >>> >>>> Thanks for all the detailed background, Jeremy. >>>> >>>> The detailed back-and-forth here on the finer points of the design >>>> strikes me as the sort of thing a TAG design review should help to sort >>>> out. Can you please file one for this feature? I'm going to gate any >>>> positive vote here on a resolution there. >>>> >>>> Best, >>>> >>>> Alex >>>> >>>> On Thursday, August 13, 2026 at 11:14:33 AM UTC-7 Jeremy Roman wrote: >>>> >>>>> On Wed, Aug 12, 2026 at 8:43 PM Sangwhan Moon <[email protected]> >>>>> wrote: >>>>> >>>>>> Adding a couple of drive-by questions below, >>>>>> >>>>>> On Wed, Aug 12, 2026 at 5:14 PM Jeremy Roman <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Thanks for the feedback and advice; responses inline. >>>>>>> >>>>>>> On Wed, Aug 12, 2026 at 11:55 AM Alex Russell < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hey Jeremy, >>>>>>>> >>>>>>>> Thanks for filing this. Would be good to see this sent to the TAG, >>>>>>>> as I'm not sure it qualifies as trivial. >>>>>>>> >>>>>>> >>>>>>> This is thin enough that I'm not quite sure what feedback I would be >>>>>>> asking for TAG's time on. >>>>>>> >>>>>>> With respect to *form*, certainly we could imagine different >>>>>>> naming, or some enum or dictionary instead of a boolean, or something >>>>>>> like >>>>>>> that. It's quite a small API surface, though, and I don't think >>>>>>> anything is >>>>>>> very out of the ordinary. >>>>>>> >>>>>>> With respect to *function*, most of the interesting functionality >>>>>>> (what sorts of transformations the user might do, what capabilities the >>>>>>> user has to control it, how associated user data is stored and >>>>>>> processed, >>>>>>> etc) resides in vendor-specific features that are for the moment outside >>>>>>> the scope of standardization. Maybe in the future some of these >>>>>>> capabilities will be useful to expose to the platform and at that time >>>>>>> much >>>>>>> deeper standardization discussion would be beneficial. The only >>>>>>> functionality added to the platform here is that some web pages can tell >>>>>>> that some sort of browser feature was used in a way that might change >>>>>>> the >>>>>>> content the user sees. >>>>>>> >>>>>>> To me it seems that the size of the platform exposure in both >>>>>>> respects is rather modest, but if others would like this reviewed I'm >>>>>>> not >>>>>>> necessarily opposed. >>>>>>> >>>>>>> On the overall feature, Edge has some experience with features in >>>>>>>> this space, as we had some image and video "superresolution" features >>>>>>>> that >>>>>>>> we have since un-launched. A couple of thing we learned along the way: >>>>>>>> >>>>>>>> >>>>>>>> - It's *extremely* important for developers to have control. >>>>>>>> Consider radiology charts or other regulated enviornments. We >>>>>>>> cannot be >>>>>>>> messing with images in those settings, and so there have to be >>>>>>>> controls >>>>>>>> (and I'd argue, affirmative developer opt-in) to gate this sort of >>>>>>>> feature. >>>>>>>> The I2E implicitly fits this, but it isn't clear from the explainer >>>>>>>> that it >>>>>>>> will remain opt-in. >>>>>>>> >>>>>>>> For the first Chrome feature I'm looking at surfacing this way, >>>>>>> we'll probably avoid this particular concern, because it applies only to >>>>>>> certain kinds of images and we only perform the transformation when the >>>>>>> user explicitly uses the feature from browser UI. >>>>>>> >>>>>> >>>>>> 1. Extending Alex's developer control question: does this mean the >>>>>> proposal considers preventDefault() against the uareplacestart event a >>>>>> no-op? >>>>>> >>>>> >>>>> Yes. Maybe in the future certain browser features might be >>>>> preventable, but broadly speaking browser features acting on behalf of the >>>>> user tend to "win" in the hierarchy of constituencies. >>>>> >>>>> >>>>>> 2. Skimming the explainer, my understanding is that when blitting the >>>>>> "transformed" image to an HTMLCanvasElement or serializing it, the >>>>>> expectation is that it will be a reference to the original image, >>>>>> correct? >>>>>> >>>>> >>>>> I believe that would be the result in Chrome's implementation (which >>>>> uses UA shadow DOM to embed an iframe to a UA-controlled origin) and I >>>>> think vendors ought to do the same or something similar in most cases, but >>>>> all I'm aiming to expose/standardize at this point is how sites can >>>>> observe >>>>> the fact of replacement. But since we're talking about vendor-specific >>>>> features, I don't know what constraints might apply to future features >>>>> implemented by Chrome or other vendors. >>>>> >>>>> >>>>>> 3. If the expectation for (2) is to make the replaced image >>>>>> transparent, how do you see this working with getDisplayMedia()? (I ask >>>>>> because this might not be trivial) >>>>>> >>>>> >>>>> As far as I know, getDisplayMedia can be used to see pixels on the >>>>> screen that are cross-origin, cross-site, and even outside the browser. >>>>> For >>>>> that reason, I think it's reasonable that it can see the transformed >>>>> image. >>>>> >>>>> >>>>>> 4. Extension of developer control: Was a site-initiated >>>>>> HTMLImageElement.requestReplaceImage() path (e.g. gated by a user >>>>>> gesture) >>>>>> considered? >>>>>> >>>>> >>>>> Right now the particular feature I'm working on is viewed as a browser >>>>> feature rather than a web platform feature. Browser features, including >>>>> this one, are typically activated using vendor-specific UI. >>>>> >>>>> If in the future we want to allow sites to request that these features >>>>> be offered or even directly activate them, that would require a much >>>>> larger >>>>> discussion about the security/privacy properties of that, interoperability >>>>> of different implementations and offerings, etc. >>>>> >>>>> This API is very generic; it simply lets pages know when some such >>>>>>> feature has touched their images. It could conceivably be used for >>>>>>> features >>>>>>> which should have additional controls of the form you mention, but I'm >>>>>>> not >>>>>>> sure what can be done at this level to address that beyond advice that >>>>>>> browser vendors consider this potential issue with each such feature >>>>>>> they >>>>>>> implement. I'm fine to do that if it's helpful, though in many cases >>>>>>> it'll >>>>>>> refer to browser features which standards don't generally describe. >>>>>>> >>>>>>>> >>>>>>>> - Developers will need visibility in logging for impacts on >>>>>>>> latency and potential control over replacement UI. E.g. if this >>>>>>>> snaps in >>>>>>>> later than the original image, do we have good CSS controls for >>>>>>>> making sure >>>>>>>> the transition is seamless? (I know the answer to this question, >>>>>>>> which is >>>>>>>> "no", but it should be addressed in any Explainer). >>>>>>>> >>>>>>>> One application of this API is identifying when image replacement >>>>>>> features are (or have been) in use, so that developers can consider that >>>>>>> when looking at performance reports. Given the transformations and how >>>>>>> they >>>>>>> are presented is within the purview of the vendor-specific feature, I'm >>>>>>> not >>>>>>> sure how much there is to say here. Features that happen on page load >>>>>>> might >>>>>>> want controls analogous to CSS font-display (I assume this is what >>>>>>> you're >>>>>>> referring to), but this doesn't really apply to features that transform >>>>>>> images much later based on user action. >>>>>>> >>>>>>> I can explicitly state that this is out of scope (for now) if you >>>>>>> think it's helpful. >>>>>>> >>>>>>>> >>>>>>>> - Given that this is a feature that uses LLMs behind the >>>>>>>> scenes, has thought gone into interop? >>>>>>>> >>>>>>>> At this time I'm not pursuing interoperability on the particular >>>>>>> generated outputs (or indeed on the types of transformation at all), >>>>>>> though >>>>>>> that could happen in the future. >>>>>>> >>>>>>> Nonetheless it does seem useful to work toward interoperability in >>>>>>> the following sense: if website www.photographyblog.com wants to >>>>>>> remove a label that says "this photo was taken by a human on 01/02/2016" >>>>>>> when the image is substantively transformed in Chrome, then when another >>>>>>> browser adds a similar (or even cooler) transformation feature it >>>>>>> should be >>>>>>> able to benefit from this behavior in that site (and any other site). >>>>>>> >>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> On Tuesday, August 11, 2026 at 2:20:39 PM UTC-7 Chromestatus wrote: >>>>>>>> >>>>>>>>> *Contact emails* >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>>> *Explainer* >>>>>>>>> https://github.com/explainers-by-googlers/ua-image-replacement >>>>>>>>> >>>>>>>>> *Specification* >>>>>>>>> https://github.com/explainers-by-googlers/ua-image-replacement >>>>>>>>> >>>>>>>>> *Summary* >>>>>>>>> Modern browsers can provide capabilities to augment the browsing >>>>>>>>> experience by modifying media in the page on behalf of the user. The >>>>>>>>> advent >>>>>>>>> of generative AI makes it more likely that browsers will add such >>>>>>>>> features. >>>>>>>>> Sometimes, the replacement content added at the user request might not >>>>>>>>> match other content and functionality in the page, which could >>>>>>>>> confuse the >>>>>>>>> user. Even if this cannot be completely avoided, if authors can >>>>>>>>> observe >>>>>>>>> when replacement happens they can adjust the document to mitigate >>>>>>>>> confusion >>>>>>>>> (e.g., by hiding or adjusting other content). For example, a user >>>>>>>>> browsing >>>>>>>>> an e-commerce site with a generic product image (e.g., a model >>>>>>>>> wearing a >>>>>>>>> jacket) might wish to imagine themselves wearing the item. The user >>>>>>>>> agent >>>>>>>>> uses generative AI technology to produce that image and present it in >>>>>>>>> place >>>>>>>>> of the model image. The page improves the user experience by removing >>>>>>>>> text >>>>>>>>> referring to the model's dimensions and the garment size depicted, as >>>>>>>>> it >>>>>>>>> may not be correct in the replacement image. >>>>>>>>> >>>>>>>>> *Blink component* >>>>>>>>> Blink>Image >>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EImage%22> >>>>>>>>> >>>>>>>>> *Web Feature ID* >>>>>>>>> Missing feature >>>>>>>>> >>>>>>>>> *TAG review* >>>>>>>>> none as yet (API shape is trivial, API owner discretion needed on >>>>>>>>> whether this requires review) >>>>>>>>> >>>>>>>>> *TAG review status* >>>>>>>>> Pending >>>>>>>>> >>>>>>>>> *Goals for experimentation* >>>>>>>>> We're looking on hearing from sites which are affected by Chrome >>>>>>>>> features allow users to generate and emplace edited images in web >>>>>>>>> pages, >>>>>>>>> about whether this API allows them the information required to >>>>>>>>> optimize the >>>>>>>>> user experience as these features are used. If additional or >>>>>>>>> different API >>>>>>>>> is required to adapt appropriately, we'd like to know that sooner >>>>>>>>> rather >>>>>>>>> than later, especially if the changes required are not purely >>>>>>>>> additive. >>>>>>>>> >>>>>>>>> *Origin Trial documentation link* >>>>>>>>> https://github.com/explainers-by-googlers/ua-image-replacement >>>>>>>>> >>>>>>>>> *Risks* >>>>>>>>> >>>>>>>>> >>>>>>>>> *Interoperability and Compatibility* >>>>>>>>> *No information provided* >>>>>>>>> >>>>>>>>> *Gecko*: No signal >>>>>>>>> >>>>>>>>> *WebKit*: No signal >>>>>>>>> >>>>>>>>> *Web developers*: No signals >>>>>>>>> >>>>>>>>> *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? >>>>>>>>> *No information provided* >>>>>>>>> >>>>>>>>> >>>>>>>>> *Ongoing technical constraints* >>>>>>>>> None >>>>>>>>> >>>>>>>>> *Debuggability* >>>>>>>>> *No information provided* >>>>>>>>> >>>>>>>>> *Will this feature be supported on all six Blink platforms >>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>>>>> No >>>>>>>>> >>>>>>>>> *Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>>>>>> No >>>>>>>>> >>>>>>>>> >>>>>>>>> *Flag name on about://flags* >>>>>>>>> *No information provided* >>>>>>>>> >>>>>>>>> *Finch feature name* >>>>>>>>> *No information provided* >>>>>>>>> >>>>>>>>> *Non-finch justification* >>>>>>>>> *No information provided* >>>>>>>>> >>>>>>>>> *Requires code in //chrome?* >>>>>>>>> True >>>>>>>>> >>>>>>>>> *Tracking bug* >>>>>>>>> https://issues.chromium.org/issues/544822216 >>>>>>>>> >>>>>>>>> *Launch bug* >>>>>>>>> https://launch.corp.google.com/4452457 >>>>>>>>> >>>>>>>>> *Estimated milestones* >>>>>>>>> Origin trial desktop first 152 >>>>>>>>> Origin trial desktop last 157 >>>>>>>>> >>>>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/5076374013476864?gate=5435940823760896 >>>>>>>>> >>>>>>>>> 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/CACuR13eUhYfhQg1r6-13O77Ui2OiL2cszWZL_vDum-42GzR8rA%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13eUhYfhQg1r6-13O77Ui2OiL2cszWZL_vDum-42GzR8rA%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/f6e81fe8-cb3f-41b4-9021-f757652fd54an%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f6e81fe8-cb3f-41b4-9021-f757652fd54an%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/CACuR13dRmR_FW07M6Fw%3DGgvt7WE09HEDfO%2BJcZmU_uv-WXqt7g%40mail.gmail.com.
