Finalize API shape for supporting multiple layers

[toji]

While we do not intend to support more than a single WebGL layer for the first version of the spec, we know that we will want multiple layers down the road and as a result we should make sure that the mechanism for setting a session's layers can extend to support it.

That could mean just leaving the baseLayer bit we have right now in place, or switching over to an array-based design, or any number of other designs. We just need to have a plan so that we don't need to break the API shape after the June Milestone.

Highly correlated with the work happening in https://github.com/immersive-web/layers

[ddorwin]

I believe we should stick with baseLayer for the first version of the spec. I think it is premature to try to define something else until we have a better understanding of how layers will work and be used. Issues to address may include: How are layers added and removed? Are there events? Are there configuration options (i.e., alpha)?

I don't think adding support for multiple layers in the future would break the API shape. It should be easy to feature detect the new capability, and it's not the end of the world if implementations need to support both baseLayer and a new mechanism. User agents (and the community) could also work to deprecate the former over time (browsers have processes for this). It also seems likely that baseLayer is polyfillable on top of some multi-layer mechanism and vice versa (for single layers).

I would be more worried that in an effort to support multiple layers now, before having incubated and iterated on another layer, we may end up specifying a mechanism that doesn't meet the eventual needs of users of such layers and that it will be more difficult to replace and/or polyfill such a mechanism.

Note: The current attribute-based design might result in indirect failures for applications written today after user agents remove baseLayer because such user agent implementations would silently ignore the value, causing a failure somewhere else rather than an exception at a call site. This only affects how the failure is exposed, though, and the deprecation process should help avoid this altogether for the most part.

[toji]

This was discussed at the June 2019 F2F. The group's conclusion was to stick with baseLayer for the core spec, much like David suggests above, and then allow a more robust layer array system to be implemented alongside it. The presumption is that using them in the future would be a strict OR mechanism, where developers can either use baseLayer OR its successor, but not both at the same time.