Bring 'immersive-ar' back into the spec

[cabanier]

As we discussed on the mailing list, environmentblendmode is not a good substitute for emulating AR. We want authors to choose that they are going to create AR content. By going the VR path, AR devices such as Magic Leap One and Hololens will start to present VR content which result in a bad experience.

[cabanier]

@toji In the call you mentioned that the current explainer doesn't say to use environmentBlendMode for AR content but the explainer states here:

Some devices which support the WebXR Device API may use displays that are not fully opaque, or otherwise show your surrounding environment in some capacity. To determine how the display will blend rendered content with the real world, check the XRSession's environmentBlendMode attribute.

As @thetuvix mentioned during the call, this will be confusing to users because we will first tell them this is how to create AR content but then at a later date, we will tell them to use immersive-ar

[cabanier]

@toji @NellWaliczek What can we do to bring this enum back in the spec?

As @thetuvix, @kearwood and I mentioned during this week's call, we are fine with an AR mode that has no additional features which makes this enum just a user intent. As far as I can tell, it should have no additional privacy concerns.

As @kearwood mentioned, we also don't want to pollute/encourage the VR space with AR content. Given that 3 implementors are fine bringing this feature back, what is your specific concern?

[cabanier]

I see that Chromium still has support in github :-)

[NellWaliczek]

As was summarized at the end of today's call, no decision will be made until next week's call at the earliest. Please allow @toji and me the time, as requested, to write up the details based on today's discussion. This summary will be sent, as mentioned, with enough time before Tuesday's call for all parties to have read and reflected on it. Your urgency is duly noted. However, this is not a decision to made lightly or in a rushed manner.

[toji]

I'll second what Nell said. This is an issue that we're taking seriously but we want to ensure that we're approaching it in a thoughtful manner that satisfies everyone's needs. I think everyone want to eliminate uncertainty around this feature quickly, but we also don't want to inadvertently screw up such a hugely important part of the APIs future!

Re: the environmentBlendMode text linked above, it doesn't say anywhere that this is "how to create AR content". It just describes a property of the diaplay. What I said on the call was specifically that we did not want people abusing this property as a proxy for an AR mode, and that the text could stand to be updated to make that distinction clearer.

[ddorwin]

I see that Chromium still has support in github :-)

Chromium’s support for ”immersive-ar” is behind feature flags for AR RWU APIs. The first result at the link above is a test ensuring that Chrome doesn’t expose it with core WebXR (i.e., it is explicitly not part of our WebXR origin trial). We don’t intend to ship this mode until we have confidence in the definition and its stability.

More generally, I don’t think we need to hurry any action here. WebXR still has a ways to go to CR and much longer to go before it becomes a Recommendation.

It’s also important to note that the solution is not as simple as reverting a change to restore removed text. The existing text was insufficient to ensure interoperability across the range of XR devices, and privacy was not addressed. Thus, putting (something like) this mode into the comparatively stable core spec would require addressing these concerns. (At a minimum the group would need to consider the privacy aspects - such as clarifying camera access as discussed today - since the recent privacy discussions were under the assumption that AR is out of scope for core WebXR.)

We filed https://github.com/immersive-web/proposals/issues/51 to start a collaborative discussion on these and related issues. (The list of questions there is intended to motivate and provide context for the proposed repo; there may be outcomes that don’t involve answering all of them up front.). The proposal has support from Mozilla, and I hope we can get that repo created and start addressing these questions. We would welcome your contributions there, especially since you can provide a headset POV.

It sounds like the intended outcome of this issue is a much more limited mode that is really "immersive-vr" for transparent displays. If this is something that folks are interested in (as appears to be the case), it would help to have a concrete proposal on what the mode is - and is not - and whether/how it affects probably future functionality/uses of AR mode(s).

[thetuvix]

@ddorwin:

It sounds like the intended outcome of this issue is a much more limited mode that is really "immersive-vr" for transparent displays. If this is something that folks are interested in (as appears to be the case), it would help to have a concrete proposal on what the mode is - and is not - and whether/how it affects probably future functionality/uses of AR mode(s).

