Rossen: will drill down on this - what does he mean on additional privscy characterics that are not already exposed through viewport or screen API.

Dan: why are there 2 reviews here?

Rossen: one is a subset of the other...

Dan: we've gone through the major bits of the revieww on both and it's been largely positive.. maybe we can shoot to close these at the plenary?

Dan: someone saying it exposes hardware characteristics to the web. They've already discussed that in their responses to the S&P questionnaire. They say it's not meant to solve the problem of foldable devices with more than two screens due to iterating in CSS.

Peter: I have the concern where it's designed for two segments equal size split vertically or horizinatally and that's it

Dan: together with viewport segments the equal size thing.. I don't think it's about equal size..

Peter: this is what's detectable from CSS> The only thing is how many segments do you have. Unless you make presumptions about size and shape of segments it's somewhat useless information. Their example is map view with driving directions. An example in my mind is an email client, a message pane and list of messages - straddling fold I want one on one and one on the other, I don't care where the fold or the edge is.

Dan: that can change depending on what other things are using screen real estate. Not just about where the physical fold is. On our browser you can move the url bar from top to bottom of screen. That changes relatively speaking where the fold shows in the viewport, so you have got to adjust for that to know which is smaller.

Peter: more viewport related units to handle that sort of thing... not well thought out with multiple segments, that's for the entire viewport as a whole. My concern is what you can do with the information they expose, without script or strong presumptions about client and device.

Dan: make sense for you to leave that comment?

Rossen: we thought of signing off on this and moving forward. Then someone added something for security and privacy, we challenged and asked for something in particular. It's been a month since we asked. I'm very happy with the CSS primitives one, but close to it. Don't want bias. Ken was also pretty happy with this. The final thing is that (with CSS bias) CSS WG is favourable to this approach.

Dan: I'm happy with it, also work for a company with devices with folding displays. It's in the correct place. Concern about multiple implementations. No Chrome status link.

Rossen: Weird. https://chromestatus.com/feature/5310356412956672

Dan: I think Samsung is going to implement, that's Chromium

Peter: question - looks like you can use environment variables in media queries?

Rossen: You can, yes

Peter: that was a concern I had, I wanted to make sure you could do media queries based on the size of a segment. Given tahts the case I wonder if the number of segments should just be exposed as an environment variable as well. Utility in having the number of segments as an environment variable, that's a new question

Rossen: what are you intending to do? Focus management?

Peter: is there a use for having that? For consistency does it make sense to have everything exposed as environment variables, then wondered whats the use case for that. Definitely use case for the size/dimensions of the viewport as environment variable, but wondering if there's a use case for the nubmer of segments

Tess: if it's greater than 1 that's a simple test. Maybe I want to refocus the 'primary' on essential information

Peter: you have the media query for that. A high level property that you can query. Does it make sense t have as an environment variable as well so you can use it in other properties?

Rossen: example usage? I'm detecting horizontal viewport segments 2, and I have a bunch of details to layout things properly, query env vars to figure out how big are segments, and do sutff. But I'm already in the context of 2, I know i Have 2. How am I goingto use that information i nthat block?

Peter: not useful in that block. Is itu seful outside of a media query block in some other property?

Tess: if you're doing a calc with a modulus, you might want to .. if you're trying to place something on one of the segments but you're trying to do it in a generic way with any number of segments

Rossen: starting to get a use case in mind.. I'm curious on whether or not this is something that is needed to start with? This is a purely additive feature. You acn express the same thing right now with a variable, doc variable, doesn't have to be environment variable, can set it inside the media query block. Then use it everywhere else. If we detected this as a very popular use case we can drop that into an environment variable at that time.

Peter: I accept that. Thinking that if there's a use case later on and we add an environment variable it would seem weird t have a high level property and an environment variable exposing the same thing. Redundant. If that's the case, if we can predict that, does it make sense to make it all environment variables right now. I don't have a strong argument, just wondering. In any example I think I'd use this feature in a media query I'm 90% sure I'm going to be querying other aspects of the viewport as well. If a segment is very very narrow I maybe dn't want to split my layout into two parts. That can very easily be the case if I have a window not taking full screen and mostly on one segment and partially on another segment. Only 50px on one segment I dont' want to split my layout into 2 halves. If every media queriy is going to include number and an env var about segments maybe let it all be env vars

Rossen: I think what you're describing is probably something that we need to work at with the CSS WG. And we can and should record this as a feedback, here or in a CSS issue. Stepping back, from the pov of TAG and signing off on this review, do we have any reasons to push back? What we're talking about is additional shape considerations that can be worked out by the right people.

Peter: not trying to make that deciision, I agree that CSS WG is the right place. Is there enough agreement in TAG to ask that? Then we leave it as feedback and let CSS WG decide

Tess: It seems like it's not a blocking thing. Definitely something that the CSS WG should think about. Do that via part of our closing comment or filing an issue.

Peter: yep

Rossen: my take as well. Definitely capture it.

Dan: agree to close with a positive comment?

agreed to close positively