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/CAFUtAY8igYzQNt%3D%2B0vSa0G5chA3Jf%2BEh51e3CWjidLFF1KV-uw%40mail.gmail.com.