My mental model around the WebXR module split is that we've bought ourselves the ability to address API features separately when they're orthogonal. This avoids the situation where we feel the need to save features until we can ratify a bundle of them together - now, UAs and developers can move forward with features as they independently converge.

With that lens, I don't see the mode being proposed here as some different "limited" mode that is separate from "immersive-ar". Instead, this mode is the fundamental basis for any AR app, now and in the future.

An app with just the "immersive-ar" mode plus the core WebXR spec can get predicted 6DoF device poses in an "unbounded" space, receive input, and render frames that will be presented in an AR headset or on a handheld AR device. For many early apps exploring AR on the web, that will be enough to provide an AR experience that allows users to walk around and interact with floating content at real-world scale in their environment. For example, I see nothing blocking us from producing a WebXR port of Galaxy Explorer that runs on ARCore, ARKit, Magic Leap or HoloLens with just that base set of capabilities already present in WebXR 1.0.

Moving forward, of course, such apps are also quite likely to want access to hit-testing, anchors, geometry detection and lighting estimation, at which point they would then make use of one or more of these additional modules as well. Apps that need those additional capabilities would request them during session initialization, at which point UAs can present any stronger permission prompts necessary to the end user and warm up any extra data for the app.

We do need to nail down the privacy implications around users on handheld devices believing that unprivileged "immersive-ar" sessions have access to the camera feed that they don't actually have. However, we should not unnecessarily couple that remaining privacy work to the various modules above - doing so would waste the agility afforded to us by the module path we've embarked on for WebXR, creating market pressure for Magic Leap and HoloLens UAs and developers to lean on "immersive-vr" for now as a crutch, building up a catalog of mislabeled WebXR content across the web that we'd then need to reckon with moving forward.

[cabanier]

I see that Chromium still has support in github :-)

Chromium’s support for ”immersive-ar” is behind feature flags for AR RWU APIs. The first result at the link above is a test ensuring that Chrome doesn’t expose it with core WebXR (i.e., it is explicitly not part of our WebXR origin trial). We don’t intend to ship this mode until we have confidence in the definition and its stability.

More generally, I don’t think we need to hurry any action here. WebXR still has a ways to go to CR and much longer to go before it becomes a Recommendation.

I agree. Since it will take so long to go to rec and even longer for the other components to get to REC, it's imperative that we don't try to hack AR experiences into 'immersive-vr'.

It’s also important to note that the solution is not as simple as reverting a change to restore removed text. The existing text was insufficient to ensure interoperability across the range of XR devices, and privacy was not addressed. Thus, putting (something like) this mode into the comparatively stable core spec would require addressing these concerns.

Can someone please tell me what the specific privacy concerns are of exposing an enum that only conveys user intent?

(At a minimum the group would need to consider the privacy aspects - such as clarifying camera access as discussed today - since the recent privacy discussions were under the assumption that AR is out of scope for core WebXR.)

We didn't discuss camera access. Why would 'immersive-ar' need to access the camera in a Hololens or Magic Leap One? Maybe for phone AR it is needed but since the compositing with the camera data would be under control of the browser (and not the author), what would be the concern? Someone brought up that users might gets a spoofed warning that their feed was recorded as a reason not to have 'immersive-ar' but I don't get that argument because a simple enum is not going to stop this from happening.

We filed immersive-web/proposals#51 to start a collaborative discussion on these and related issues. (The list of questions there is intended to motivate and provide context for the proposed repo; there may be outcomes that don’t involve answering all of them up front.). The proposal has support from Mozilla, and I hope we can get that repo created and start addressing these questions. We would welcome your contributions there, especially since you can provide a headset POV.

Sure. As @kearwood , @thetuvix and I said, immersive-ar without any additional sensor data is useful. I understand that more work on the privacy front is needed to get meshing and real world hit testing, but that is not what we're asking for.

It sounds like the intended outcome of this issue is a much more limited mode that is really "immersive-vr" for transparent displays. If this is something that folks are interested in (as appears to be the case), it would help to have a concrete proposal on what the mode is - and is not - and whether/how it affects probably future functionality/uses of AR mode(s).

