Foldables CSS

[dlibby-]

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.

• Explainer¹ (minimally containing user needs and example code): https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Foldables/explainer.md
• Security and Privacy self-review²: [Foldable] CSS - TAG Security and Privacy questionnaire MicrosoftEdge/MSEdgeExplainers#187
• GitHub repo (if you prefer feedback filed there): Feedback can be provided in this Tag Review issue
• Primary contacts (and their relationship to the specification):
  • Daniel Libby, @dlibby-, Microsoft
  • Zouhir Chahoud, @zouhir, Microsoft
• Organization/project driving the design: Microsoft
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/feature/5310356412956672

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the work on this design is being done (or is intended to be done in the future):
  CSSWG
• Existing major pieces of multi-stakeholder review or discussion of this design:
  csswg-drafts issue 4736
• Major unresolved issues with or opposition to this design:
  None at the moment
• This work is being funded by:
  Microsoft

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]

[kenchris]

Feedback from CSS WG: w3c/csswg-drafts#4736

[kenchris]

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/

[diekus-zz]

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.

[hober]

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?

[kenchris]

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.

[zouhir]

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

[kenchris]

@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.