#472: Foldables CSS
Discussions
Discussed
Feb 17, 2020 (See Github)
Peter: looks like a bunch of discussion on that one.
David: I think mostly Rossen and Dan.
Peter: I also want it to cover things like desktops and multiple monitors.
Hadley: If that's the case, does the name need to change?
David: I think some (Dan, Rossen?) didn't want this to be multi-monitor.
Ken: I also had that position: multi-monitor is very generic. Monitor positions can be arbitrary. Google had 2 proposals for finance use cases: window enumeration API. This is really for things that are connected with a possible seam with no display. This should be as simple as possible for existing content, treated as one viewport. I think that's the right approach. Treating this as different screens you'll get few developers optimizing app for those use cases.
Peter: I'm not saying different screens in the sense of multiple viewports.
Kenneth: Approach here is one viewport.
Peter: I know people with multiple monitors that are still one viewport, a window dragged across, with some gaps in the middle.
Kenneth: I think that's a minority use case. Even if you create the API that could work with these cases, developers won't test on those cases, it will break on other devices. All thees other configurations that people would have to test as well.
Peter: Also half a dozen configurations of foldable screens and people won't test on those either. Microsoft has an emulator. Mac historically had UI where you can tell OS what monitor configuration is.
Kenneth: I'm worried this would make API much more complex. At least API should be designed so it wouldn't break if configuration is a bit nonstandard... opt in to supporting an unusual configuration, e.g., with media queries.
Peter: Certain things like aligning grid column widths or row to these screen gaps.
Peter: The future heading to foldable screens. Microsoft heading short term solution with a physical hinge because foldable screens aren't there yet; I think that's a stopgap measure that won't be there in 3-5 years. Or foldable screens will fall out of fashion entirely. Multi-screen desktop has been around for use, more likely to be around longer in the future.
Kenneth: More likely tablet/laptop than phones, but support phones too.
Peter: I've seen laptops with 3 screens that fold out.
Kenneth: Intel has done it, a lot of different prototypes.
Kenneth: I think Microsoft hinge way will stay for a while; issues with foldable screens.
Kenneth: I think API should definitely work whether a visible hinge or not -- should work with both cases. I'm told this does. Dan has other point that even if you have screen above the fold, still want to know where the fold is, reflection and animations etc. Maybe a different environment variable similar to the other one. Still fine if you have ideas to make this more generic, but don't want to make it too complicated for the simple cases.
Peter: I saw yesterday video made with a foldable flip phone. When they folded the phone it stopped crossing the ???. So adapted when the angle of the hinge change.
Kenneth: I hope Dan can bring Samsung devices to face-to-face
Discussed
Feb 17, 2020 (See Github)
Rossen: the proposal came around a month ago - a response to new devices announced last year - by Microsoft and before that by Samsung. Idea is to have capability to decide if something spans multiple screens (1) and then - if it does where is the hinge? The API has a number of iterations - final one they came up with in MS is that it provides a media query. One discussion that came is - address second screen or multiple screen. Yes we can extend for multiple screens... ... not sufficient use cases... in windows we introduce APIs that can give you an idea of where the hinges are... bottom line the current proposal doesn't preclude multiple / second screen scenarios... CSS group favourable to it...
Ken: i think it's fine ...
Dan: some Samsung stuff.. around folding continuous screens vs separate screens...
Rossen: triggering animations with environment variable that changes... position of the fold could trigger animations... Multiple different scenarios - where the hinge is - would grow... we have scenarios where you have a super bar ... (area that is used for something else - e.g. buttons). Very aligned...
Ken: on the Samsung phone you still have a display on the hinge..¢.
Rossen: on our devices the hinge is physical but we also have software that extends the area where the app thinks the hinge is...
Kenneth: i think this is the right approach - right direction in my opinion...
[discussion on angle]
Ken: wouldn't angle be a separate API?
Rossen: there could be many folds by the way... not just one.
Dan: there is at least one out there with 2 folds...
Rossen: many prototypes out there...
Comment by @kenchris Feb 18, 2020 (See Github)
Feedback from CSS WG: https://github.com/w3c/csswg-drafts/issues/4736
Comment by @kenchris Feb 18, 2020 (See Github)
We (me and co-worker) have played around with this and it works quite well we think:
https://darktears.github.io/foldable-device-configurator/demo/
Comment by @diekus-zz Feb 24, 2020 (See Github)
I'm still concern over the wording "root viewport spans multiple displays". That does not comply with devices that use one single screen. I would feel a lot more comfortable (and feel it's a lot more future proofed) if this is implemented around the idea of a 'hinge' instead of a display. That way it can include all sorts of folding devices. The physical implementation of the device can then be abstracted around the idea of the folding feature of the device. A window can span across screens, yes, but technically it's spanning across the hinge as a common denominator between the Surface Duo and the Galaxy Fold for example.
Comment by @hober Mar 2, 2020 (See Github)
In the explainer, it says (emphasis mine)
iframes where
screen-spanning
feature policy is enabled will receive values in the client coordinates of the top most window, and it's possible the iframe won't be able to interpret that data without other information from its embedder. As an example, for cross origin iframes, the iframe's embedder must provide information about how to transform from the root client coordinate space to the iframe's client coordinate space, as this information is not available to cross-origin iframes for security reasons.
Why expose the screen spanning information to the iframe at all, if the values can't be used reliably?
Comment by @kenchris Mar 2, 2020 (See Github)
Thanks for filing this, we are happy to see that there are active discussions in the CSSWG and will wait to see how that turns out.
We are proposing to close this issue for now.
Comment by @zouhir Mar 6, 2020 (See Github)
really good question, @hober.
We noticed there are some existing web apps designed with the whole app as an iframe, taking 100% of the browser viewport. We emphasize with the architectural / technical decision web developers have to make and we worked with those customers who are keen to utilize the newly proposed web APIs to provide enhanced UIs for foldable & dual-screen devices.
We found out that the best path forward was to not look at heuristics to enable it for some iframes and also to not disable it completely. Instead, having it off by default and giving the control over its availability to the parent frame developer who knows best about the child iframe behavior and geometry sounded like a good balance.
We are happy to share more in-depth details with TAG, we also welcome suggestions & ideas.
if @kenchris wants to close this for now, happy to continue the iframe discussion @ https://github.com/MicrosoftEdge/MSEdgeExplainers
Comment by @kenchris May 28, 2020 (See Github)
@hober and I took a look at this during our TAG F2F this week and your answer sounds sensible to us, so let's go ahead and close this. Thanks for flying TAG.
OpenedFeb 7, 2020
Hello TAG!
I'm requesting a TAG review of CSS primitives for dual screen layouts.
In order to enable web developers to build layouts that are optimized for foldable experiences declaratively using CSS, we must consider fundamental assumptions of CSS (i.e. a single contiguous rectangular space for laying out content) and introduce new primitives that -together with existing layout media queries- allow developers to create layouts that react to states where the root viewport spans multiple displays.
Further details:
Note that the current explainer contains two different APIs - this TAG review is for the CSS portion. The explainer has both API surfaces mainly to reduce confusion and duplication of the introductory content (the APIs expose the very similar concepts, but in different forms). If preferable, we can split these out. We're in the very early stages, so major changes would not be unexpected, based on feedback from the CSSWG and other developers.
We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify [github usernames]