'immersive-ar' as it was previously defined in the spec suits our needs. (Please chime in if this is not the case @kearwood @thetuvix ) I also strongly believe that future extensions don't need to be limited to the AR platform. If VR get sophisticated enough, they might want to have support for hand and world meshing or even real world hit testing.

[cabanier]

I didn't see @thetuvix 's reply before I sent mine but I agree with everything he said.

[ddorwin]

@thetuvix wrote:

An app with just the "immersive-ar" mode plus the core WebXR spec can get predicted 6DoF device poses in an "unbounded" space, receive input, and render frames that will be presented in an AR headset or on a handheld AR device. For many early apps exploring AR on the web, that will be enough to provide an AR experience that allows users to walk around and interact with floating content at real-world scale in their environment. For example, I see nothing blocking us from producing a WebXR port of Galaxy Explorer that runs on ARCore, ARKit, Magic Leap or HoloLens with just that base set of capabilities already present in WebXR 1.0.

Is there a reason that a WebXR port of Galaxy Explorer shouldn't also work in "immersive-vr" sessions - or on VR headsets? If not, what is the advantage of the app using "immersive-ar" rather than "immersive-vr" with appropriate behavior for the device's environmentBlendMode (adjustments that would also need to be made in an "immersive-ar" session)?

We do need to nail down the privacy implications around users on handheld devices believing that unprivileged "immersive-ar" sessions have access to the camera feed that they don't actually have. However, we should not unnecessarily couple that remaining privacy work to the various modules above - doing so would waste the agility afforded to us by the module path we've embarked on for WebXR...

I'm not aware of anyone suggesting that "immersive-ar" be coupled to the RWU incubations. (In fact, Chrome prefers that the various areas of investigation are incubated independently.) However, the development and definition of "immersive-ar" should be mindful of future RWU capabilities, just as core WebXR's design is not coupled to AR capabilities yet they informed its design. For example, since the intent is for such sessions to expose RWU, there are considerations for clearly communicating the type and scope of such access. This led to the "AR mode" concept, which likely has an impact on the design. There are also other questions/implications to consider when adding a new mode that have nothing to do with RWU.

[thetuvix]

@ddorwin:

Is there a reason that a WebXR port of Galaxy Explorer shouldn't also work in "immersive-vr" sessions - or on VR headsets?

I'm not aware of anyone suggesting that "immersive-ar" be coupled to the RWU incubations. (In fact, Chrome prefers that the various areas of investigation are incubated independently.)

This is the key question - in a world where many RWU capabilities exist, but they are not coupled with a general catch-all concept of "AR", what does it actually mean for the app to select "immersive-vr" or select "immersive-ar"?

For example, my understanding from previous comments is that Android UAs would typically interpret "immersive-vr" as a request to spin up a VR headset subsystem such as Daydream, whereas "immersive-ar" would signal an intent to use ARCore in handheld mode. If the intention of Galaxy Explorer is to visualize the solar system in the context of your room, the app may prefer to go the ARCore route, even if the app is not then placing the sun on a real-world plane.

From that perspective, I've interpreted "immersive-vr" as the app's request to end up with an environment blend mode of "opaque", with "immersive-ar" being the app's request to get "additive" or "alpha-blend" depending on the device. To solve this immediate Android ambiguity, we could have named them "immersive-opaque" and "immersive-nonopaque" or perhaps "immersive-headset" and "immersive-handheld" - my recollection is that the group found it more evocative for those still new to the WebXR API to send them down a "VR" or "AR" path, saving more advanced concepts like environment blend mode until folks got deeper into the API.

[cabanier]

For example, my understanding from previous comments is that Android UAs would typically interpret "immersive-vr" as a request to spin up a VR headset subsystem such as Daydream, whereas "immersive-ar" would signal an intent to use ARCore in handheld mode. If the intention of Galaxy Explorer is to visualize the solar system in the context of your room, the app may prefer to go the ARCore route, even if the app is not then placing the sun on a real-world plane.

