Skip to content

[RFC] Change spanning media feature #235

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

Open
zouhir opened this issue Mar 17, 2020 · 6 comments
Open

[RFC] Change spanning media feature #235

zouhir opened this issue Mar 17, 2020 · 6 comments
Assignees

Comments

@zouhir
Copy link
Contributor

zouhir commented Mar 17, 2020

We originally proposed spanning media feature with a set of a string-type values representing the hardware configuration (single-fold-vertical, single-fold-horizontal), and our idea for the future was to create new string values representing the screen topologies of that new hardware.

Frame 31 (1)

We believe the folks on this CSSWG thread w3c/csswg-drafts#4736 have provided great suggestions that we are now strongly considering as alternatives to the currently proposed spanning media feature.

@fantasai has proposed:

display-span-x: <integer[1,inf]>
display-span-y: <integer[1,inf]>

@Crissov sort-of similarly proposed:

segmentation-x or horizontal-segments
segmentation-y or vertical-segments

Why do we like the above proposal?

What @fantasai has specified above makes the media-feature self-explanatory and follows a clear and deterministic convention, this increases the ergonomics of the API and helps developers to easily reason about the configuration they are willing to target, rather than keep having to look up the spec to understand what a dictionary of values actually maps to what hardware.

To discuss

  • any objections on moving forward with @fantasai's suggestion? more specifically, towards 2 separate media feature for horizontal and vertical display regions (logical or physical) and the values are of type integer

  • do you feel the phrase display-span-x and display-span-y naturally covers devices with no separate physical displays such as Samsung's and Motorola's foldable devices?
    Frame 32 (1)

  • other feedback items regarding this topic?

@chris480
Copy link

I agree with display-span as mentioned above.

  1. One concern is what kind of values are used. I feel like display: grid styling system can be extended to foldables, or non-conforming displays. So something along the lines of fractional unit value grid uses might be ideal.

How would the proposed system handle a tri-fold display or a partial folding display? For tri-fold that would be the equivalent of 1fr 2fr 1fr grid

In my mind display-span-x and display-span-y would be similar to grid-template-columns and grid-template-rows

  1. I do feel the display-spans do cover folding displays like Samsung's and Motoral's if there a media query for seamed vs seamless display

@jspurlin
Copy link

jspurlin commented Mar 30, 2020

I like the "specifying the number of segments" proposal so that this is futureproofed.

I don't really have a big preference on the naming convention, although horizontal/vertical feels more natural than x/y (which feels a little less clear to me and might cause confusion for developers).

@davatron5000
Copy link

Hey, I've been mulling this around. In general I like the spanning queries the way they are, but display-span-x|y: <integer> is fine as well.

The potential future for asymmetrical displays bends my understanding a bit from an authoring standpoint. Because a display-span-x: 3 device could be a myriad of dimensions: 1fr 2fr 1fr or maybe it's 2fr 1fr 3fr. It's hard to make a UI that would adapt content to all those scenarios. Take for instance the LG twisting phone:

LG twisting display where top screen is a wide rectangle and bottom screen is a squarish portrait

The bottom display-span-y screen would share none of the qualities (height/width) and the top screen. Would a device like this be in scope?

@chris480
Copy link

Hey, I've been mulling this around. In general I like the spanning queries the way they are, but display-span-x|y: <integer> is fine as well.

The potential future for asymmetrical displays bends my understanding a bit from an authoring standpoint. Because a display-span-x: 3 device could be a myriad of dimensions: 1fr 2fr 1fr or maybe it's 2fr 1fr 3fr. It's hard to make a UI that would adapt content to all those scenarios. Take for instance the LG twisting phone:

The bottom display-span-y screen would share none of the qualities (height/width) and the top screen. Would a device like this be in scope?

https://github.com/w3c/screen-fold/issues/37

Someone correct here, but I'm not sure there is a good notion of paging. This would be important to having screens like the LG Wing, where in their demos show specific content on one screen, and a separate content on the other. eg. Youtube video and comments.

I don't think the current css folding proposals adequately address a way for developers to say on "Screen A move this section container here. Screen B everything else"

Even if we don't do have dedicated screen A | B notion, which screen takes priority in terms of view port. Again with the LG wing. If I'm in wing mode, and on a browser. Does the top screen width take precedent, or the narrower screen?

@luxzg
Copy link

luxzg commented Sep 14, 2020

While current discussion (and blog posts) focus on mobile devices, in this case mostly new smartphones, I'd like to remind devs that we have other multi-display devices as well. Eg, simply - PC. You already have the 3x1 and 3x2 shema relatively widely in use, not to mention 5x1 and all variations. Likewise, in same scenario you already have different sizes and resolutions on those displays. While I know in most usage cases it is mobile phones (and similar) that will have comparably huge numbers vs similar PC / desktop devices, but there are already existing usage cases for PC as well. Be it seller/client display in POS environment, monitoring displays, video chats, presentation apps, etc. Lots of traditional software is going web, and handling multiple displays on multi-display desktops would enable more (mostly professional facing) apps to take the route eventually.

So, yes, please go with something in 1-N direction for this feature. And it would be forward thinking to enable the "primary display" descriptor as well. Not sure how these new Android devices handle that, but we know Windows OS has this information.

In short: fantasai proposal seems ok, maybe modified to be (or have alias for) display-span-horizontal / vertical, add display-span-primary, and make sure it works natively on Windows desktop browsers, so you don't need emulators, just stretch browser window across all your displays.

@jasongaylord
Copy link

jasongaylord commented Sep 21, 2020

@chris480

I don't think the current css folding proposals adequately address a way for developers to say on "Screen A move this section container here. Screen B everything else"

I think there is by using getWindowSegments. I'd assume there's some sort of listener to be able to show when segment 2 is now available.

Feedback on the "To discuss" items above:

  1. Yes I think the proposal by @fantasai makes sense.
  2. I'd hope that the browsers on the bendable screens would report multiple segments as in some cases I'd like to treat the singular screen as 100% and in others as 2 separate screens.
  3. Devices like the LG Wing offer a deeper discussion into sizing screens especially orientation concerns.

Also, while we are in the MS Edge repo, can someone please confirm that these changes won't be made for MS Edge only and that they will be PRs on Chromium and official with W3C for support?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants