Tess: Looked at this in Wellington...

Peter: It was pending feedback, but we got some feedback.

Rossen: seems like they made quite a few updates.

Tess: Certainly seems like all issues were addressed, that's good.

(pausing for further investigation)

Bumped to next week

Ken: They are asking for feedback on 5 things (last comment in issue). Like should we add to existing screen in addition to getScreens() or should we just add the new props to the screen objects returned by getScreens().

Ken: navigator.screen is the main screen. they want to add additional things (beyond what's already defined in CSSOM View). [list of many features] They want getScreens() in addition because you may have more than one; should the new things just be added to the new objects or should they also get added to navigator.screen

Tess: shouldn't they be the same type of Screen object?

Ken: the new things are async, and they want a static snapshot instead of having a live object. Also the current object is sync and permissionless.

Peter: my initial reaction was similar to yours. But now I think navigator.screen is a mistake. We should deprecate it over time. Maybe the new Screen object should have a similar API surface, but be distinct. I think we should pretend navigator.screen doesn't exist and start over.

David: Do all of the things on the existing screen object even make sense for all screens, or just the main screen? [examples] spec, Gecko IDL, Blink IDL

Tess: should we file CSSOM View issues to ask them to deprecate the main screen object, and cut its properties down to just what is necessary for web compat?

Ken: That sounds good

Peter: availTop and availLeft make sense if you have top and left, but those only make sense if the geometric relationship between all the screen is known. (I suppose it is, but can change over time.)

Ken: [takes action to leave comment to that effect]

David: we shouldn't weigh in too strongly, in case they have good reason to do something different.

Ken: the next one is whether getScreens() should support filtering, perhaps with media queries

Tess: We have some advice in our design principles document about this kind of device enumeration. We recommend providing the ability to filter or constrain the devices that get returned.

Tess: They shouldn't rely on a list that provides all the screens.

Peter: not sure the multiscreen boolean makes sense.

Tess: They should also rigourously spec the order in which screens are returned (per our design principles)

Ken: [leaves comment summarizing the above]

Tess: [time check]

Peter: third issue is #34 combining screen enumeration and window placement proposals

Tess: argument for is that they need to be used together to solve the use cases, and argument against is theoretical purity? they're logically distinct?

Peter: relationship between screens can change over time, but that's not related to this issue. this is the relationship between windows and screens.

Tess: on the one hand, I like reviewing short specs that define one, self-contained feature. On the other hand, I tend to prefer kitchen sink specs (like HTML) over lots of little specs (like CSS). I think it makes editors think through how things are interrelated more. All that said, I think this question is ultimately one of editorial discretion. My quirky preferences shouldn't outweigh the preferences of the people actually doing the work.

Tess: I will take the action item to give the feedback

Tess: issue #29 now, reject promise with permission denial

David: Seems reasonable to reject the promise.

Ken: As we suggested deprecating navigator.screen it would be bad if you can not get the main screen without a rejection/permission

David: Not sure this should be behind a permission and instead be browsers settings etc.

David: I will leave some feedback. Done.

Ken: last question is about scope

David: seems complicated; different OSes and different browsers do different things here.

Tess: regarding #15 scope, I encourage them to take baby steps - I will leave feedback.

Ken: specific issues - we gave feedback - they say they have addressed our feedback.

Tess: issues were auto-closed?

[looking at their issues to see if the feedback has been addressed]

Ken: I'm fine with this... One of them they have filed an issue which hasn't been fixed yet.

Dan: are there key issues that haven't been resolved - or can we close?

Ken: for promises they have listened, for scope they are considering, and they have combined screen enumeration and placement which also follows our feedback so I would say yes. And they filed new issues in their new repo.

Dan: Propose we close then.

Peter: my main concern is the inetraction with the foldables work.

Ken: thomas steiner filed an issue related to that issue 21 on the new repo... Nothing there yet but the issue is filed.

Peter: my main fear is that - the foldables work is in flux - someone's going to ship something and then it will be an API we can't change and it won't work nicely with foldables...

Ken: i think that's why they asked about the scope.

Dan: we could leave that specific feedback - that this needs to play well with the developing foldables work.

Peter: i'm fine with that.

[consensus to close]

Ken: I can [leave a closing comment and close it