Thinking about this some more, is a handheld device really "immersive"? Maybe we need a new category for devices that are not immersive such as phones and tablets as opposed to a head mounted projector system.

I think there are a lot of reasons to break it into its own category. For instance, a handheld-ar session can have a UI that is hard locked to the screen or have access to DOM Layers. On immersive-vr/immersive-ar these constructs are not desirable and UI and input will be very different.

Of course this means that authors are going to have to create different code paths for different device types but I believe that is unavoidable. Would people be opposed to this? Or is there a hope within the group that the same code can run well across a range of devices? @toji ?

[TrevorFSmith]

This comment on #788 applies to this Issue.

TL;DR the question is not whether or not to give authors, users, and browser vendors the ability to differentiate between AR-centric and VR-centric use cases. The question is whether we should block WebXR core from review and standardization while we work on the still-open questions of the immersive-ar flag and problems that go with it.

It seems to me that this Issue and #788 have more clearly revealed that there remains significant disagreement about the fundamental nature of immersive-ar around the handheld/head-worn problem, blending modes, and the security issues.

[TrevorFSmith]

More related conversation in this comment in #788.

[cabanier]

This comment on #788 applies to this Issue.

TL;DR the question is not whether or not to give authors, users, and browser vendors the ability to differentiate between AR-centric and VR-centric use cases.

No, that is not the issue. Please look over the thread to see what the concerns are. I can restate them if you want.

[TrevorFSmith]

No, that is not the issue. Please look over the thread to see what the concerns are. I can restate them if you want.

That is a wildly inappropriate response, Rik, bordering on a violation of the Code of Conduct. Please de-escalate how you approach this topic.

[cabanier]

I'm sorry if I made you feel like I was somehow attacking you. This thread is really long and there was additional information over email and during the weekly call so it might make sense if I restate what the issue is. That is all I meant.

[ddorwin]

@thetuvix wrote:

This is the key question - in a world where many RWU capabilities exist, but they are not coupled with a general catch-all concept of "AR", what does it actually mean for the app to select "immersive-vr" or select "immersive-ar"?

I agree that this is a key question. The current WebXR design has effectively split all experiences into two modes, but applications don't necessarily break down along any single definition of "AR" vs. "VR." I think your examples of "immersive-opaque" / "immersive-nonopaque" and "immersive-headset" / "immersive-handheld" illustrate this well.

Does the decision to split along "AR" vs. "VR" still make sense given the new information in this discussion, the decision to support RWU-less "AR," and the addition of the required/optional features mechanism? Perhaps developers would be better served with either a) more modes that are more specific to usage (as @cabanier suggests) or b) a single "immersive" mode with more options that can be mixed as appropriate. [1]

As an example, it's not clear to me that the context of the user's room is critical to Galaxy Explorer. It's possible that the developer of such an app might feel that immersion in a headset is more critical than what the background is. On the other hand, for furniture shopping, any type of AR might be more desirable than VR, but a 3D model in a VR HMD is still better than looking at a flat version. Or perhaps the developer would prefer an opaque background over AR if there is no RWU to allow the furniture to be anchored.

One of the problems with the current API design is that developers can only ask three questions (via supportsSession()) before committing to a mode: Do you support inline? Do you support immersive VR? Do you support AR? The developer then has to choose one of those without knowing whether it is suitable (i.e., the specific capabilities or whether any RWU is supported in the AR mode). This seems reasonable for VR headsets, which don't vary too much. However, developers of some XR applications probably won't have enough information to decide between AR and VR until after they've requested the session. Given this, perhaps the specification should not force a decision but rather let the developer specify what they want to do in an immersive session.

The issues behind the current discussion are a good example. There isn't necessarily an inherent incompatibility between "VR content" and see-through headsets, but there are certain types of content (i.e., full FOV motion) that are problematic, especially with current display technology. If developers had to request more capabilities or provide more information about their application [2], user agents could more accurately report whether the client supports it - and enable more and better experiences across devices. With the current design (and related implementer decisions), users of certain headsets will not have access to any VR content unless the developer specifically targets those headsets. This is unfortunate since progressive fallback and making it possible/likely that as many users as possible have access to XR content has been a consistent goal for WebXR since before the rename.

