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. 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.
