CSS pseudo-class/styling and Fullscreen API integration #14
Conversation
|
PTAL, now updated to have independent styling that is decoupled from Fullscreen API's pseudoclass and UA stylesheet. (There's a rule to set |
|
@Manishearth FYI, if I remember right you were asking about this at the f2f. |
| transform: none !important; | ||
|
|
||
| /* intentionally not !important */ | ||
| object-fit: contain; |
There was a problem hiding this comment.
Do you need this rule? It exists for images going fullscreen, and presumably it makes no sense to have an image as the XR overlay element?
There was a problem hiding this comment.
I don't have a strong opinion either way, but I think it would be preferable to keep the rule for consistency. While using an image as the overlay element would be unusual, there isn't really a reason to prohibit it.
A fullscreen-based inplementation would be applying the object-fit rule since the overlay element matches both :fullscreen and :xr-overlay.
index.bs
Outdated
| The user-agent style sheet defaults for the DOM Overlay element are as follows: | ||
|
|
||
| <pre highlight="css"> | ||
| :xr-dom-overlay { |
There was a problem hiding this comment.
Having "dom" as part of the web-exposed name is unusual, would just :xr-overlay be OK? (A selector always matches something in the DOM, so this reads a bit like :first-dom-child instead of :first-child.)
There was a problem hiding this comment.
That sounds reasonable, I'll change it to :xr-overlay. For the others in the thread, please speak up if you feel strongly about it.
index.bs
Outdated
| } | ||
| </pre> | ||
|
|
||
| NOTE: This is based on [[FULLSCREEN#user-agent-level-style-sheet-defaults]], with additional styling to make the overlay element transparent. A user agent MAY use the Fullscreen API to implement the DOM Overlay, and in that case its backdrop must also be transparent. The styling for [=:xr-dom-overlay=] does not explicitly depend on the Fullscreen API's pseudoclass or styling so that user agents have the flexibility to implement it independently of the Fullscreen API. |
There was a problem hiding this comment.
It looks like all the requirements here are just MAY. Do you expect implementations to differ in practice here, or why not a stronger requirement?
There was a problem hiding this comment.
The reason for not requiring use of the Fullscreen API is that this seemed too restrictive on a platform with multiple displays. For example, when using a desktop PC with a tethered headset, the current WebXR immersive-vr mode continues displaying a 2D web page on the normal monitor while the headset is showing immersive content. In this case, the Fullscreen API could be expected to apply to the 2D monitor display, and a DOM overlay may be using a separate mechanism for the immersive display, so allowing the APIs to work separately seemed preferable.
@Manishearth, since you were one of the people requesting this distinction, do you have more context?
There was a problem hiding this comment.
I don't actually recall when we last discussed this, but yeah, we basically should be able to distinguish between 2d and 3d fullscreen API uses.
There was a problem hiding this comment.
It sounds like the important distinctions are in the hardware the browser is running on / attached to, not differences between browsers. If both Chrome and Firefox would show the same behavior on the desktop PC in the example, does the spec spell out what should happen in enough detail for Chrome and Firefox to achieve interoperability here?
There was a problem hiding this comment.
I think this should be the case, with the caveat that the specification intentionally leaves some flexibility to the user agent about details such as placement of the overlay. The goal is that applications should be usable across browsers and for different hardware types.
There was a problem hiding this comment.
Ah, so I think the problem is that my reading of the "MAY" isn't what's intended here. I've filed #15 to request clarification.
|
I'll merge this to make discussions less confusing, but please let me know if you have additional feedback or requests for further edits. |
No description provided.