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/CACuR13cy3TGA_V7SfuaDJqoB5b0uW_zSuXdF4dL%2BmzYNkusJyw%40mail.gmail.com.
