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/CACuR13cV62LK748tFBT_Wis%3DxTA57AhrnynwGLVj0MRMMALyVg%40mail.gmail.com.
