Meeting minutes
Screen Fold API
Suggestion: Rename to Device Posture API
anssik: Limited time, look at high priority topics while the spec contributors here.
… start with Screen Fold API. "Guest speakers" from Devices and Sensors.
anssik: TAG feedback was acknowledged by contributors. Please walk us through.
kenchris: TAG review; feedback was about exposing angle and posture.
… Posture might depend on other things, not just the angle. For example, if using keyboard and mouse on tabletop.
… Ship the posture as soon as possible, disconnect from angle values.
… Samsung is eager to ship animations on foldables using angle.
… Maybe privacy issues, if apps can track users using fold angles.
… Alex and I have ideas on how to address that. Also, need to handle devices with more than one fold.
… Suggest we rename spec to Device Posture API, focus on posture. Get the angle sensor in another spec.
Alexis: Personal opinion, posture has more value right now, in terms of helping apps/sites behave accordingly.
… Easiest to implement, even if device has multiple folds, device has one posture.
anssik: Two pieces of information, angle and posture. Posture is higher level abstraction on top of level.
… Expose posture and leave angle as a low level detail.
kenchris: We want to enable new use cases. If devices have more than one fold, need to expose it differently anyway.
dlibby: Seems reasonable, having angle in a CSS media query seems problematic, as it can change.
… Posture seems closer to what Android API is exposing.
anssik: Would it be informative or normative what the postures are?
kenchris: Because of hardware limitations, cannot describe angles for all devices. Info from Intel and OEMs.
… If Android is launching with different postures that would be a big deal.
… Want to collaborate with everyone in the industry.
<dlibby> this is android's alpha API surface: https://
Alexis: Angle is the main way to detect posture. Can also detect posture using other sensors.
anssik: Let's say Windows thinks device is laptop posture if angle is 0-150 degrees, Mac OS thinks 0-140 degrees.
… Would implementers have freedom to map to their concepts of postures?
kenchris: Yes, the spec does. But we have a chance to tell OEMs to use specific angles.
anssik: Do we want consistency?
kenchris: We want as much standardization as possible, to avoid surprises for developers.
Alexis: We derive posture from hinge angle, no native APIs to get posture on Windows, but long term OS will provide posture.
… Spec is not as relevant, since the OS will decide what the posture is.
dlibby: I'll add link to API in Windows.
tidoust: A couple of postures depend on the device orientation. Laptop vs book depends on landscape vs portrait.
… Could you run into inconsistencies between posture and orientation media queries?
kenchris: Could depend on the primary input device as well. People would have to derive it themselves. Better as postures.
anssik: Could the implementation use additional sensors to determine posture?
Alexis: For example, if you attach a keyboard, it becomes a laptop regardless of orientation
anssik: We could put these examples in the spec as implementation guidance
Action: alexis and kenchris to add some text clarifying that posture may be derived from sensors in addition to the angle
dlibby: When laptop and tablet are different postures, based on keyboard presence, why do we want developers to differentiate?
<anssik> proposed RESOLUTION: Drop ScreenFold.angle from the Screen Fold API first version (for DAS WG consideration)
Resolution: Drop ScreenFold.angle from the Screen Fold API first version (for DAS WG consideration)
kenchris: Names are a bit confusing, should find a better name than "laptop."
Alexis: Could have keyboard separate and use the device like a laptop.
<Zakim> dlibby, you wanted to ask about the 'primary input' comment
kenchris: Explainer is out of date, still uses the term "table"
msw: +1 for pursuing posture, it is useful. Ask what would posture return in a desktop setup with external monitors.
kenchris: Would return no-fold value.
… it's per-screen.
dlibby: Is this related to the hardware state, when the browser is spanned, even if the content may not be able to react semantically?
kenchris: Even if the browser is in one segment, you may need to react to it.
Alexis: If browser is on top half, it's not as relevant as if it is spanning. Hard to reason about posture based on spanning.
msw: It would be useful in tent mode to know if your window was spanning across the segment.
… For example, rendering half a game upside down.
kenchris: That information is from CSS spanning.
Alexis: Needs to be handled in the window segments spec.
Louay: Is there any implemenation to play around with?
Alexis: Some bits in Chromium, parsing CSS. Not there yet.
… Needs more time discussing with Microsoft over native side.
mfoltzgoogle: Any thoughts on testing these APIs? Simulation, with WebDriver perhaps?
alexis: We want to have tests for sure, but specifics this TBD
Multi-Screen Window Placement
Use cases explainer for Multi-Screen Window Placement
msw: Few changes since TPAC. Shape we proposed is stable, well-received.
… Some questions in my mind, some issues in GitHub deserve consideration.
… Reasonable API to place windows in multi-window desktop environments.
… Continuing to settle on consistent terminology between proposals.
… Compatibility with upcoming hardware.
… Mostly concerned with implementation details.
anssik: How are the security and privacy reviews going?
msw: One bit of feedback, ensure cross-origin opener policies respected.
… Privacy, one question to expose user friendly labels for the screens in various scenarios.
… Let sites get a user friendly string you can show to users.
… Questions about reliability of this info cross platform. Potential fingerprinting issue, could use generic names.
… An implementation detail at this point.
anssik: Similar to enumerating media devices.
<anssik> MediaDeviceInfo.label in Media Capture and Streams
mfoltzgoogle: Depends on what manufacturer puts into HDMI EDID, and whether OS exposes that to apps.
Louay: Naming is relevant if you have more than two displays.
Louay: Think of additional information to distinguish them, like display identification.
msw: Privacy feedback is to use generic names when possible. Very few users have three or more screens.
… Does it make sense to change the label if the user plugs in a third screen?
kenchris: Could be just a number, if you show it on the screen.
alexis: Inform the user of the primary monitor and secondary monitor, if that can be obtained from the OS.
msw: Those are critical parts of the API. Got partner feedback for more descriptive strings.
anssik: Do you have terms/concepts we should pay attention to?
msw: Thought about window segments, but the information available doesn't allow us to polyfill window segments.
… Concern about a <something> in a multi-screen environment. What information needs to be exposed about segments in a screen?
… In the case where we have a single panel, how would a web app determine a bounds of the segment, without having the window intersect the fold.
… For example, if a window is on the left side, how do I know about the fold, if I want to place my window based on that?
… Seems compatible with the notion of per-screen segments.
msw: Current API shape exposes a single event that is fired when a screen is connected or disconnected, or current screen changes.
… May want to split into two events.
kenchris: I agree
Window Segments
Rationalizing with declarative CSS and visualViewport concepts #12
[mediaqueries-5] Updating the CSS media feature syntax for foldable & dual-screen devices #5621
dlibby: During TPAC, a few resolutions in the CSS WG which changed a little bit our proposals.
dlibby: Confusion from developers led to pivoting to the JS API that we have. Getting closer to viewport segments.
… For the CSS portion, a media feature is planned to test how many segments a viewport, and geometry given by env property.
… One thing we've been struggling with is how to expose all of this.
dlibby: Currently, concept does not exist in CSS. Two constraints: for CSS, we pretty strongly believe that we want a declarative solution that is efficient. For JS, there is a natural fit with the Visual Viewport API.
… Feedback I'd like to have is whether that's the right approach. JS gives you changing values and CSS gives higher-level abstraction.
… Also a couple of questions that Mike brought up during previous discussion
kenchris: That makes sense to me. One possible worry is, if CSS is not flexible enough, devs will do everything in JS, which would be inefficient.
anssik: Is there an established convention for mapping CSS and JS APIs? Low-level in JS and high-level in CSS? Or is it 1:1 in terms of expressiveness?
dlibby: The viewport is one example. Devs use 100vw and still end up needing vertical scrolling.
… Trying to think of other examples. Good idea to explore prior art.
anssik: From my dev days, I would be expecting to get from JS what I can get from CSS.
kenchris: Important that everything that is in CSS is exposed to JS. Not necessarily the other way around.
anssik: But then, the experience is that, if you expose an API that can be misused, it will be. Especially with performance, people will expect that implementations will always perform well, regardless of how they use them.
… Minimizing the API surface seems like a good approach.
dlibby: The renaming to viewport clarifies how the spec fits with other screen proposals.
msw: This segment information could be useful before the window is placed. That's where the multi-screen window placement API could be useful and could perhaps give you some per-screen viewport info.
kenchris: You really want the segments per screen. There may not be a 1:1 mapping though.
msw: I don't think that the aim would be to have pixel-level precision with regards to viewport segment boundaries. The general idea that this screen contains multiple segments could be informative to certain web applications that are trying to align their windows through such boundaries.
… Probably lower priority than what each of the proposals is trying to achieve
anssik: Do you want a new name for the repo?
dlibby: Perhaps.
kenchris: We talked about fold angle before. If you see any way to integrate the angle in this proposal somehow, that would be valuable.
anssik: My understanding is that Visual Viewport API has been shipping in Chrome, but the spec has not advanced much
… Would you layer on top of this?
dlibby: That's TBD
msw: Someone sort of referenced that they would like to have fullscreen on 2 out of 3 screens on Chrome OS.
… The discrete panels are composed as one virtual display.
… The request was was they would be to go fullscreen on 2 of the 3 screens and leave the third screen available for other windowing activities.
… The only way that ChromeOS allows windows to span displays is through this unified mode.
… Not sure how to address this.
dlibby: In my mind, this would be a nice fit for segments indeed. Here are the coordinates available in JS or CSS.
… What is the role of the window manager in its restricted semantics that it is forcing.
… Very interesting use case.
… It speaks a bit to the need to screen segments.
msw: In that case, I suppose it's even possible to programmatically place your windows across screens, which is not the current goal of the multi-placement proposal.
anssik: I think we discussed PowerToys FancyZones window manager utility in the past.
… Is this considered as a valid implementation for segments?
dlibby: Reformulating the question, if a user has these FancyZones enabled, should a fullscreen window result in a viewport that is segmented by the zones?
kenchris: Used by people who have these very large monitors, because you usually don't want maximized windows to actually take the entire screen.
dlibby: I think the intent of the segments is that there is some sort of logical division.
… Maybe there's an argument for it. Having that information exposed from the OS might be the trigger.
tidoust: Noticed Visual Viewport API is widely shipping, should we do something to advance the spec?
dlibby: Can connect with David, take an action on look into it
Action: dlibby to contact editor of the Visual Viewport API to assess standardization intent
Form Factors
anssik: The explainer itself is not the main deliverable, it's just a means to align on terminology.
… Floor is open.
dlibby: Flashing out that viewport section, I can take care of that.
… Some clarity on posture related to "laptop" would be nice to have.
msw: The idea of screen segments. Fold work is taking a higher level perspective. It's not quite as important to explain how folds relate to multiple screens.
alexis: It seems to me that there will be on a single foldable screen multiple logical segments. It seems that there will be a concept of logical segments, even though it is not physical segments.
… I'm not sure whether the notion of logical segments is covered is in this explainer.
anssik: So a definition for logical viewport segment.
alexis: Example of browser window covering the entire screen, held in "book" posture, need to target the segments, e.g. to create a 3D book page effect.
Louay: One comment regarding the naming of the API. We just need to make sre that we take possible future features into account, so that they still fit the name.
anssik: Please go through the material and let us know what you think.
msw: Has our report gained any attention? It's valuable for us, has it been shared anywhere?
anssik: Internally, it's been useful for explaining this problem space. We haven't done much marketing externally.
… More a paper/tool for ourselves to align on terms and adjust other normative specs.
msw: It might be useful for folks in WICG and other groups.
alexis: Even for developers so that they start understanding these concepts.
… Did you report that internally within Microsoft, Daniel?
dlibby: Most of the team is aware of concepts, but I pointed some folks to it. A mix of both.
anssik: I don't want to glorify this document, but let's get more eyeballs indeed.
Presentation API continued
Same-screen presentation PR #479
mfoltzgoogle: The API could be evolved to support this. The question was raised whether that could fall under the scope of the window placement API where being able to place a window to an attached display could perhaps include the current display.
msw: Placement on the same screen is certainly in scope.
… It sounded that the request was to be able to use the Presentation API regardless of the situation so that developers do not have to use different APIs to target different displays.
mfoltzgoogle: One key question is whether your team is also looking at wireless displays with the same API as directly attached displays.
dlibby: I don't recall on the top of my head. I believe they are only looking at connected displays.
msw: Maybe I'm missing some context on what might be requested that is not covered by the Window Placement API.
dlibby: Nice to use one API to "enter presentation mode". Also no way to open a window in fullscreen mode (user action needed).
mfoltzgoogle: Alternatives: use the Presentation API, allow placed window to request fullscreen without an additional user activation. There seems to be an issue in the repo around that.
msw: When the opener has the right permission granted, that should be doable. It hasn't been one of our top priorities. If it's something that folks using the API would want, a public signal would be very welcome to inform our work.
mfoltzgoogle: With the Presentation API, this will not be restricted to attached screens. They would see a combination of local and remote screens.
dlibby: Isn't there a mechanism to filter the list?
mfoltzgoogle: We do filter for certain URLs that correspond to apps but if you give us HTTPS URL
… we will consider all types of screens.
dlibby: And the communication mechanism between the opened page and the opener is the same?
mfoltzgoogle: Correct.
… The communication channel abstracts the way the screen is attached.
dlibby: I'll follow up to get a bit more clarity on this.
… It's not the highest priority.
… I see some nice ergonomic benefits to this.
mfoltzgoogle: I think it's a logical extension for apps that really want what the Presentation API offers. If there's a motivation and signal we could use to prioritize that work, I would certainly be willing to provide feedback on API changes to support that.
… If it's more local displays only, I would recommend working things out with Window Placement.
AOB
anssik: Thanks everyone for joining. You should expect to see some updates in the issues discussed where we'll tag some of you guys so that we keep pushing this work forward.
Louay: Maybe we can think of having another meeting like this one before TPAC.
anssik: Good point. Also we can organize ad-hoc and joint calls as needed.
… Regarding re-chartering, we should start discussions around mid of this year.