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/ffd329dd-86d0-4a6c-a245-179e25fa7418n%40chromium.org.
