- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Jul 2018 04:52:34 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Full-screen insets`.
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: Full-screen insets<br>
<dbaron> https://drafts.csswg.org/css-env-1/#safe-area-insets<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2871<br>
<dbaron> (that URL was for the previous topic)<br>
<fantasai> dino draws a fullscreen video player<br>
<fantasai> There's a title in the top left corner<br>
<fantasai> there's controls along the bottom<br>
<fantasai> dino: Works fine on a desktop machien because everyone knows you can get out with escape or whatever<br>
<fantasai> dbaron: But touch interface doens't have escape key<br>
<fantasai> dino: So we need to provide some UI for escaping<br>
<fantasai> dino: e.g. an X in the top left corner<br>
<fantasai> dino: Fades away if you haven't touched the screen much lately<br>
<fantasai> dino: Trying to come up with avriables to take the page where it can draw content when the browser UI is available<br>
<fantasai> florian: We kindof alked about that when we were doing round display, with different approach<br>
<fantasai> florian: MQ with coordinate, if I put something there, will it be visible?<br>
<fantasai> florian: Rather than browser trying to prove geometry, can just ask "can I put the box there"?<br>
<fantasai> myles: Why would you want to binary search for an available space? seems awful<br>
<fantasai> dino writes an example<br>
<fantasai> title { pos: abs; top: env(fs-inset-top);<br>
<fantasai> dino: Can even say title { transition: top 1s; }<br>
<fantasai> dino: then the title shifts as the browser UI desappears and appears<br>
<fantasai> dino: While we specify top/left/bottom/right<br>
<fantasai> dino: top effectively reserves the entire top<br>
<fantasai> dino: We might do {various things } in this area<br>
<fantasai> dino: In safe mode, would also have put the left side offset, but we decided to just do the top<br>
<fantasai> ...<br>
<fantasai> astearns: ...<br>
<fantasai> dino: The issue is that we did that for awhile, and it looks weird if the title is not at the top. Looks lik they've got a weird design<br>
<astearns> s/.../so the space taken up by the browser UI is only known when the UI is showing/<br>
<fantasai> dino: Other issue I link to, because we fade out the X, it's a good example where YouTube fades out their UI as well<br>
<fantasai> dino: Might want to expose timers on our fading so they can synchronize<br>
<fantasai> heycam: Maybe use events rather than time?<br>
<fantasai> dino: Events makes more sense, usually we're responding to those in JS anyway<br>
<fantasai> heycam: ...<br>
<fantasai> dino: We'd also have to publish and make sure everyone's listening to the same events<br>
<fantasai> dino: That's basically the two proposals. Happy for any suggestions or comments<br>
<fantasai> florian: What we started with seemed nice and simple<br>
<heycam> s/.../also you don't know when exactly to start counting those seconds/<br>
<fantasai> florian: but semes like maye they're overly simplified, and as you get into more complicated situations we keep having to add mroe and more tricks<br>
<dbaron> s/dbaron:/?:/<br>
<fantasai> dino: It's veyr specific to our design, but we want to have something that works for others as well.<br>
<fantasai> florian draws a dashboard display and asks about how far are we going to go<br>
<fantasai> dino: safe-area-* is about hardward shapes. fs-inset is about on-screen displays<br>
<fantasai> florian: ...<br>
<fantasai> myles: System with arbitrary shapes would be so difficult to use that no developer would do it<br>
<astearns> s/hardward/hardware/<br>
<fantasai> Rossen: Similar to this, we had a value called device-fixed<br>
<fantasai> Rossen: Worked exactly you describe,<br>
<fantasai> Rossen: When onscreen keyboard came in, didn't want to resize the entire window<br>
<fantasai> Rossen: But i fyou wanted to attach UI on top of the keyboard, e.g.<br>
<fantasai> Rossen: Insteadd of positoin: fixed<br>
<fantasai> Rossen: You'd do position: device-fixed<br>
<fantasai> Rossen: And it would adjust<br>
<fantasai> Rossen: You won't have to resynch or compute any numeric values like top/bottom etc.<br>
<astearns> s/?:/dino:/<br>
<fantasai> dino: You wouldn't be able to animate<br>
<fantasai> Rossen: That would be done for you<br>
<fantasai> Rossen: Basically saying that the device now is going up<br>
<fantasai> Rossen: on-screen keyboard is cming up<br>
<fantasai> Rossen: If this UI was important for YouTupe, they'd simply position this as device-fixed<br>
<fantasai> Rossen: And then this simply becomes bottom: 0;<br>
<fantasai> Rossen: And they don't need to do anything else<br>
<fantasai> Rossen: They don't even know, it's still the same thing<br>
<fantasai> florian: If you are sizing things, would that affect viewort units?<br>
<fantasai> Rossen: This is ovekill<br>
<fantasai> Rossen: Another example put forward was if you have, suppose some vertical sidebar<br>
<fantasai> Rossen: Same thing, a bit more work for us, but if you have positioned top and obttom it would respond<br>
<fantasai> Rossen: From what I know, it was very successful because very simple<br>
<fantasai> Rossen: position: fixed vs position: device-fixed<br>
<heycam> fantasai: why isn't position:fixed have the behavior of device-fied?<br>
<fantasai> Rossen: We weren't actually resizing the viewport, it was an overlay UI<br>
<fantasai> Rossen: e.g. keyboard uses semitranslucent colors<br>
<heycam> fantasai: but what if you want to clearly see the content at the bottom of the page?<br>
<heycam> Rossen: just dismiss the keyboard<br>
<fantasai> fantasai: What if you need to type into a form field at the bottom of the page?<br>
<fantasai> frremy: Then you can dock your keyboard.<br>
<fantasai> dino: Do you still support device-fixed?<br>
<fantasai> Rossen: yes<br>
<fantasai> Rossen: We were doing this for action center, which is something that swipes from the right<br>
<fantasai> Rossen: If you have some UI that's really important to your app<br>
<fantasai> Rossen: you can attach it<br>
<fantasai> myles: Does it work if the window is not full screen?<br>
<fantasai> Rossen: No, this is only for full-screen<br>
<fantasai> iank_: What is the box?<br>
<fantasai> dino: In our case the device-fixed box would be what remains after the inset here.<br>
<fantasai> iank_: But it wouldn't solve this use case?<br>
<fantasai> dino: It would, but ti wouldn't solve use case of wanting ot fade all controls at once<br>
<fantasai> iank_: What aobut tile shifting to the right?<br>
<fantasai> dino: We'r ereserving the right ot put more things up there<br>
<fantasai> dino: Would be up to browser to animate the the device-fixed box.<br>
<fantasai> myles: Animation is different<br>
<fantasai> myles: we want the animation to fade out<br>
<fantasai> myles: whereas you want it to slide out<br>
<fantasai> Rossen: You can fade out the keyboard or slide it?<br>
<fantasai> myles: How does the page know to fade out or side out things?<br>
<fantasai> dino: Say youtube uses a 3s fade, and we use a 4s fade.<br>
<fantasai> dino: Wnat to tell youtube to use 4s if it wants to be in sync<br>
<fantasai> fantasai: In Apple's case, could just use the transition time value in the 'transition' property<br>
<fantasai> Rossen: Reason we wanted it done in browser was because syncing timers was not working<br>
<fantasai> astearns: weirdly shaped things will need to use a lot of environment variables<br>
<fantasai> dino: OK, we'll take back this feedback<br>
<fantasai> fantasai: Also, you might want to consider s/fullscreen/overlay in the names... it's not really about the fullscreening<br>
<fantasai> Rossen: If we are looking to solve the tying of author-defined controls with UA controls animation<br>
<fantasai> Rossen: You can have a start and an end event<br>
<fantasai> Rossen: Just also need to know how long between the two<br>
<fantasai> myles: Could be part of the start event<br>
<fantasai> astearns: Maybe you only need one set of environment variables<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2871#issuecomment-402362512 using your GitHub account
Received on Wednesday, 4 July 2018 04:53:41 UTC