[1] This wouldn't necessarily mean reopening VR Complete. The core spec and implementations could keep using "immersive-vr", though it might eventually be deprecated should the "core" AR work come up with a better solution.

[2] Taking the current concerns about see-through headsets as an example, an indication that the world won't move or that the experience only needs a small FOV could be an indication that the application can work on such headsets. User agents could even choose to enforce the specified conditions somehow if they wished.

[blairmacintyre]

FWIW, I like the direction you are going @ddorwin ... in Argon, we didn't really distinguish between AR and VR, but rather distinguished between capabilities and how "reality" was represented.

Differentiating between "inline" and "immersive" and then leaving the rest to capabilities also has the advantage, as you say, of supporting much more interesting approaches to progressive refinement. And it also allows different UAs to give users control over what different apps "see" in terms of device capabilities, if they want.

[speigg]

In Argon, the primary way we distinguish between immersive applications is what we call either an “environment-layer” application, or an “augmentation-layer” application. RWU is provided by (or derived from) the “environment-layer” (which itself may be based on RWU of the physical world), and likewise RWU is provided to the “augmentation-layer”. If the application author chooses “environment-layer”, then their application is presenting a digital environment (in which case they have full control over their world coordinate system and how that world is navigated, e.g., able to provide “teleport” controls). If the author chooses “augmentation-layer”, then they are presenting digital content that is registered against an underlying environment (real or digital), and must not make assumptions about how that environment can be navigated. The primary reason for distinguishing applications in this way was so that multiple applications could be integrated together in a “unified view of reality”.

Everything else (the nature of the display, opaque vs non-opaque, handheld vs headworn, 3DOF vs 6DOF, RWU, etc.) we expected developers to adapt/react to (dynamically), as we gave users complete control over these aspects.

[speigg]

I think part of the problem is the assumption that the developer can always determine what set of characteristics will create the best experience for the user. Shouldn’t it be up to the user to weigh the pros/cons of experiencing the Galaxy Explorer in the context of their room vs in a more immersive presentation without their room visible? Shouldn’t the user be able to decide if their physical environment is suitable to viewing 3D models when furniture shopping (perhaps their current physical space is cluttered or not large enough), or if it would be preferable to view that 3D model within a digital environment (e.g., a generic virtual living room, or even a digital scan/representation of their real living room, assuming they are not currently at home)?

[cabanier]

Thanks @ddorwin , @blairmacintyre and @speigg for your feedback. I won't reply using inline comments this time but can if anyone prefers that.

There are a several issues if we just request immersive and then let the author figure out the capabilities:

1. It complicates author choice. If an author just wants to create a VR, AR or handheld AR experience, they have no way of discovering capabilities until after they request the session. In addition, if there are future extensions or modes to the spec, it might break the experience because they didn't account for those. Forcing them to support all modes including future ones is a high bar.

2. it provides a poor user experience If a site properly detects the device type after the session and determines the device is not supported, the user will first see a prompt for permission, a flash of VR and then be thrown back to the 2D browser.

3. it's unclear what a UA should do if it is capable of more than 1 session mode If an author requests an immersive session and the device is capable of more than 1 mode, what mode should the UA turn on? Also, what permission should the UA be asking for? For instance, a phone could be capable of both VR and handheld AR. Or for a device such as the HTCVive Pro, when should it turn the cameras on?

4. it results in broken sites Some authors might just create content that works correctly on 1 session type and won't bother to check. This will result in frustrated users because the experience looks bad or is totally broken.

If we have multiple session types, it will give savvy authors a choice before the session starts so they can set up their logic and inform the user of what they will or won't see. Nothing is stopping authors from checking multiple times what types of sessions are supported. For instance, Angry Birds works equally well in VR/AR with minor tweaks so the developer can just call supportsSession with each experience they want to offer (likely from best to worst). Possible types:

• inline

• immersive-vr full screen with 6dof controller, 3D UI and an opaque display

