WebView and Web Embedding

[siusin]

Is there work being incubated (in a Community Group, Business Group, IG, WG, or outside of W3C) that you'd like to highlight for W3C team attention?
Yes. It's in the W3C WebView Community Group.

• What's the work?
  The WebView Community Group aims to identify, understand, and reduce the issues arising from the use of software components (typically referred as WebViews) that are used to render Web technology-based content outside of a Web browser (Native Apps, MiniApps, etc).

• Where is it being incubated?
  The W3C WebView Community Group

• What help does it need?
  Help facilitate discussions between the group and interested parties to identify requirements and key issues

• Where do you think it should go next?
  The group is working on a draft charter for a Web Embedding WG, also looking in to Security Considerations for WebViews

[siusin]

/cc @NiklasMerz and @espinr

[NiklasMerz]

Thank you @siusin for bringing this up. I would really appreciate input from the team and more members.

I've been solo-chairing the WebView CG for some time now and recently I started to gather ideas on how to move on. I've must admin I feel a little lost at the moment.

We've done some great work in the CG like the usage & challenges report, CanIWebView and some great collaboration with the WebDX CG on things like web-feaures, BCD, Baseline or webcompat.dev. But what's next?

Is security or more documentation and advocacy a good focus?
Is there a path towards WebView standards?
Can we broaden the audience and nail down a scope to get everyone in embedding together?

I think we really need some guidance and support from all parties involved.

[NiklasMerz]

Note there is also a new CG with goes into this direction Embedded Web Engines & Native Web Runtimes Community Group chaired by @daisy19gnu.

[NiklasMerz]

For additional context I think @dontcallmedom summarised it perfectly on the Igalia Chats podcast with @bkardell and @meyerweb.

Dominique Hazael-Massieux: There are a couple that I will actually have to miss because I'm flying back tonight, but maybe building on one of the topics you added to... I think it was four years ago that I helped launch the WebView community group, which is trying to look at what, if anything, W3C can do to help make web use a better experience for web developers and a lot of the questions you alluded to around is it part of the web? Is it used for first party content versus for the drive by web and so on? Many of these questions were considered in the community group, and I think we now have a better understanding of that ecosystem. Since then, we've also seen some really interesting overlap with the work happening around EPUB, which is often implementing using web use, the work happening around mini apps, which is the way many applications get deployed in China again based on a WebView ecosystem. We've seen some interesting overlap with what Google has been developing under the name of isolated web apps. So, a way of packaging applications with additional privileges by constraining how they can be accessed and deployed to avoid some of the security challenges again of the drive by web. Interesting overlap perhaps also with web extensions. We've just launched for the first time ever as a web extensions working group, which is looking at standardizing APIs for web extensions again so that developers don't have to recreate extensions across the various engines. But again, web extensions, they use web technologies with a very different security model with very different expectations. So, there is whole ecosystem of technologies that are looking at using web technologies, but outside of the default web security model, which we know I think understand much better than when we started developing it organically, but comes with a number of very interesting properties in terms of facilitating adoption deployment accountability and so on, but also creates fairly systematic constraints in terms of what new technologies can be brought to the web at what speed and as a result, may put the web or broad definition of the web at a disadvantage. So, one of the breakouts would be in this case very specifically around WebView for Servo, but it's run by the chair of the WebView Community Group, which I know has been having a number of conversations about what can W3C do at this point in time to facilitate and accelerate the conversation for greater convergence in that space. So, yeah, that's one of the topics that I'm-

[espinr]

Thank you @siusin , @NiklasMerz ,

It is the ideal moment for this. We have been researching and discussing this non-browser web and how to make the convergence to preserve the One Web. We had an interesting discussion at TPAC 2025, and later during Breakout Days 2026 and the AC 2026.

In these sessions I raised the concerns of the challenges we face in the MiniApps standardization. The main issue is security, and this WebView-related research (and potential standardization) could benefit the future of this and other hybrid app ecosystems. Understanding the gap between the embedded web and classic browser web could also be relevant to clarifying and documenting the heterogeneous functionalities of webviews across platforms. This is something that WebView CG has started and could be relevant in the evolution of the web.

