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 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/CAOMQ%2Bw-V-m%3D6c57NEvjGVVms_Mha7rvaJgeeTxga%3D0cUz8QcoA%40mail.gmail.com.
