- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 Oct 2020 21:12:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Foldable screens`, and agreed to the following: * `RESOLVED: Adopt the multiscreen MQs into MQ5.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Foldable screens<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/5621<br> <TabAtkins> dlibby_: This is an updated proposal for primitives we'd like to introduce for dual-screen and foldable devices<br> <TabAtkins> dlibby_: This one is a new media feature that describes the number of logical display regions a viewport is spanning across<br> <TabAtkins> dlibby_: Not th edevice itself, the relationship of the viewport to the device regions<br> <TabAtkins> dlibby_: The syntax is in two axises to allow for future form factors to use the same feature<br> <TabAtkins> dlibby_: goes hand-in-hand with the environment vars we discussed yesterday<br> <heycam> q+<br> <TabAtkins> dlibby_: Looking for opinions on this and if it's okay to add to mq5<br> <TabAtkins> q+ myles<br> <florian> q+<br> <myles> q+<br> <Rossen_> ack heycam<br> <TabAtkins> heycam: my initial thoughts about this is whether these features are, don't wanna say complex bc the syntax isn't complex, but wondering if really there will be that many arrangements of displays that we need a feature shaped like this, as opposed to something simpler<br> <TabAtkins> dlibby_: in our original proposal we wer emore scoped, but that came with the baggage that as new form factors appeared, what is the syntax you would use for them?<br> <TabAtkins> dlibby_: So we feel this gives a more futur-eproof model, while allowing author to target today's devices<br> <Rossen_> ack myles<br> <TabAtkins> myles: Sof or width queries, for example, if you say (display-span-x: 3), is that *at least* three screens, or exactly 3?<br> <Rossen_> q?<br> <TabAtkins> dlibby_: Exactly, if you use the : or =. If you use < or > it gives less or more<br> <smfr> q+<br> <TabAtkins> myles: This also suggests authors might have different layouts for each arrangement - a different for 2x1 vs 1x2 vs 2x2, etc. That's the intent?<br> <TabAtkins> dlibby_: Yes.<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to react to myles<br> <TabAtkins> fantasai: The mq would give you an exact number, but becuse it's an integer ti can take min/max prefixes as well, so you can just opt into "2 or more displays"<br> <myles> fantasai: display-span-x: min(2)?<br> <TabAtkins> fantasai: To respond to heycam, the reason I didn't want to do simpler syntax, if someone has a 3-fold device we'd need a new MQ<br> <TabAtkins> (myles, no, (min-display-span-x: 2))<br> <TabAtkins> fantasai: The syntax for this simple case isn't any harder ot use than a more "specialized" one, but it lets us extend to a grid easily<br> <TabAtkins> fantasai: it doesn't let us extend to a non-grid, tho<br> <TabAtkins> fantasai: but i think most of the cases we'll need to worry about will be a grid or simplification of a grid<br> <myles> (TabAtkins: oh! are all number-taking media queries supposed to automatically get min- and max- prefixes?)<br> <TabAtkins> fantasai: So didn't want to box us into a corner<br> <TabAtkins> (yes)<br> <Rossen_> q?<br> <Rossen_> ack florian<br> <TabAtkins> florian: i think this works nicely<br> <TabAtkins> florian: as discussed yesterday, desktops can b emore complex arrangements<br> <TabAtkins> florian: but this isn't just windows that can be slightly offset from each other, it's a special display mode<br> <TabAtkins> florian: And I think a grid is really the only realistic mode to deal with<br> <TabAtkins> florian: [shows off an example]<br> <TabAtkins> florian: So i think we're good<br> <Rossen_> q?<br> <Rossen_> ack smfr<br> <TabAtkins> smfr: Does the asnwer to these mqs depend on which screen the browser is on?<br> <TabAtkins> smfr: From samsung demos, browser can be on left, right, ro spanning both<br> <TabAtkins> smfr: So will these change?<br> <TabAtkins> dlibby_: Yes, if you're only on a single screen, your display-span will be 1<br> <TabAtkins> smfr: So not about the physical device, about the current configuration<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: On that note, think we need some bikeshedding on this - we use "display" to refer to the physical device<br> <TabAtkins> fantasai: so like display-width vs width<br> <TabAtkins> fantasai: and we want consisten wording between env() and MQ<br> <TabAtkins> TabAtkins: note the MQ word is 'device-', not 'display-'<br> <TabAtkins> fantasai: Oh yeah. But the env() is using viewport, so we should be consistent between them<br> <Rossen_> q?<br> <TabAtkins> Rossen_: So any preferences or opinions?<br> <TabAtkins> TabAtkins: No strong opinion on word, but strong opinion towards naming consistency like elika said<br> <astearns> device-arrangement<br> <TabAtkins> florian: 'viewport' isn't great, it's how your viewport spans<br> <TabAtkins> heycam: perhaps something about presentation<br> <TabAtkins> fantasai: if you ahve a normal display it'll ahve a value of 1<br> <TabAtkins> heycam: so i think like 'display-span-x' will sound like it should match if your single window spans across both segments even if it's just acting like a normal window<br> <fantasai> i/heycam/TabAtkins: If your window spans a folded device, is that span 2 or span 1?<br> <TabAtkins> florian: if you're on a device with a seam between screens, then eys absolutely<br> <dholbert> present-<br> <TabAtkins> florian: But on a device with a seamless pane separation, up to the UA to decide which way it goes<br> <TabAtkins> dlibby_: valid point, goes down to what cam was mentioning - if you're in more of a tiled mode that the device is informing the UA about<br> <TabAtkins> dlibby_: So possibility of a seamless device not presenting itself as multipane if you're not doing something<br> <TabAtkins> smfr: some implication of spanning the whole utility area<br> <TabAtkins> smfr: if you span both screens, but half of one screen is filled with a different app, your browser is 1.5 screens wide<br> <TabAtkins> smfr: So without information about what size each pane is...<br> <TabAtkins> TabAtkins: That's what the env() is for, reporting those pane sizes<br> <TabAtkins> Rossen_: So yeah in your example, the shared pane will just have a smaller viewport for the browser in that pane<br> <TabAtkins> florian: so my suggestion is to resolve to adopt it, bikeshed naming in github<br> <TabAtkins> florian: But i think we're agreeing to the proposal overall, maybe need a few details to be clearer<br> <TabAtkins> florian: But not hearing real pushback<br> <Rossen_> q?<br> <myles> q+<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to comment on querying the gap<br> <TabAtkins> fantasai: agree with florian<br> <TabAtkins> fantasai: also might be useful to query info about the gap, how big it is and if there's content missing in the gap - if it doesn't paint or if it just jumps across<br> <TabAtkins> dlibby_: The env variables are designed let you avoid the gap, but perhaps there's a query to make it clearer up front<br> <TabAtkins> myles: are the env() indexed?<br> <TabAtkins> dlibby_: discussed that a bit yesterday, yes they are<br> <TabAtkins> dlibby_: based on discussion, should match the 2d grid indexing<br> <fantasai> The question of whether working on the "explode" model or the "window" model is probably relevant - http://fantasai.inkedblade.net/style/discuss/table-backgrounds/<br> <TabAtkins> Rossen_: So any objections to adopting them into MQ5?<br> <TabAtkins> RESOLVED: Adopt the multiscreen MQs into MQ5.<br> <TabAtkins> <br until=":15"><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5621#issuecomment-713142655 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 20 October 2020 21:12:40 UTC