• immersive-ar full screen with 6dof controller, 3D UI and a transparent display

• handheld-ar (future) full screen with touch input, screen locked UI and a transparent display

It will also stop sites from unaware authors from showing unusable content which will frustrate users and likely the original author.

@ddorwin I appreciate your concern that this will break the progressive fallback the web platform usually tries to offer. However since all content is author generated, I don't see how the UA could support or enforce this. I believe the best solution is to give the author the choice and let them provide the fallback. Your concern about what choice to give the user if both AR and VR are possible is likely best handled by the author. If the current APIs don't provide enough support, we should extend the spec (at a later date of course)

[cabanier]

I think part of the problem is the assumption that the developer can always determine what set of characteristics will create the best experience for the user. Shouldn’t it be up to the user to weigh the pros/cons of experiencing the Galaxy Explorer in the context of their room vs in a more immersive presentation without their room visible? Shouldn’t the user be able to decide if their physical environment is suitable to viewing 3D models when furniture shopping (perhaps their current physical space is cluttered or not large enough), or if it would be preferable to view that 3D model within a digital environment (e.g., a generic virtual living room, or even a digital scan/representation of their real living room, assuming they are not currently at home)?

I agree that this should be the case. However, because the author is in charge of drawing the scene, it is not something that the browser can enforce. The browser should be able to give enough information to the author so they can present the user with a choice.

[speigg]

The browser can’t enforce that people don’t build crappy/unusable websites either. I think it’s okay if some experiences don’t work 100% correctly in all cases, but even 50% usability is better than 0%. I think progressive enhancement is the way to go. It might be complicated to optimally support all of the various cases (e.g., having screen-locked UI vs UI in the world, touch-input vs wand-input vs gesture-input, etc.), but that just opens up the space for people to build intermediary adaptive UI libraries that solve these problems.

[cabanier]

The browser can’t enforce that people don’t build crappy/unusable websites either.

It's true that we can't stop that but we can try to stop it from happening by accident.

I think it’s okay if some experiences don’t work 100% correctly in all cases, but even 50% usability is better than 0%. I think progressive enhancement is the way to go. It might be complicated to support all of the various cases (e.g., having screen-locked UI vs UI in the world, touch-input vs wand-input vs gesture-input, etc.), but that just opens up the space for people to build intermediary adaptive UI libraries that solve these problems.

Almost everyone will use frameworks that will do the progressive enhancement. I'm saying: let's give authors and frameworks the information they need to make progressive enhancement happen and let's not opt them into everything and then let them figure out if they can support it.

@speigg , @blairmacintyre , @ddorwin , what do you think of the 5 issues about just having immersive I listed above?

[speigg]

@speigg , @blairmacintyre , @ddorwin , what do you think of the 5 issues about just having immersive I listed above? 1) It complicates author choice. If an author just wants to create a VR, AR or handheld AR experience, they have no way of discovering capabilities until after they request the session. In addition, if there are future extensions or modes to the spec, it might break the experience because they didn't account for those. Forcing them to support all modes including future ones is a high bar.

I think it makes the choice easier. Either present content inline in the context of a normal web page, or present content "immersively", using whatever capabilities are enabled by the UA.

2) it provides a poor user experience. If a site properly detects the device type after the session and determines the device is not supported, the user will first see a prompt for permission, a flash of VR and then be thrown back to the 2D browser.

This is only true if the author fails to support the absolute minimal (VR) experience enabled by the features in the core spec.

3) it's unclear what a UA should do if it is capable of more than 1 session mode. If an author requests an immersive session and the device is capable of more than 1 mode, what mode should the UA turn on? Also, what permission should the UA be asking for? For instance, a phone could be capable of both VR and handheld AR. Or for a device such as the HTCVive Pro, when should it turn the cameras on?

Applications should still request permissions for capabilities (e.g., for RWU) that they want, but in general these additional capabilities should be used for progressive enhancement. I'm of the opinion that the UA can decide which mode is best when multiple session modes are available (this might mean that the UA makes assumptions based on the requested capabilities, or it might mean that the UA gives the user the choice via a prompt).

