- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Apr 2020 23:56:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Proposing new CSS primitives to enable great web experiences on foldable & dual-screen devices`. <details><summary>The full IRC log of that discussion</summary> <astearns> topic: Proposing new CSS primitives to enable great web experiences on foldable & dual-screen devices<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4736<br> <AmeliaBR> ScribeNick: AmeliaBR<br> <AmeliaBR> dlibby: A few months ago, we wrote up initial thinking on this project space. Specifically, foldables with 2 identical screens. We've had a lot of feedback, a lot about more exotic form factors or possible application to desktop multi-screen.<br> <AmeliaBR> dlibby: (shares slides from explainer) This was the proposal, a new media feature, screen-spanning, with value describing direction, and then environment variables for the dimensions.<br> <AmeliaBR> ... we went back to the drawing board based on feedback. Some detailed comments about how this interacts with bezels and so on, and how can we make it extensible to multiple dividers/folds in different directions. So need more complex environmental variables.<br> <AmeliaBR> fantasai: this slide shows 4 panes, but 3 in the media query. Is that correct?<br> <AmeliaBR> dlibby: yes, though that's open for debate. We're counting the number of folds/divisions, not panes.<br> <AmeliaBR> ... For the environment variable, that means we then have an array-like structure, needs a way to access the nth value. Can't use comma, because that's the fallback. One possibility is a nested function.<br> <smfr> q+<br> <AmeliaBR> fantasai: Or could just use a space separated `env(divider-left 3, <fallback>)`<br> <fremy> @dlibby: also, why not just divider-left-1, divider-left-2, etc...?<br> <Rossen_> q<br> <AmeliaBR> dlibby: We then can start looking at more complicated cases (3 by 2 panes in example). Should there be different names to access horizontal vs vertical, top vs left. Getting a little overwhelming in complexity. Wanted feedback from WG about whether there is a more generic way to describe this.<br> <astearns> ack smfr<br> <AmeliaBR> smfr: I don't really have a mental model of how content is supposed to interact with the different screens. Can you pinch zoom on one screen, or would that zoom the whole display? Or scrolling, doesn't the divider line move relative to the content?<br> <AmeliaBR> dlibby: Our proposal was based on defining things in the “client” coordinate system, doesn't change by scrolling. Zooming, haven't looked at that. Depends on a pinch or layout zoom, whether it changes the geometry in CSS px.<br> <astearns> ack fantasai<br> <AmeliaBR> fantasai: Generally, we say pinch zoom shouldn't change geometry, don't re-compute layout. But layout zoom would require computing everything.<br> <AmeliaBR> ... on the slide, you're calling this 1,2,3,4 dividers for the top row and then the bottom row. That's really confusing to number in this wrapping fashion. I'd try to name more like grid dividers, assuming continuous columns, maybe taking the widest gap if they're not all the same.<br> <AmeliaBR> plinss: I agree that number seems weird, but in multi-monitors, they're not necessarily be in a grid layout. We can't assume something simple if we want to include that.<br> <AmeliaBR> florian: And desktop screens are often different sizes.<br> <AmeliaBR> plinss: and that will probably be true in future for foldable mobile devices.<br> <AmeliaBR> dlibby: Yes, we're trying to define in a generic way that doesn't make geometry assumptions.<br> <AmeliaBR> fantasai: But at a certain point, what are the chances that you're going to make a design for arbitrary inconsistent sizes of panels? Can we start with a simple assumption of a grid-like layout. The original proposal was for just a single fold.<br> <AmeliaBR> plinss: But we should at least consider whether more complex is possible.<br> <AmeliaBR> fantasai: So long as simple cases stay simple.<br> <AmeliaBR> dlibby: Agree with that. Kind of hard at this point in time to imagine all application use cases and all devices in the future.<br> <fantasai> extending to multi-fold from single fold wasn't hard, so worth doing; extending to arbitrary geometry in space, it's harder, so I wouldn't be opposed if there was a proposal that handle complex cases but still kept simple cases simple, but don't want us to get stuck on trying to solve arbitrary geometry and make simple cases hard or impossible for the next 5 yrs<br> <AmeliaBR> astearns: Like with custom origins and masonry, it would be helpful if specific questions are split out into separate issues. Right now we have a giant discussion. As these questions come up, please make separate issues.<br> <AmeliaBR> dlibby: Agreed. Main goal for this f2f is to ensure we're on the right track.<br> <AmeliaBR> astearns: On that note, any other concerns that came up from the presentation?<br> <fantasai> +1 to florian, that's important consideration<br> <AmeliaBR> florian: I'm slightly concerned about how this media query will be used & is it the best approach to the problem. E.g., can you make your grid just nicely snap to the folds, without needing to calculate all the environment variables, margins, and so on.<br> <fantasai> s/so on/so on of ancestors and previous siblings and cousins/<br> <AmeliaBR> Rossen_: Snapping to the gaps is definite a use case, but we have so many different layout contexts, and we already have ways to make those sizings. Yes it uses calc. But if tomorrow we change grid, we don't want to need to retrofit a lot of magic. Trying to keep it simple rather than baking in interactions with all layout models.<br> <tantek> Curious about relation to "multi screen" work if any<br> <AmeliaBR> fantasai: I do think that florian's point is really important. We don't want people to need to calculate many layers of margin and padding to figure out where they are on the screen.<br> <AmeliaBR> Rossen_: I disagree.<br> <AmeliaBR> dlibby: There's certainly things we can look at, but I do think this proposal covers the basic primitives to start to get developers exploring things. Integrating with special layout modes could be revisited.<br> <Rossen_> q<br> <AmeliaBR> fantasai: One thing to look at is re-using fragmentation module to avoid breaks. That's what fragmentation is designed to address.<br> <AmeliaBR> astearns: Most examples I've seen treat different screens differently, two or more separate layouts. Not fragmenting content across screens.<br> <AmeliaBR> Rossen_: And fragmentation is one-dimensional.<br> <tantek> In particular I'm curious about possible overlap with https://www.w3.org/2014/secondscreen/ specs and thoughts<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4736#issuecomment-622180570 using your GitHub account
Received on Thursday, 30 April 2020 23:56:15 UTC