To be efficient and avoid overlapping, I would consider alignment (+reorganization) with similar activities:

• WebViews CG - obvious :)
• MiniApps WG (/CC @imsenyu) and CG. If this succeeds, I would suggest moving our WG activities to this (or a similar group) and keeping the CG for incubation and maintenance of the white paper.
• High Perf. Web Apps CG: proposing more efficient WebViews so we can bring the requirements here.
• And the new Embedded Web Engines and Native Web CG (+ @daisy19gnu) whose objectives are similar.

[daisy19gnu]

Thanks @siusin for opening this, and @NiklasMerz and @espinr for the generous framing — glad to be part of this conversation.

I strongly agree with the convergence goal, and with avoiding overlap. "One Web" — including the large parts of it that now run outside the classic browser — is exactly why I started the Embedded Web Engines & Native Web Runtimes CG, and I'd like us to join forces.

To make that concrete, here is how I see our group fitting in — as a complementary piece rather than a duplicate:

• The WebView CG / Web Embedding direction naturally centers on the application layer — OS-provided WebViews, MiniApps, packaging, and especially security.
• Embedded Web Engines & Native Web Runtimes takes the vantage point of the developer embedding the engine itself: the engine layer, the web-platform gaps that surface when an engine runs outside a browser, and — an angle I care about a great deal — accessibility and internationalization / text layout, including the EPUB and digital-publishing world, which (as @dontcallmedom notes) is a large, real user of embedded web engines.

There is genuine overlap, and that is exactly where alignment pays off. I'd suggest we map the pieces together, in the open and in writing, so participants always know where a given topic lives and we divide the work rather than duplicate it. I'm happy to help draft a shared scope map / "who does what" note that we can iterate on across the groups. For this, a shared document plus issues would suit me well.

Looking forward to building this together.

— Minori Ikeda, Chair, Embedded Web Engines & Native Web Runtimes CG

[bkardell]

Speaking with my colleagues, we are not sure we understand the particular line of distinction being drawn here @daisy19gnu . We are, however, very interested and have been trying to help organize people to work together too.

[daisy19gnu]

@bkardell Fair question — let me sharpen it. The line isn't "who talks about WebViews" (we clearly overlap there), it's which failure mode you're debugging:

• WebView CG / Web Embedding: a platform-provided WebView breaks at the app-integration boundary — permissions, packaging, lifecycle, security, cross-webview consistency.
• Embedded Web Engines & Native Web Runtimes: you ship the engine itself outside a browser chrome, and the web platform assumes a browser context that isn't there — no tab, no omnibox, no standard permission UI. That's where real accessibility/i18n/text-layout gaps show up once you're rendering actual content (EPUB is my concrete example), and it's also where hardware-facing APIs like WebBluetooth/WebSerial/WebUSB live — territory OS WebViews typically lock down at the app layer for good reason, but a full engine embed has to reckon with directly.

So less "two committees, one topic," more "two altitudes of the same stack" — which is exactly why a shared scope map is worth doing, since from outside it can look like duplication. I know you and your colleagues have been working on organizing this space too — I'd rather co-draft that map with you than duplicate the effort.

— Minori

[bkardell]

@daisy19gnu I suppose this could be one way to break it down, but fwiw we have never viewed the WebView CG as having that distinction.

[siusin]

Based on the recent discussions, @NiklasMerz has proposed a number of updates to the WebView CG charter and has initiated a CfC：
https://lists.w3.org/Archives/Public/public-webview/2026Jul/0001.html
WebView-CG/charter#16

Many thanks to Niklas for driving this effort!

[NiklasMerz]

Thanks @siusin for the advice on updating the charter!

I fully agree with @bkardell that we don't necessarily need to make that distinction and we can cover these topics in WebView CG as well.
WebView CG has done a lot for web compat docs and there is a lot more we could do.

I still strongly believe we should create some forum for bringing WebViews, MiniApps and everything else around embedding together.

[daisy19gnu]

@bkardell @NiklasMerz — thank you both, and let me drop the abstract distinction.

You're right that it doesn't hold up from where you sit, and I should have seen it sooner: Igalia has been doing genuine engine-embedding work with WPE for years, so "engine layer vs. app layer" was never going to be a line that separated us. I withdraw it.

