- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Feb 2020 01:03:13 +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> <dael> Topic: Proposing new CSS primitives to enable great web experiences on foldable & dual-screen devices<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4736<br> <dael> dlibby-: As maybe you've seen MS has announced 2 new dual screen devices.<br> <dael> dlibby-: Given these are cross variety of platforms and browsers and web would be great. CSS is great for layouts. Been bandying about ways to expose CSS for this so they can control how webcontent is in relation to the hinge.<br> <dael> dlibby-: Had some principles about don't want to expose unnecessary new capabilities. Trying to be cognizent that these devices aren't comprehencive of future. Don't want to shut door on future form factors.<br> <dael> dlibby-: It's a new media feature called 'spanning' Intent is to desc when viewport is spanning several screens. Depends on how viewport is positioned.<br> <dael> dlibby-: Need to understand where gap/hinge is in terms of css coord. Proposed 4 env variables to desc where is the fold, width and height of fold<br> <florian> q+<br> <astearns> ack florian<br> <dael> dlibby-: Excited to hear feedback, if this sounds reasonable, any drawbacks. Definitely open to changing based on collective experience<br> <astearns> q+<br> <dael> florian: Always a challange for a new MQ for new device. Categorizing devices doesn't stand as time passes. I'm happy to see this proposal is trying to test a relevant aspect of what's going on. Means we're on the right path. A little concerned about env variable. When it comes to sizing I think this is likely to overlap the unsolved viewport units conversation and which parts have and don't have scrollbar and keyboard<br> <dael> florian: All the struggle with vh/vw seem to overlap here. I don't have a solution. Proplem space seems reasonable.<br> <dael> dlibby-: Makes sense. Aware of some interaction with things like vch unit to reference visual viewport. I would agree there's rationalization to be had there.<br> <dael> dlibby-: Being desc with viewport units I don't think it sits how we've been thinking about it. Not sure if you're jsut noting tie ins<br> <dael> florian: Similar issue, not nec. units. If you want to size something to 80% after folding, what 80% are you talking about? Probles are same as vh/vw even if not same units.<br> <dael> jensimmons: Question: Haven't thought a lot abotu devices with hinge. Is mental model for anyone designing for screen simply that there's a wider screen with a web window like we've known for years and then suddenly it's magically half as wide and that's it? It jumps wide to narrow and narrow to wide?<br> <dael> jensimmons: Or is it that people think about design of the screen where you have more space then that. WHen you open a browser window it's usually one space and hwen you go wide it goes two up? Are there thing like that?<br> <dael> jensimmons: Is it simply a different way but similar to responsive or is it more complicated whre you have 2 up b/c new screen?<br> <Rossen_> https://user-images.githubusercontent.com/5052316/73715033-8a3e5b00-46c7-11ea-8839-af3801c97502.png<br> <dael> Rossen_: A little of both. Awareness of hinge is important and that's what desc spanning. Spanning is going across hinge in middle. THat allows you to create different experience on that hinge location<br> <dael> Rossen_: If you look at motivational examples in issue they're pretty well thought through. If there's an email app you can do solumns on left for folder, email titles and then right side is full experience with selected message<br> <myles> q+<br> <dael> Rossen_: These are doable but if you don't know where hinge is you have content half on one side and half on the other. That's a simple example. Many others that Zo (sp?) has been working on<br> <dael> Rossen_: Knowing where hinge si is important<br> <heycam> q+<br> <dael> dlibby-: Knowing where hinge is and mapping to it might be useful to developers in many cases<br> <dael> jensimmons: Some of these things we know so far like where is screen aren't issues. THIs is where hinge is.<br> <dael> Rossen_: Right. And this is why we're nto defining viewport, but there's something that splits viewport<br> <fantasai> s/many cases/many cases. Also different OSes treat the gap differently, e.g. some mask content in that area whereas others split the screen apart/<br> <dael> astearns: Is this prop MQ matching cases where phsycial hardware doesn't have hinge. Thinking like a reader view or something like that where might want to layout differently between left and right page. I think ther answer is this MQ is not for a case like kidle to view on content where content flows from one side to another. This is about having a phsycical gap in screen<br> <astearns> ack astearns<br> <florian> q+<br> <astearns> ack myles<br> <dael> Rossen_: I dont think we're insisting on physical paradigm. I can see an epub that uses multiple tabs internally to drive that experience using this css mech. It's something we haven't thought about. Good to consider<br> <dael> myles: It's clear there are use cases for one browser window to span both halves. I've also seen use cases like in explainer with google maps where one half has map and other is locations. For one big browser window we can do that today. 2 panes could be solved with preso API<br> <plinss> q+<br> <dael> myles: Your prop is more powerful b/c allows mix both these. Some content aligns to fold and other span both. I haven't seen cases for this mix. Can you desc one?<br> <dael> dlibby-: I think you said there's single window paradime and you split content. THe other where you lean on preso API to open another full window. Correct?<br> <dael> myles: What type of content are you encouraging web designers to create with this API. Because with no API web designers could create for this. Presentaion API would encourage 2 different independent. You haven't proposed either of those types. You're proposing a 3rd type that doesn't fall into first two buckets. What type of content are you encouraging that's not in those buckets?<br> <dael> astearns: Specifically a mixed mode were some content is split but other content spans both?<br> <dael> Rossen_: Let's consider a mail app with an application bar that spans both screens and then left and right sections for the two screens<br> <dael> myles: Yeah, I think that answers. A nav bar that spans across the fold.<br> <astearns> ack heycam<br> <dael> heycam: A little unclear to me if the model here is the window that spans the two displays. Does it have a strip of pixels which are not rendered because they overlap the folder or is the back buffer for the window is split? Or both?<br> <dael> dlibby-: Accomodate both. Early MS devices is that they'd have different. One has pixels across the back and the other has a split. In one case your fold-width would be 0 but it's still there<br> <dael> heycam: Understood.<br> <dael> heycam: For UI or content you want to span, the toolbar and you've got buttons you want to avoid the fold space so you don't lose half a button- not sure if there's a great way to use env variable to make them avoid fold if you're using flexbox. I gues syou can fallback to script<br> <dael> Rossen_: What you're saying is exactly what [missed] to avoid having loss of content to avoid having the button fall under the hinge<br> <dael> Rossen_: If you see fold width it essentially describes that space<br> <dael> heycam: I'm imaginging a flexbox container that spans the width. I'm not sure how you use nth env variable to make sure the flex items when you get to fold one doesn't go over fold.<br> <dael> florian: Similar is a 3 column grid where you want 2 and 1 and you don't care which side is the 2 but you don't want a split grid.<br> <dael> ??: First one is a single flexbox with an arbitrary number of buttons with width. You won't know when buttons reach hinge but it'll help you make 2 columns. Request is a single flex and avoid the gaps<br> <dael> heycam: Right. THat might be an example of the more general region flow<br> <astearns> s/??/Zouhir/<br> <dael> Zouhir: The original demos we experimented with we didn't touch on arbitrary number of childrens avoiding hinge. We did make multiple grid and flexbox where we can snap to the fold nicely. It's a good note to take<br> <Rossen_> q?<br> <dael> astearns: Good to add examples of env variables with layout mechanisms<br> <florian> q-<br> <fantasai> It sounds like you really need media queries against the fold offsets<br> <astearns> ack plinss<br> <fantasai> plinss++<br> <Rossen_> +1 to plinss<br> <dael> plinss: Couple points- Lot of work done on folding screens and I'm hesitant to do something in CSS that we'll have to carry around when folding screens might no longer have hinges. However multiple monitors on desktop is comment. Would like to make sure if we solve what we do applies on desktops as well. Food for thought<br> <dael> dlibby-: Good feedback. Have that in the back of our mind but not concrete<br> <dael> Rossen_: We've taken steps to make sure that's not obstructed. But yeah multi-monitor is first that came to discussion<br> <dael> plinss: And there's 4 monitors in a grid where you have vertical and horizontal<br> <dael> astearns: Thanks for the introduction. I'm sure we'll discuss on the issue and again on a call<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-582686731 using your GitHub account
Received on Thursday, 6 February 2020 01:04:16 UTC