W3C

– DRAFT –
Immersive Web Groups Face-to-Face Day 2

19 March 2025

Attendees

Present
ada, atsushi, Brandel, Laszlo_Gombos, lucas0, m-alkalbani, mkeblx, yonet
Regrets
-
Chair
Ada
Scribe
ada, alcooper, cabanier, m-alkalbani

Meeting minutes

arrive, administravia

<atsushi> ada: see no new colleage, start without round introduction

Model: Add example showing enabling interactivity (immersive-web/model-element #20)

Brandel: [sharing the latest updates and examples on the explainer]
… stage mode = orbit is similar to QuickLook where you can manipulate the object (rotate it up and down, left to right etc)
… this issues is about adding examples to the specification and explainer
… wondering if we should have a repo (or public site) for examples
… prefer putting examples in a separate repo / site and not just limited to explainer and spec
… thoughts on putting examples online?

yonet: would the webxr samples page work?

ada: we could make a separate model element page to the webxr samples

<trevorPicoXR> Ruoya just arrived alcooper would you or brandon be able to let her in?

bajones: a separate repo would be a better option, mainly to not overcrowd the webxr samples page

Brandel: agreement on working on visual example code on the explainer

trevorPicoXR: are samples going to be public?

Brandel: yes

<Brandel> https://immersive-web.github.io/model-element/explainer_demo.html

Brandel: scope of examples will be around main functionality of model-element

ada: no problem in creating new repo for examples

Model: Formats and CSP (immersive-web/model-element #15)

https://github.com/immersive-web/model-element/issues/15

Brandel: we need to figure out best implementation and examples will be a big part of that

ada: one thing that would be good to see is if orbit control is at a level where developers can implement it, might be good to have that as sample code

<ada> https://github.com/immersive-web/model-element/issues/15

Brandel: formats issue - this was raised when people were under the impression that a model needed subresource fetching
… might be worth comparing different security approaches to subresource fetching

bajones: don't see any reason why we need subresource fetching this early on
… one of primary benefits to delivering models as separate assets is if you have large models then it can be a benefit to cache separate images or textures, but don't see that as a big use case here

Rik: you mentioned sub-resource fetches will be done as model?
… can't that be done as an image (similar rules to images and SVGs)

ada: model is different enough to an image (in terms of size at least) that if a browser is requesting a model it should say it's requesting a model and not a 300mb image

Brandel: fetching would be at the discretion of the device

trevorPicoXR: can you elaborate on threejs rendering scene to USDZ?

Brandel: there is a usdz exporter developed by threejs

ada: one resolution we want to get from this is whether people are still okay with fetching one resource rather than sub-resource fetching

(fetching one resource is preferred)

<ada> https://github.com/immersive-web/model-element/issues/27

Model: Default Styling (immersive-web/model-element #27)

Brandel: looking for any ideas/views on default styling of model
… keep to default or specify size? models can be kilometers or cm

Rik: is model the first element that doesn't have intrinsic size?
… used SVGs as an example for intrinsic sizes

Brandel: recommend that we don't rasterize in a user presentable way to allow people to do what they want

ada: also don't think we should stop UA's doing foveation on models

Brandel: CSS canvas is the ultimate determent, then you go to attributes if that's not specified

bajones: 300x 150 is a silly default to make/force people to resize
… if it's no more than just canvas then no reason to break that trend
… seems likely that this will be the first time we have an element that doesn't have a transparent background
… harsh part of this decision is we must override CSS if it conflicts with stereo presentation

<Zakim> ada, you wanted to be devils advocate

Brandel: it would be technically possible to have a transparent background but it would be the wrong thing to do in some cases

ada: in this case if you were to treated like html and iframe, it defaults to white

bajones: recalling previous conversation about whether or not we take certain CSS freedom away from developers
… not a specific issue on the agenda but might be worth discussing further with the CSS group, also reasonable to go to them with this practical recommendation

<ada> A hare ran by the window.

Rik: points out html is still transparent

bajones: whether you're in dark mode or light mode, you still have to specify that using CSS

Rik: so this would be the first element which is not transparent

[10 minute break]

ada: Discussing setting background color of model element and need to speak to CSS WG about these restrictions

Brandel: Should speak to CSS folks; but are we in broad agreement that this is complicated enough to make this be an Opaque element?

Rik: Disagree

Ada: it'll be weird from a standards thing being the one that's not transparent?

Rik: Yes

Ada: What if there was a new thing like "matting color" and that's effectively what we're doing here?

Rik: Matting is the final step, so that's different and this would just be background color

Ada: Do you think Model should be transparent even in stereo?

Rik: Yes

Ada: Don't want to encourage folks to put things behind the model, but then things get rendered in front of it, yielding an uncomfortable punch through effect

Rik: Shouldn't that be up to the author?

Ada: Don't want to take that away, but talking about defaults

Rik: Would it be weird to have your whole page be yellow except for a white box for the default model?

Bajones: I regret to inform you, I-Frames do opaque backgrounds; though spec text source is unclear, GH issues/Articles point to this being the case

Rik: Is this not an edge case?

Bajones: Yes, but there are at least some occasions where iframes get default backgrounds by default
… Not sure if they always get opaque backgrounds, you may need to opt-in to a transparent background.

Rik: Just tried it, and they don't seem to get colors by defaults

Bajones: There are cases where bg color can be picked for readability, which feels similar to our case
… If the process of having a transparent bg would make perceiving the element difficult or uncomfortable, we should pick a non-transparent bg. This is like the punch through effect

Ada: Alternative: BG color inherit

Ada: So it wouldn't be transparent by default, but wouldn't look too weird

Rik: So if you say inherit, and no one defines it, then default woul dbe transparent

Ada: Yes

Ada: Oh, it only goes to direct parent

Bajones: If Default is inherit, but there's no parent so default is actually transparent, we're kind of in the same boat. In this case we still have the transparent background in the stereo context that looks weird

Ada: This looks weird because text is in front of the model, but physically behind it, but renders differently

Brandel: [Shows a demo of this]

Brandel: Spatial CSS would be different because we could push things into the page, but if CSS only affects the surface of hte page, we can't affect the depth and so this is weird
… However, another example is having multiple models on the page

Brandel: With the default background, the teapot would render on top of the text

bajones: Just introduce z-buffer for the whole page! (/s)
… This is an awkward and uncomfortable enough thing that we should take steps to prevent this default

atsushi: Had discussion similar to this at last TPAC if Model is a MediaElement; IFrames may be special cased; but do MediaElements have such special cases?

cabanier: Should CSS even apply here and there should just always be a punchthrough? (Unless the model isn't loaded)

Brandel: Model won't occupy entire viewport, so needs to be matted on top of
… don't just want punchthrough to your aparment

Rik: This all feels weird, we should chat with CSS folks

Ada: +1
… Or TAG, but maybe CSS folks first
… will look into joint meeting or asking experts to drop-in to one of our meetings.

bajones: To motivate CSS usage: We still do want to impact size/positioning of element, so some CSS does need to apply.
… another scenario we discussed was that some cases may never want stereo
… This shouldn't be the default; but want developers to have the flexibility
… In those cases, all CSS should apply
… won't be surprised about in-headset behavior. So the stereo case is the only "edge-case" here

Ada: feel quite strongly that some CSS doesn't apply. Rules that can't work spatially, should always not work even on monoscopic display. But maybe a mode to force entirely monoscopic, and then they apply
… not just default on fallback

trevorPicoXR: This might come down to impl details when rendering with transparency, might actually need the texture of the stereo element when rendering in the browser. Does this have privacy implications?

Brandel: A couple of things to either not support or otherwise e.g. drawPixels
… Tab Previews/Shared Views are monoscopic textures would look weird if composited from user POV. So some need for a neutrally projected view
… independent of being part of web standard
… so re-use for standard would be good as well

Ada: Scribing a list of questions into GH issue

Brandel: Filter may not need special casing, perspective transforms are barely relevant
… but we shouldn't allow them
… no path to shearing model contents, but shearing viewport is definitely bad

Ada: Add other questions to Model Issue #27 so that CSS WG can pre-flight them
… being devil's advocate specifically wrt default size: A lot of content when 300x150 was defined was in landscape mode. If we did this today would it be 150x300 instead?
… also, do models have a habit of being boxy, should we consider 300x300 as the default?
… weird to specify a weird default that doesn't gain us that much, 99% use case would be using grid/flexbox

<ada> alcooper: I don't think that 300x300 would be odd at all since it makes sense for the default aspect ratio

ada: Potentially worth investigating. Is anyone opposed?

[no vocal objections]

<yonet> https://github.com/immersive-web/model-element/issues/25

Brandel: Described preffered approach for this, depends on what folks want to standardize
… would be reasonable to allow people to specify pitch (e.g. pulling front up/down).
… CAD tools support roll, so may also be relevant
… Could do this possible manually with entity transform
… Mostly about how to navigate content
… DO want to define orbit fit so that model can stay within viewport
… Unsure of other instances in Web Platform where only sometimes read-only
… in stagemode=orbit this should be readable, but not writable

test

Brandel: how do we present this in a way that is web appropriate?
… and are there any other reporting flags that we need to apply to be aware of the type of mode that something is in?
… e.g. if stagemode=orbit is on, then it's an automatic fail, but maybe other signals are relevant as well

Ada: This is a few questions, maybe we can address them individually?

Brandel: Given description of orbit, do we want to do anything else? (e.g. persisting pitch, roll, etc.)

Brandel: If folks aren't implementing it yet, may not have opinions

(Nods from around the room)

cabanier: Having things that are sometimes read-only may not be weird, set value could be "initial", and this wouldn't impact when in orbit mode

Brandel: if orbit is active, can't write. Could make "stackable" transforms, but not sure if this is what folks want

Brandel: Throw errors on DOM Matrices that have e.g. shear or non-scalar mult. So that could be an option

Ada: One thing that could be interesting, currently take DOMMatrixReadOnly as the property, what if we don't use `=` for the assignment, and allow a property giving us DOMMatrix vs DOMMatrixReadOnly depending on the mode
… this might be a way to re-use thigs that are in the platform already

bajones: Using DOMMatrixReadOnly as the mechanism for preventing folks from editing feels reasonable
… not sure what you mean by not using `=` for assignment?

Ada: currently update entity transform via `model.entityTransform = new DOMMatrix`, but this allows properties that we can't change
… Might be trickier for implementers, because you need to proxy the DOMMatrix and need a way to update it

Bajones: In JS you can have an attribute that the setter takes one value and the getter returns another. e.g. return value is always read only but setter is not.
… Assignment could be required to be a copy, which has unfortunate side-effects, but it is fairly common elsewhere
… may not be most elegant, but could work, and `get` is always the RO

Brandel: This is how it currently works

Bajones: Not sure how any of this works in idl

<ada> alcooper: I guess the concern I had is that if the general premise of model is something that is more privacy concerning how concerned are we with the state being observable such as they have clicked in or rotated the model.

<ada> Brandel: regular pointer events get past through so there is nothing new there, but I don't think there is anything special about entityTransform and that making it unreadable when stageMode is set would be as useful and people could just reroll their own interaction behaviour anyway

Brandel: In general we discussed if entityTransform is a CSS property
… WebKit folks felt this was not likely worth doing
… May want to anticipate this, but not appropriate to build right now

joshi: Do we have a roadmap for spatial CSS?

Brandel: Not really. Kind of up to folks in this room/group
… Need people with time/ability to reason through corner cases. Model is helping this, but likely not all of them

Ada: There's an abandoned detached-element repo, which could be a good starting point for this
… But not sure anyone is thinking about this right now

Brandel: Have been trying to keep view on absolute model MVP *and* the fact that this is likely not the last thing we do

Brandel: Don't think we can prevent re-work, will have to revise things based on expanding scope of spatial web

trevorPicoXR: Example yesterday was trying to go in this direction, but obviously hindered by existing mechanisms. Would love to hear if there was some way to do this atm
… standardizing takes a long time, so have to do some of this outside of standard and then bring back to standard

Brandel: Back to sometimes ReadOnly - who do we ask

Ada: TAG is a good fit

Ada: WhatWG also acceptable

Brandel: Very nearly finished with PR to WhatWG
… just describing categories of content, etc. Will land it for the presence of the model as well as any appropriate web platform tests
… When we start looking at next things to land, TAG review would be good to revisit

Ada: Resolution: Wait for WhatWG merge, then ask WhatWG and if no resolution ask TAG

<yonet> https://github.com/immersive-web/model-element/issues/109

Brandel: there's context in the issue
… secure contexts as not disclosing information from the user
… but model is not that
… it's not a feature that needs https
… people say that new features need to be https
… localhost is a secure context
… for the purposes, of a headset is harder to do

ada: on visionOS you can't do port forwarding

Brandel: there's a question on the impact of local development
… I do see the merits of security requirement

bajones: on chrome derivates, you can go to flags and you can trigger certain addresses as secure
… that option is there to make development easy
… and it's really convenient
… localhost is a secure context
… originally when we did WebVR, there was a big push to make it https only
… and there was a lot of community pushback
… I got gray hair from these arguments
… and we go to a point that there were complicated workarounds
… but when we got to WebXR, nobody seemed to care anymore
… these day there a lot of development tools to enable https
… and nobody cares anymore
… right now webgpu is https only and nobody cares
… it doesn't hurt us to do https only
… it feels like attempting to skirt the https trend, is going to cause problems later
… , I'm in favor of just doing https

alcooper: https still has value in being safer to download content
… so it's no observable

ada: I was thinking of doing http until someone tells us not to
… but this is the only html element that would require https
… so it would show fallback content when you use http

bajones: any android device would be able to use port forwarding with adb

Brandel: I have not exhausted explored what the public is doing

ada: I used engrok for a while and that worked fine
… the stuff I use only works on an internal device
… I hate having to create a local certificate and having to accept each time

Brandel: the conclusion is to add https and if people's flow is hard, we will put the pressure to fix that

ada: anything else?

Brandel: no, I don't think so

[lunch]

Unconference Hand Meshes from the WebXR API

(semi minuted)

bajones: OpenXR can now surface models

bajones: apparently unreal uses WebXR-Input-Profiles

<Zakim> ada, you wanted to be a scrooge

<alcooper> 2nd bunny sighting

<bajones> 🐇🐇🐇🐇

<Brandel> https://github.com/oculus-samples/Unity-DepthAPI?tab=readme-ov-file#7-using-hands-removal

<Brandel> https://developers.meta.com/horizon/documentation/unity/unity-depthapi-hands-removal/

Unconference: WebXR + HDR

(partially minuted)

bajones: in flat land WebGPU there is a mechanism where you associate the canvas with WebGPU device and you give it a format: RGBA BGRA (both srgb) and FLoat16 (HDR colourspace greater than 0-1) and includes a canvas toneMapping mode standard or extended, standard maps to sRGB and clamps lights greater than 1.0, extended mode will allow colours to extend beyond the standard range the

tonemapping is just whatever the screen does rather than being under developer control. But you don't get anyway to learn what the headroom of the device is.

bajones: with WebXR and WebGPU you can use the same 3 formats, BGRA, RGBA and Float16 (Float16 doesn't work in Chrome Canary yet) we don't have an equivalent for the canvas toneMapping mode.

Unconference: Shared Anchors

[break]

cabanier: shared anchors haven't really been feaasible because it is very difficult to set up outside of native experiences.

cabanier: recently the questOS shipped a feature so that headsets in the same space can communicate and set up sharedanchors without using the shared anchor infrastructure

cabanier: i've been looking at setting up a shared reference space with unique ID so you know which users are sharing a reference space

cabanier: we've been experimenting with devs so that you add a feature flag and use a new kind of reference space which will be returned immediately and then reset when it connects and agrees on a shared coordinate space

when the space updates it sends a reset event

<Zakim> ada, you wanted to ask if it could ever be cross platform

cabanier: the underlying shared anchors still use the network so to be x-platform it would need the servers to be able to talk to each other.

<Zakim> ada, you wanted to confirm that the reference space is unboduned

<alcooper> https://developers.meta.com/horizon/documentation/native/android/openxr-spatial-anchors-api-ref/#sharing-extension-and-api-overview

<alcooper> (https://developers.meta.com/horizon/documentation/native/android/openxr-spatial-anchors-api-ref/#xr_meta_spatial_entity_group_sharing-overview)

Minutes manually created (not a transcript), formatted by scribe.perl version 197 (Tue Nov 8 15:42:48 2022 UTC).