I'd like to be concrete about the work instead, because I don't think the real question is who owns WebViews.

Reading the WebView CG charter, two things stand out to me:

• Out of scope: "Normative specifications. Actual incubation of the explainers developed by the group is not in scope of this charter."
• The scope targets explainers "that would be implemented in a WebView," and the flagship deliverable is machine-readable data describing the differences between WebView and browser implementations.

That is a valuable and well-defined mission, and I don't want to blur it — the current CfC sharpening the group's focus toward security looks right to me for that mission. But the problems I'm bringing don't terminate there. They need to land in i18n, CSS, APA or the Publishing groups as actual platform work, and they are not differences between a WebView and a browser: they reproduce in both.

Concretely, here is what we find by embedding an engine to render long-form publications — Japanese vertical writing, ruby, EPUB Media Overlays (synchronized audio for accessibility), and assistive-technology integration through a native toolkit (GTK/AT-SPI) rather than browser chrome:

• Paginating vertical-rl content. CSS multicol lays columns along the inline axis, so in vertical-rl the columns stack along the block axis and pagination simply does not work. It requires a two-layer structure — an outer horizontal-tb paginator carrying column-width, wrapping an inner layer that carries the content's writing mode. Two implementations arrived at this independently and measured nearly identical results. None of it is discoverable from the specs.
• Scroll origin for vertical-rl scrollers. Whether the scroll origin sits at the right edge depends on which element is the scroller and on its computed writing-mode/direction. Getting it wrong silently reverses the reading direction for right-bound books — a correctness bug that produces no error and no visual artifact.
• EPUB Media Overlays under pagination. The specification defines active-class, but is silent on pagination: bringing the active element into view is undefined. Any implementation that does it is inventing behaviour, and there is no interoperability story.
• Accessibility when the engine is embedded. The accessibility tree has to reach the host toolkit's AT stack. The web platform assumes a browser context that provides one.

These are not hypotheticals. They are open, measured, and being worked on in public right now.

@NiklasMerz — on wanting a forum that brings WebViews, MiniApps and the rest of embedding together: yes, and I'd like to help. My reading is that what's needed between us is coordination, not consolidation. A shared "who works on what" map plus cross-posted issues would go a long way, and I'm glad to draft a first version for you all to tear apart.

I'd also point to the Exploration IG's SEED session at TPAC as a natural venue to test whether the publishing and accessibility side of embedded rendering has a home anywhere in W3C today. I intend to propose it there.

I'd rather divide the work than the territory. Happy to keep this in writing and in the open.

— Minori Ikeda, Chair, Embedded Web Engines & Native Web Runtimes CG

[NiklasMerz]

Thank @daisy19gnu for providing more details and context. This is really helpful. I see that you are working a couple of things that could become out of scope for WebView CG.

My reading is that what's needed between us is coordination, not consolidation. A shared "who works on what" map plus cross-posted issues would go a long way, and I'm glad to draft a first version for you all to tear apart.

That's a great way of describing it and it captures my/our intent very well. Coordination is the missing bit.

I'd also point to the Exploration IG's SEED session at TPAC as a natural venue to test whether the publishing and accessibility side of embedded rendering has a home anywhere in W3C today. I intend to propose it there.

SEED or breakout sessions at TPAC are definitely a good venue and I'm looking forward to that.

I don't want to rush or push things too much, but I'd like to move this towards to some action items because we have been talking about this for some time now (around last TPAC I suppose). TPAC 2026 is in October and I feel it's a good milestone to have something ready by then. If this thread is not the right place please let me know.

I can imagine a combination of activities like this could be actual steps. Please add your ideas:

1. Create a charter proposal and form a community group where this coordination can happen prior to TPAC
2. Run a breakout session to set a scope and mission and form a CG after TPAC
3. Run a joint meeting with MiniApps, WebView CG, Embedded Web Engines & Native Web Runtimes and more at TPAC
4. Coordinate outside TPAC

Is forming a new CG good idea for this coordination activity? I think we talked about community vs working group. Maybe interest group or something else entirely is a better fit?