Requested in ChromeStatus: https://chromestatus.com/feature/5076374013476864?gate=5167550450237440
Several commercial publishers are in code freeze for the holiday shopping season, but I'd still prefer to keep this contiguous. On Wed, Nov 4, 2026 at 11:45 AM Rick Byers <[email protected]> wrote: > Sorry for my delay on this Jeremy. Yes that makes sense to me - let's > reset the experiment to be starting in M158. We can follow up offline on > the easiest way to implement this tooling-wise (chromestatus is not > designed for it). > > Rick > > On Tue, Oct 27, 2026 at 11:23 AM Jeremy Roman <[email protected]> > wrote: > >> 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/CACuR13cDSNNv2MEgxQQOT7rEepoBgg_Rjd4UEp4O4GHBwo3g_w%40mail.gmail.com.
