- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 19 Oct 2020 21:57:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``Updating the css `env()` function to enable selection by index from a list of pre-defined environment variables``, and agreed to the following: * `RESOLVED: Develop a list and matrix version of variable references so that we can pull various pieces of an env() out, and the syntax we choose for these variables should match the MQ for it` <details><summary>The full IRC log of that discussion</summary> <myles> Topic: Updating the css `env()` function to enable selection by index from a list of pre-defined environment variables<br> <myles> GitHub: https://github.com/w3c/csswg-drafts/issues/5622<br> <myles> dlibby: A continuation of the previous discussion. Targetting dual-screen devices. Creating primitives that are more extensible to target desktops or future devices. That could be better than the original proposal. Previously we described where a fold might exist in yoru viewport, but this changes to describe segments of your viewport and their dimensions. It's probably 2 issues: 1. Whether this set of env variables makes sense, and 2. the right way<br> <myles> to represent it syntactically. TabAtkins replies about 2. Focusing on the env variables themselves... these would be in visual viewport coordinate system. Targetting the top level layout constructs.<br> <myles> dlibby: We have not yet heard use cases for integrating into the various layout submodules.<br> <fremy> q+ (after Tab gets an opportunity to reply)<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <TabAtkins> q+<br> <fremy> q+<br> <myles> dlibby: the ordering in the proposal for this issue is a row major order with a single index. Maybe there will be some discussion about whether that should be a 2-d index. -> Syntax question about whether env variables should be specified up front about the ones that are represented by the UA, or if an open-ended set of variables is sufficient for that spec.<br> <myles> dlibby: Our goal is to get something into the WD for css-env. But feedback on the concept / makes sense/ etc. would be appreciated.<br> <astearns> ack TabAtkins<br> <heycam> q+<br> <myles> TabAtkins: On the syntax question, the original proposal has an index(var name, integer) and represents an indexed variable name there. We don't' need a function, if we want a list or matrix value env variables, we can build them into the name like name-1 or name-2 but if we want to make them separable, which is reasonable, we can't target a particular screen if it's built into the ident, we can add 1 or more integers into the main argumetn part of<br> <myles> the [missed]<br> <fantasai> +1 to Tab<br> <myles> TabAtkins: I'm happy to add in 1+ integers after the variable name, that makes sense.<br> <fantasai> s/[missed]/env() function/<br> <astearns> ack fremy<br> <myles> fremy: That mostly covers the thing I was going to say.<br> <bkardell_> q+<br> <myles> fremy: One little thing: when I looked at this, one of the things you can do if you have a way of separating the numbers and the value is you can have the number be a variable. You cannot have the name of a variable be a variable. There can be use cases for that.<br> <myles> fremy: Why limit ourselves to integers?<br> <myles> fremy: Right now, the syntax for variable is [ident comma fallback]. What if instead we allowed the ident to be a list of identifiers or numbers, and then concatenate them. Then we could use variables in the name of variables, which would be cool. You could have a structure, like main color, secondary color, and then prefix them with the name of a theme, like dark-maincolor or light-maincolor, and use a variable to select which theme you're using on<br> <myles> an element.<br> <myles> fremy: Like what TabAtkins said, we don't need a function, but we can put any arbitrary ident there.<br> <myles> myles: Floating point values makes that tricky<br> <myles> TabAtkins: it would be ident | int<br> <astearns> ack heycam<br> <myles> heycam: In the proposal, there's talk of 2d screen setup. Will this work with non-mobile device situations? 2d arrangements of monitors is usually for desktop machine.<br> <astearns> ack bkardell_<br> <myles> <dlibby's connection is broken, he can't answer><br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask about viewport vs display<br> <astearns> q+ bkardell_<br> <bkardell_> q-<br> <myles> fantasai: 2 questions: 1. Are we distinguishing between viewport and physical display, is env() returning the value for the viewport (if you move a window on the display) how does that effect the env()<br> <myles> fantasai: 2. Do we want to linearize the list? Or do we want to assume a gridded layout and have a matrix w/ 2 indices, one for each axis<br> <myles> astearns: If we decide to use a list syntax now, can we extend that to accommodate a matrix syntax?<br> <myles> fantasai: It depends on what exactly we decide to do. A linear form is ... the syntax would have different needs depending on what you wanted to do. It's interesting how exactly the syntax work and how it relates to the MQ and how it relates to each other and other things in CSS. It's important that we think of these two features together. The MQ + the env()<br> <myles> <dlibby is back><br> <myles> fantasai: 2 questions: 1. Are we distinguishing between viewport and physical display, is env() returning the value for the viewport (if you move a window on the display) how does that effect the env()<br> <myles> dlibby: We are querying the viewport in relation to the physical/logical display regions.<br> <myles> fantasai: That needs to be clear in the name.<br> <myles> fantasai: and in the spec also.<br> <myles> fantasai: With the MQ we were talking about going toward a matrix form, where you've got rows and columns. For the env(), would we want to do that here also? Or a linearized version here for some reason? Both?<br> <tantek> This sounds like pagination but for different shaped pages that are displays<br> <myles> dlibby: Perhaps having both would be useful, but the hesitation with the matrix is just for the set of hardware we know about currently, that extra metal load of the matrix-like syntax seems a difficulty for authors to get over. If there's consensus that having that consistency with the MQ.... We're amenable to having it for the syntax as well.<br> <tantek> Also curious if this is meant to model complex non-rectangular amalgams of displays like adjacent Times Square video screens<br> <myles> fantasai: It would be good if the MQ + the env() would have consistent syntax. If we need the linear version for some reason, then maybe we can look into that. But we should aim for consistency<br> <myles> dlibby: Okay, we can take a look.<br> <myles> heycam: In the proposal, there's talk of 2d screen setup. Will this work with non-mobile device situations? 2d arrangements of monitors is usually for desktop machine.<br> <astearns> q?<br> <smfr> q+<br> <myles> dlibby: One thing we've been referring to is a semantic mode from the window manager. If there would be a desktop OS that supports an app window going into a configuration where it has a rectangular viewport that is spanning some number of screens, we would want it to apply. But if you're moving your window between displays and happen to let go of your mouse where a few pixels are bleeding into another monitor, that doesn't feel right for the<br> <myles> semantics of this.<br> <fantasai> window manager should be snapping that, probably<br> <myles> heycam: It seems like you would want to know the spatial arrangement of these displays. Even in a simple situation of two halves, if they are arranged vertically or horizontally, that would change how you woudl use the env() vars. Maybe we want the matrix syntax.<br> <myles> dlibby: Yes, it's important, and part of a separate issue related to the media issue that fantasai alluded to earlier. The proposal: Two media features, one in X direction and one in Y direction about how many you have in a certain axis.<br> <myles> dlibby: As newer form factors come into existence, they can fit into that<br> <myles> heycam: The author would have a MQ to select on arrangement, then within that, env() to index within that<br> <myles> dlibby: Yes. fantasai is right that we want consistency<br> <astearns> ack smfr<br> <myles> smfr: I have a hard time evaluating these proposals b/c I don't understand the model w/r/t scrolling + zooming. When you scroll, do both screens move up and down at the same time? Is the right side showing the bottom of the left side down? Or can we do multicol thing where scrolling is <hand waves><br> <myles> smfr: Or does the whole thing scroll as once? If you zoom, where is the origin? Is it all one big thing? I would like to see animated images how scrolling + zooming works.<br> <myles> dlibby: Okay. We can put that together. By default you have a single rectangular viewport / ICB which is the size of the rectangle, spanned across both screens. If you don't do anything special, the entire thing will scroll. The site could use the primitives that independently scroll themselves with overflow-scroll. We don't want these values to change on zoom. Similar principle on zoom - shouldn't change, like safe-area-inset. We don't want<br> <myles> relayouts on every zoom frame. To the exten that we can match that existing behavior we think that's a good model for these env() vars<br> <myles> smfr: I think it would be useful if your examples started with a simple case that didn't have a scrollable left column, and then add in teh scrollable left column wehre it makes sense to map things on to two screens.<br> <myles> smfr: Like a page with no columns. Wikipedia.<br> <myles> dlibby: At the bottom there's an example of an outlook application.<br> <myles> dlibby: Where it just flows across that seam or fold, across the 2 displays. It would scroll as if your viewport was just that size. This is about letting people customize that w/r/t the viewport.<br> <myles> smfr: I think that's fine.<br> <myles> astearns: I read through the proposals a few times. There's lots of layout described. Different kinds of layout across / separately. But to smfr's point, there isn't the extra stuff that he's asking for in terms of scrolling / zooming / other actions across both screens / independently. But it's a separate issue. smfr, can you raise a new issue about including more, specific examples?<br> <myles> smfr: Sure.<br> <myles> astearns: proposal: Develop a list and matrix version of variable references so that we can pull various pieces of an env() out, and resolve the syntax we choose for these variables should match the MQ for it<br> <myles> dlibby: That sounds like what i've been hearing?<br> <myles> RESOLVED: Develop a list and matrix version of variable references so that we can pull various pieces of an env() out, and the syntax we choose for these variables should match the MQ for it<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5622#issuecomment-712464916 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 19 October 2020 21:57:19 UTC