Hey Jeremy, We got more context from Rick at this morning's API OWNERS, and now that I understand the situation better, LGTM1.
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 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.