4) it results in broken sites. Some authors might just create content that works correctly on 1 session type and won't bother to check. This will result in frustrated users because the experience looks bad or is totally broken.

Again, this is only a concern if the author fails to support the absolute minimal (VR) experience enabled by the features in the core spec, which is all that the application should assume is available. The minimal VR experience may not be ideal everywhere, but it should still "work" everywhere without additional burden on the developer. Am I wrong?

[speigg]

For example, an author may develop a screen-locked UI as a "progressive enhancement" that is only shown when presenting to a handheld device. If the author fails to implement this particular "progressive enhancement", then their minimal VR experience should still "work" (perhaps not optimally, but at least to some extent) when presented to a handheld AR device.

[cabanier]

@speigg we're in agreement that this is something we want. The disagreement is if this should be an opt-in by the author, or an automatic upgrade.

[speigg]

@speigg we're in agreement that this is something we want. The disagreement is if this should be an opt-in by the author, or an automatic upgrade.

I don't see what you mean by "automatic upgrade". I'm assuming that applications would only have access to the additional (e.g., RWU) capabilities if they have opted into them, by requesting those particular capabilities.

[speigg]

Ah, based on your original issue, I think you're saying that “VR” applications shouldn't "automatically" work (at all) on see-through displays. Yeah, I would disagree.

[cabanier]

Ah, based on your original issue, I think you're saying that “VR” applications shouldn't "automatically" work (at all) on see-through displays. Yeah, I would disagree.

That would be up to the user agent to decide. The spec can stay silent on that. Right now, only Magic Leap has said they would do this and this can be up for debate.

If an author just wants their content to present on an AR (and doesn't care that it looks bad), they can always create an AR session and present the same content. Again, it would be up to the author to decide.

[cwilso]

To checkpoint - tomorrow we'll discuss the proposal that Nell made, with some slight tweaks after discussions today. (see below for proposal.)

In short - the key questions that have arisen appear to me to be ones of the tradeoffs between progressive capability across devices (a core tenet of the Web, I'd point out) vs. ensuring developer control and best presentation on in given environments (clearly desirable). I've heard the concerns about ensuring that we don't provide two ways to create AR content in the short term, and agree this is a concern. I think we can avoid this. I also hear the question about whether VR content should be automatically supported in a see-through AR device, and agree this needs to be a choice left up to the UA. (I'd be personally disappointed if it weren't supported by my device, but concede this is a personal choice.)

The proposal (with due credit given to Nell for writing most of this):

The core of AR remains under the scope of the Working Group.  Additional incubations (ex.: real world understanding, lighting, etc) are under the scope of the Community Group.

The WebXR AR core will include:

• A way to request an AR session (aka. ‘immersive-ar’)
• Environment blend mode will move to this AR core spec (from the WebXR core), enabling developers to differentiate between ‘additive’ and ‘alpha’ environment blend modes, and this is also where we will specify what environment blend modes will return for "immersive-vr" sessions.
• The ability to differentiate whether UI elements should have the option of being placed in a ‘screen-space’ or must be placed in ‘world-space’.
• Possibly allowing developers to restrict the creation of sessions based on the properties defined above
• Mitigations for all associated privacy and security issues introduced by these features (but NOT mitigations for privacy and security issues that may be introduced by OTHER AR work in other incubations, like real world understanding or camera alignment or the like).

We will continue to drive for concrete answers to the outstanding issues relating to the “core” of AR as quickly as possible.  This is our top priority alongside resolving remaining issues in WebXR Core and Gamepad.  In the best case, if we are able to agree upon and define a concrete “core” of AR quickly enough, we can submit it for CR at the same time as the main WebXR Device API.   All “non-core” AR features will incubated in different repositories, including anchors, hit-testing, real-world geometry, and any support for a DOM overlay.  These incubations will start under the scope of the CG. When WG consensus is that any incubation is stable enough, we can adopt them into the WG. (The WG can discuss if they should be incorporated into a current spec or should continue as a separate module specification.)