New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[mediaqueries-5] Media query for enclosed screens #9701
Comments
The idea, I suppose is mainly about whether others can see it? I'm curious why this might matter - I guess there's some thought that it might be security related? But one can share their view on most/all of those devices so I expect that it's never totally that.. Or was this about something else? For example, when I'm using one and a password field is shown to me, it is still obfuscated.. Is the idea you might want it to not be by default as long as you're not sharing your screen? I guess another thing that is interesting on a lot of these devices is that you can have actual gestures in the regular sense of the word, not in the touchpad/2d screen sense.. |
The QR use case it's actually quite real. There are users of Wolvic asking for some way to interact with webpages that use QR codes while wearing a headset. Having this kind of authentication is actually pretty convenient for those users because typing in XR is not specially fast/comfortable (unless you use an external bluetooth keyboard). However as @bkardell mentioned, streaming is a quite common use case already available in most of the devices I tried. |
The CSS Working Group just discussed The full IRC log of that discussion<TabAtkins> fantasai: for virtual headset displays, there might be some things that are different from regular displays an author will care about<TabAtkins> fantasai: We have several MQs already - pointer, hover, environment-blending <TabAtkins> fantasai: One thing that came up is whether you can scan a QR code on the page - if you're on a headset, your phone can't be used to scan something on the page <bkardell_> q+ <TabAtkins> fantasai: So q is if we should add this, and if so, what to call it? <astearns> ack bkardell_ <TabAtkins> bkardell_: Whether you can scan a qr code is something people want to do with.. <TabAtkins> bkardell_: igalia makes a vr browser <TabAtkins> bkardell_: used on many enclosed-screen browsers <TabAtkins> bkardell_: The fact that you can't scan the obvious way doesn't mean there won't be a way to do it <TabAtkins> bkardell_: The browser might offer a way to follow a qr code itself <florian> q+ <TabAtkins> fantasai: In general, you can't take a photo of the scren with another device <TabAtkins> bkardell_: Not directly, but you can cast to another device <TabAtkins> fantasai: At that point you have another device and it can resolve the MQs differently <astearns> ack florian <TabAtkins> bkardell_: Well, not if it's like ChromeCast <TabAtkins> florian: Need to be careful about the "cast" situation <TabAtkins> florian: In the flip way, you think if you're *not* in an enclosed screen you want to hide passwords by default, but show when you are in an enclosed screen because nobody can see <TabAtkins> florian: But if casted they can <TabAtkins> florian: So does it mean people *probably* can't see your screen? Or *definitely* can't? <TabAtkins> florian: Think we need to know more about the intended use-cases (plural) to know how they expect to behave <TabAtkins> bkardell_: Yes, agreed. There's "pass-thru" on devices; on a Quest it's not good enough for photos, but for others... <TabAtkins> bkardell_: Might be good to bring to Immersive Web group. Happy to talk more offline. <TabAtkins> bkardell_: I think there def are some more MQs to do here <TabAtkins> astearns: Sounds like we should take this back to the issue and explore the specific use-cases in more detail. <TabAtkins> astearns: Is that ok? <TabAtkins> fantasai: I think that's fine. Main thing from our side is the QR code issue. <TabAtkins> bkardell_: Explain that? <TabAtkins> fantasai: You ahve an app, can send info or auth yourself by scanning a QR code with your phone and it'll link accounts <TabAtkins> fantasai: But you can't do that if you're on a headset <fantasai> TabAtkins: The phone is the thing that needs to see the QR code, doesn't matter if the headset can scan it <fantasai> TabAtkins: so that e.g. you can link your phone chat with desktop chat <fantasai> TabAtkins: This is not handled by the browser on the headset being able to do anything <fantasai> bkardell_: the browsers on both devices can talk to each other <TabAtkins> bkardell_: Those devices generally have some way to send info to another device. We should talk offline <TabAtkins> astearns: In the cases I can think of, where scanning a QR code is necessary, there's usually an alternate provided bc not everyone has a second device. <TabAtkins> astearns: We'll take it back to the issue and explore the use-cases. |
Random suggestion for the name: single-viewer or something like that that to indicate that a phone, a second viewer, is not possible. Casting is an interesting problem and I think devices should set single-viewer to false if there is casting (possibly) happening |
I do see there might be reasons to add a media type for mixed-reality environments, as authors might want to style text and image content differently based on whether or not there is environmental pass-through happening. I also think things like |
I was just reading about Sec-CH-UA-Form-Factor, and thought of this issue as being in the similar space. Maybe we can take inspiration from the naming there |
One key question about devices with virtual headset displays is, in what ways would an author need to adapt their website to accommodate, and do we have media queries for that?
We have
hover
,pointer
, andenvironment-blending
, which address many of the adjustments that might be necessary...But another one of the functional differences between physical displays and virtual displays is that they're only visible to the user's eyes: nobody else can look over, and also neither can they e.g. take a photo of the screen or read a QR code displayed on the screen with some other device, which is something an app might need to query for.
Question to the CSSWG is: should we add a media query for this device limitation, and if so, what should it be called?
The text was updated successfully, but these errors were encountered: