Repository navigation
[wg/immersive-web] Immersive Web WG 2026 Group Charter #564
Description
New charter proposal, reviewers please take note.
Charter Review
Expected end of charter refinement phase: 2026-09-07
If applicable:
What kind of charter is this? Check the relevant box / remove irrelevant branches.
- New
- New WG
- New IG
- Existing
- Existing WG recharter
- Existing IG recharter
Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, security, and TAG. Also add a "card" for this issue to the Strategy Funnel.
Substantive changes
Short description (or link to it) of the substantive changes in this charter. Use "None or N/A" otherwise.
- Adding new module (specification) but within current scope
- (Still under investigation) Plan to bring modules to REC, while Core API remains living model in CR
Communities suggested for outreach
Known or potential areas of concern
Where would charter proponents like to see issues raised? (this strategy funnel issue, a different github repo, email, ...)
Anything else we should think about as we review?
- No CRS updated during current charter period yet.
Note: proposed chairs should be copied @... on this issue.
/cc @AdaRoseCannon @Yonet (co-chairs)
Note: The Technical Strategy Team Lead or Project & Process Team Lead will assign the issue to a Charter Facilitator for new charters. For rechartering, the team contact is the Charter Facilitator by default, please assign the issue to them directly.
Activity
himorin commentedon Jul 27, 2026
initial draft development was at w3c/charter-drafts#831
remaining issues before starting refinement (carried over from above issue)
tidoust commentedon Jul 27, 2026
I think you can start the refinement period before these issues get addressed. Initiating charter refinement can certainly wait a few days, but I wouldn't lose more time to avoid making the rechartering process longer that it could.
himorin commentedon Jul 30, 2026
yep.
will open PR to add
<i class="todo"to non-finalized points, draft announcement of charter refinement, and start both charter refinement and horizontal reviews. /cc @AdaRoseCannon @Yonet[-][wg/iwwg] Immersive Web WG 2026 Group Charter[/-][+][wg/immersive-web] Immersive Web WG 2026 Group Charter[/+]himorin commentedon Aug 7, 2026
forgot to mark as HR requested after issuing draft announcement of charter refinement at this Mon.... sorry for delay.
simoneonofri commentedon Aug 7, 2026
For the Security review, I have one blocking comment on the charter. The candidate says that each specification should contain “sections” covering security and privacy implications, while the current charter template says “separate sections”. Could the charter be aligned with the current template? I would consider the blocker resolved once the wording is aligned.
Separately, because the charter covers a family of specifications which has security (and privacy) implications, could the Group evaluate whether to include a shared Security and Privacy document as a charter deliverable, similar to Web of Things (WoT) Security and Privacy Guidelines or create a section in the Threat Model for the Web?
himorin commentedon Aug 7, 2026
thank you for checking and finding this. it's totally my mistake not to be noticed this (possibly, haven't touch from old text...)
filed as w3c/charter-drafts#862
IWWG has one explainer covering (most of) entire WebXR space as https://immersive-web.github.io/webxr/privacy-security-explainer.html , and we may move this into one WG Note.
Added group issue as immersive-web/administrivia#249 , please comment there if you have any consideration (or to webxr repository for any missing points in explainer).
simoneonofri commentedon Aug 7, 2026
Thank you. PR #862 addresses the blocking comment; I’ll consider it resolved once the PR is merged.
No problem, I had a similar issue diffing old charter, draft charter, and new charter :)
The existing Privacy and Security explainer is the kind of cross-specification starting point I had in mind. Developing it into a WG Note seems like the better home for the Immersive Web-specific analysis.
ruoxiran commentedon Aug 12, 2026
no comment or request from APA.
plehegar commentedon Aug 13, 2026
Charter refinement
matatk commentedon Aug 14, 2026
Hi @himorin, APA has looked at this and we have a few clarifying questions. I am also involved in looking at this from a TAG perspective, though we have not come to a resolution yet. I'd be grateful for your thoughts on the following...
The 'real-world' geometry module was renamed to 'plane detection' (and there's also a separate 'mesh detection' module listed later on). However, the description for the 'plane detection' module says:
Is that still correct—are meshes still in scope?
Regarding moving to WebGPU for rendering: do you have a plan for how long this will take (the charter talks about Q42027 for the bindings to be complete—do you expect implementations to be complete then too?) and how long WebGL will remain required/supported?
The Mesh detection module (new) has a description that reads:
Does this overlap with Plane detection above?
Also, there is no expected completion date given for Mesh Detection.
CSS Spatial Layout isn't mentioned as a deliverable but in section 5.1 W3C Groups, it says IW WG will work on it. This seems like quite a big architectural development. I understand that there are other similar proposals currently being worked on - would you be able to give the rationale for the group choosing this one? Or is exploration of the use cases in general ongoing?
The proposed PCM haptics for gamepads proposal isn't mentioned as a deliverable but in section 5.1 W3C Groups, it says IW WG will work on it.
Also, with this one, it seems like a feature that would be widely useful outside of WebXR—is it the intention to make it so?
himorin commentedon Aug 17, 2026
Failed to fix that. I've opened a PR to update description including others, and also history table entry.
w3c/charter-drafts#865
Implementation is on-going in parallel to spec development, also WG is continue discussing with WebGPU WG. Layers part hope to be fixed shortly.
There is no plan to drop WebGL from WebXR Device API (Core).
Plane detection, which got enough incubated and ready to be developed under WG space recently, was ruled out as separate module from some sort of catchall feature group in tentative deliverables.
For Mesh Detection, as tentative deliverables, we will have secure idea of completion once well incubated in CG.
Immersive Web WG is co-woring with CSS WG on this part, but we assume specification will be solely developed under CSS WG after current incubation phase. IWWG may give insights or comment from XR perspective, but browser user experience is out of Scope of IWWG.
We have feature request of PCM haptics in general, and we have PCM haptics repository for gathering and developing use cases and requirements, rather than development of real specification.
Similar to 4., I suppose we shall wrote as
The Immersive Web Working Group will contribute to incubate and work on xxxx. Does this fixes concerns?matatk commentedon Aug 18, 2026
Thanks @himorin, your replies, and w3c/charter-drafts#865 do answer my questions.
I noticed one more thing, regarding how the modules are named. Here is a list of all of the proposed deliverables (collapsed for brevity)...
Complete list of deliverables
WebXR Device API
WebXR Gamepads Module - Level 1
WebXR Augmented Reality Module - Level 1
WebXR Hit Test Module
WebXR DOM Overlays Module
WebXR Lighting Estimation API Level 1
WebXR Hand Input Module - Level 1
WebXR Anchors Module
WebXR Layers API Level 1
WebXR Depth Sensing Module
Navigation
WebXR Plane Detection Module
WebXR Raw Camera Access Module
WebXR/WebGPU Binding Module - Level 1
Model Element
WebXR Anchors Module - Level 2
WebXR Body Tracking Module - Level 1
WebXR Mesh Detection Module
XR Capture Module
Image Detection
Marker Detection
Face Detection
Gaze Tracking
Geo-alignment
If we only consider the deliverables that are estimating, sensing, testing, detecting, inputting, or tracking things, we have:
WebXR Hit Test Module
WebXR Lighting Estimation API Level 1
WebXR Hand Input Module - Level 1
WebXR Depth Sensing Module
WebXR Plane Detection Module
WebXR Body Tracking Module - Level 1
WebXR Mesh Detection Module
Image Detection
Marker Detection
Face Detection
Gaze Tracking
There seem to be some inconsistencies with how these are named, for example...
Wouldn't 'tracking' and 'detection' be essentially the same thing?
The Marker Detection repo is named 'marker-tracking' which is inconsistent with the charter (I've not checked any other repository names).
It seems like 'sensing', 'detection', and 'tracking' are very similar (very much so with 'detection' and 'tracking') - wouldn't it cause developer confusion to have different names that mean the same thing?
The description in [wg/immersive-web] Aligned spec description to ones' abstract charter-drafts#865 points out that the Hand Input Module enables 'tracking' of hand poses—so might this too be more consistently named 'tracking'?
I could easily be wrong, but would like to know more about the rationale behind the use of 'detection' and 'tracking' in particular. Has the group looked at the names of all of the specs together, to see if any simplification could be done?
himorin commentedon Aug 19, 2026
@matatk actually, there is no solid or agreed naming convention for modules, some may name from underlay library, code name of proposer ('s organization), or conversation in meeting... Of course, like taken from underlay library, aligning technical terminology around XR industry space may be the most strong background, and we may or may not know why it is called as in industry.
personally, I feel we use tracking for where client software by itself may actively operate something, detection for where underlay hardware system or XR space building library will perform some operation using information, but no solid nor clear boundary officially placed.
Originally it was, and stalled over time, some short time ago CG work resumes with starting draft explainer but not yet matured. We will look how it will be named after draft work progresses.
I'm not an expert in XR space (regarding to write client applications in XR space), but within some communities I haven't heard anything before...
@AdaRoseCannon @Yonet have you heard anything related to this?
this was originally proposed and developed to enable input using hand, which was emerging at early phase of HMD, like hololens extensively used input and system operation using hand pose, so named as is. Now, it is limited to provide joint information rather than more extensive input, but considering API is used by this name over 6 years, it is not good idea to rename just for wording issue.
@Manishearth how do you feel?
I'm not sure we could change simplification over commonly used XR terminology or already used over long term, but really thank you for raising question here.
Manishearth commentedon Aug 19, 2026
I don't think this is accurate, or maybe I don't understand what you're trying to say. I don't understand the distinction you're drawing between hand pose and joint information. The API was always intended to be like this, and the space hasn't changed significantly.
I think "hand tracking" is a good name, and matches what e.g. OpenXR calls its API. I think being more consistent about "tracking" is good but this is a minor editorial change. The APIs don't actually use these terms, I think, so there's a limit for developer confusion.
himorin commentedon Sep 7, 2026
No comment or request from i18n
himorin commentedon Sep 14, 2026
@ylafon is there any update from TAG front, although charter refinement phase already ends? I believe you will make several comments which we need to update draft charter...
himorin commentedon Sep 25, 2026
updates
I can ask for this week, to see if they are any taker. But it is likely that no.@simoneonofri
@matatk
plehegar commentedon Oct 23, 2026
Proposed W3C Charter: Immersive Web Working Group (until 2026-11-20)