Display of an inline 3D model

[zachernuk]

What problem are you trying to solve?

We want to display 3D assets directly in a web page in a privacy-preserving, spatial manner that allows for the integration of potentially sensitive input streams like the user's inter-pupillary distance, head movement, ambient lighting etc - without divulging that information to the Javascript context.

What solutions exist today?

WebGL and WebGPU allow for the real-time, in-line presentation of 3D objects - but exist as a 2D image on the page, and do not respond to the user's head position.

The WebXR API allows for immersive Augmented and Virtual Reality (AR/VR) display of content, but by deferring all rendering responsibility to WebGL, it requires the Javascript context to have awareness of all the necessary information.

For privacy and security reasons, it's also not possible to integrate WebXR content with traditional DOM content, meaning that WebXR-based spatial experiences must provide all other interaction and GUI elements themselves.

In both instances, the author-facing complexity of using a Javascript-based renderer that must be downloaded additionally - and represent significant overhead for a now-consistent and simple set of needs.

How would you solve it?

To create a new <model> element that allows the asset to be rendered outside of the Javascript context, and establish a reasonable initial API to meet basic use cases. We have been developing a proposal within the W3C Immersive Web Community Group to produce a model explainer, and an explanatory demo of the desired goal.

Anything else?

Establishing a new element for this approach to display is a high priority for platforms with spatial display capabilities such as a headset or other stereoscopic device, but provides significant benefits to web platform consistency on non-spatial devices as well. A consistent, browser-managed rendering strategy will result in smaller website transfers, greater consistency of display, accessibility and manipulation.

[cabanier]

Quest browser is also interested in adding this feature. Can I attend the meeting as well?

[virtualgeoff]

A new element to display a 3D model in a webpage?

Back in the '90s we used to do this with:

<embed src="model.wrl">

[zachernuk]

I recall! For those interested, we have a Model explainer with a "considered alternatives" section that includes <embed> and why we'd like to consider something else.

[marcoscaceres]

Moving this explicitly to the Stages model.

To meet Stage 1:

• A comprehensive explainer for the Contribution, in a standards organization-approved incubation venue such as a W3C CG or a branch of an existing WHATWG Standard.
• Consensus that the WHATWG is interested in exploring solutions in this problem space.
• (At least) one implementer interested in doing prototyping work: WebKit is prototyping, Meta and Samsung have expressed interest (potentially targeting Chromium).
• Identification of the Contributor: @zachernuk (Apple).
• Identification of a relevant WHATWG Workstream and Standard that will host the Contribution, and notification of the Workstream Editor(s).

@annevk, can you help us identify the right workstream? What's the appropriate mechanism for formally recording "consensus that the WHATWG is interested in exploring solutions in this problem space"?

[marcoscaceres]

If we have consensus, the Stages document for Stage 1 states that:

The WHATWG commits to hosting a specification draft in a repository or branch (if the Contributor requests it).

The Contributor would like to request the WHATWG host this proposal.

[domenic]

Your wish is granted! You can host it in a branch. Just please do not send a pull request before stage 3, when you have complete specification text.

[marcoscaceres]

I think we want it in a repository though, that way we can track our own issues. Given the complexity of this feature, we expect the final PR to be quite large and probably take about 1-2 years to complete Stage 3 before sending it over as pull request to the main spec.

[zcorpan]

I see two possibilities for hosting this work in the WHATWG and supporting separate issue tracking:

1. Incubate in a branch of whatwg/html and create a new repo only for issue tracking. I think PRs to merge to this branch would not be possible without notifying whatwg/html watchers.
2. Incubate in a new repo (fork of whatwg/html or blank) under whatwg.