Consider merging `immersive-ar` into WebXR

[saschanaz]

Currently there are two enums named XRSessionMode in Web IDL world, one from WebXR Device API and another from WebXR AR module. As they can cause potential confusion, could we consider merging those two?

Relevant issues:

• Validate IDLs in idl_test() web-platform-tests/wpt#18382 (comment)
• Allow partial enums whatwg/webidl#184

[Manishearth]

Part of the reason behind the module split was so that we could cleanly define all of the AR stuff in a separate module. Moving this back makes modules less useful.

That said, we could do the minimal change here: move immersive-ar into the WebXR spec, define it as erroring early in requestSession() and isSessionSupported(), and define immersive session as containing it. This spec can then change it to a non-error.

[blairmacintyre]

Isn't there a way to say "this is additive to the thing in the main spec"? It's understood that this module build on webxr, so in general we'll need a convention to say "add or change some definition in the main spec"

[saschanaz]

Currently there is no machine-readable way to say an enum is an extension of another one. There is an existing discussion to allow it: whatwg/webidl#184

[Manishearth]

@blairmacintyre No, see whatwg/webidl#184 . Talking to folks at TPAC it seemed like partial enums weren't really desirable.

This is doable for spec text (which we'll have to do a bunch), but less so for webidls, especially since they're slurped by various tools (which is AIUI the context of this issue). It might be possible to tweak the tooling to support this, idk.

[mounirlamouri]

In this case, it may be possible to simply define immersive-ar in the core spec and say that the feature is defined as part of webx-ar and if the implementation doesn't support this spec, it should say it's not supported.

It's fairly similar to what @Manishearth suggests above with the exception that I do not think we should have one spec requiring to fail and another saying otherwise because the conflict between the two specs would prevent browsers to properly implement one or the other.

[rcabanier]

Wouldn't that make it harder to add other modes later (ie handheld-ar)
What happened to the proposal to just make it a DOMString and not rely in WebIDL to do the parsing?

[Manishearth]

I do not think we should have one spec requiring to fail and another saying otherwise because the conflict between the two specs would prevent browsers to properly implement one or the other

I think we have precedent with specs explicitly overriding others, especially if we call it out in the first spec. There will need to be some form of overriding no matter what.

We could also do it as a DOMString, yes. I feel like that's not as good for documentation.

[saschanaz]

I think @mounirlamouri's suggestion matches what Permissions spec does: it simply describes it's for another spec and skips everything else.

[mounirlamouri]

Wouldn't that make it harder to add other modes later (ie handheld-ar)

No, it wouldn't. The only impact would be that if we send a version of WebXR to REC, it may miss new values that are in the ED. Though, this is mostly an administrative problem, it has no practical impact.

What happened to the proposal to just make it a DOMString and not rely in WebIDL to do the parsing?

DOMString seems to be a counter-pattern here. partial enum are being pushed back because the TAG and the community at large is pushing against specs editing the behaviour of other specs. Trying to make things DOMString because it would facilitate doing that may not be the right approach in spirit.

[Manishearth]

/agenda to figure out what we want to do here

[toji]

Honestly my preference would be to keep enums well scoped to the documents that define their behavior, but given that it appears partial enums are not being considered I don't think we can conscionably continue to write spec text as if they exist.

That leaves us with two clear alternatives:

• Define all known enum values in the document that the enum is declared in and clearly link out to the appropriate document for the behavioral description.
• Maintain a separate document that defines just the enum and links to the appropriate behavioral descriptions for each value. (This is, effectively, the Permissions approach.)

The latter approach is certainly more extensible, and it may be prudent for something that we expect to be amended frequently. (Perhaps this is how we should manage the feature descriptors list?) It does feel like overkill for an enum that is expected to only have 3-4 items in it in the forseeable future, though.

That's especially true for an enum defined in a spec outside the IW group's control, like Gamepad. In that case it seems pretty clear that the recommendation is that we work with the host spec to incorporate our desired enum value. It's obviously not desirable to jump into asking a different spec for modifications right away, though, so I would recommend that until a proposal solidifies we leave an ISSUE in the spec text indicating the desired additions to the other spec in lieu of duplicating the enum or faking partial enum support.

Given all that, my suggested changes (though I'm not particularly excited about them) are:

• Move the "immersive-ar" enum value into the WebXR spec with a link to the webxr-ar-module spec for the definition.
• Send a pull request to the gamepad API to add the "xr-standard" enum value with a link to the webxr-gamepad-module for the definition.
• Evaluate if there's any similar lists in the core WebXR spec that we feel will be modified by multiple modules in the future and consider moving them into a separately maintained list (feature descriptors are a strong candidate for this.)