# WebXDC dynamic preview & click listeners (inline apps) **URL:** \ **Category:** Feature Proposal\ **Tags:** webxdc, webxdc-api-future, user-interface\ **Created:** [August 13, 2026, 9:12pm UTC](https://support.delta.chat/t/webxdc-dynamic-preview-click-listeners-inline-apps/5647 "2026-08-13T21:12:52Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![ian](https://support.delta.chat/user_avatar/support.delta.chat/ian/32/3164_2.png) [@ian](https://support.delta.chat/u/ian)\ **Post date:** [August 14, 2026, 9:45am UTC](https://support.delta.chat/t/webxdc-dynamic-preview-click-listeners-inline-apps/5647/3 "2026-08-14T09:45:24Z")
I can offer the same response I’ve already given at the other topic which would have none of the drawbacks mentioned: > [@Feature suggestion - view apps inline](https://support.delta.chat/t/feature-suggestion-view-apps-inline/4468/11): > > A use case for allowing to show webxdc of static HTML + CSS in the chat with JS disabled is to provide an alternative for space-efficient and accessible stickers, animations and lightweight interactive CSS-only galleries and combinatoric logic. You can already achieve this with SVG+SMIL, but competence for creating such from scratch is high and it can’t be usually reused elsewhere. Whereas, existing png & jpg thumbnails of a game or the current snippet from the doc or calendar app could be repr… I.e., the webxdc app could render a static preview not into a raster image from a canvas, but instead into just a plain HTML DOM, possibly containing CSS and ideally up to a small amount of optional (SVG) images. If the app is implemented correctly (i.e., with [progressive enhancement](https://en.wikipedia.org/wiki/Progressive_enhancement)), possibly almost no additional code needs to be written for this use case. Such a static preview could then be cached in the local database, possibly as a single self-contained HTML file under the blob directory. It could be rendered into a sandboxed (iframe) widget that has JavaScript disabled, hence it would be more lightweight to process than if the fill-500 hack was required every time it scrolled into view. The simplest alternative to dehydrate such a component would be to require an additional button press to first activate the app (and make it unblurred, restore its colors, hide the play button, etc.) and then allow normal interactions. A more seamless way would be to overlay a `
` on top to catch clicks, activate it upon clicking and forward the click coordinate through the already mentioned API that the app could dispatch to itself again after loading (i.e., so that normal DOM bubbling mechanisms would take care of finding what what clicked on). Indeed this is less accessible as a user can’t tab to individual buttons in the app, but at least they could inform themselves about it with a screen reader (possible present a dedicated activation button for such users as a substitute?). _I would like to note here that I don’t think that we have any accessible Delta Chat clients so far._ And the possibly best solution would be if the static preview HTML was marked up in an elaborate way so that the Delta Chat sandbox could determine which elements can be interacted with (such as by depressing, clicking, swiping and typing text). The sandbox could remove any possible webxdc JavaScript from the static preview and add its own event handlers to such elements. These event handlers would call back to the sandbox via new `postMessage()` API to signal which element was interacted with (such as by ID attribute) and in what way. The sandbox would remember this, replace the static preview with the real app, start it, and then invoke a new API on the app to tell it about the interaction that activated it so it could replay it internally. The latter might also be done through the URI anchor in certain cases. However, if we wanted to support interactions other than through a simple click, it would not suffice to take the shortcut of marking up clickable regions with such href links for the former cases or by walking tabindex - we would really need to define `data-delta-chat-interaction=click|swipe|keypress` attributes for such a purpose. For some advanced use cases, it could also make sense to allow moving radio buttons, toggling checkboxes and typing into input and textbox while only activating the app itself upon a click (such as on a `vote` submission button), but also submitting the data already entered on the form above upon loading (i.e., so it could process the given vote). It’s an open question how to deal with updates. The threat model (and existing susceptibilities) of Delta Chat would allow sending such static HTML state previews to your peers for them to render on their timeline. This means that the poll state or chess game on your timeline could always appear up to date. If Delta Chat took a turn for more robust protections in general, it could make sense if only the local user could generate a preview for themselves. If a new state update came in, either a clickable banner warning about a possibly outdated preview could be displayed under the preview. As an alternative, if the user has already opened this webxdc in the group previously, Delta Chat could activate the webxdc in the background so that it could process the updates, generate a new static preview and terminate. This would need an additional API and also a newmetadata field on the webxdc to signal that such batch static preview updating is supported. --- _[View the full topic](https://support.delta.chat/t/webxdc-dynamic-preview-click-listeners-inline-apps/5647)._