04:36:35 <RRSAgent> RRSAgent has joined #webscreens
04:36:35 <RRSAgent> logging to https://www.w3.org/2021/10/26-webscreens-irc
04:36:37 <Zakim> RRSAgent, make logs Public
04:36:38 <Zakim> please title this meeting ("meeting: ..."), anssik
04:36:42 <anssik> Meeting: Second Screen CG - TPAC 2021 vF2F
04:36:47 <anssik> Chair: Anssi, Louay
04:36:52 <anssik> Agenda: https://github.com/w3c/secondscreen-wg/issues/3
04:37:30 <anssik> Scribe: Anssi
04:37:39 <anssik> scribeNick: anssik
04:37:49 <anssik> Present+ Anssi_Kostiainen
04:37:55 <anssik> RRSAgent, draft minutes
04:37:55 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/26-webscreens-minutes.html anssik
04:54:26 <takumif> takumif has joined #webscreens
04:56:12 <msw_google> msw_google has joined #webscreens
04:58:06 <tidoust> tidoust has joined #webscreens
05:00:08 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
05:00:27 <mfoltzgoogle> present+ Mark Foltz
05:00:46 <tidoust> present+ Francois_Daoust
05:00:51 <tidoust> RRSAgent, draft minutes
05:00:51 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/26-webscreens-minutes.html tidoust
05:01:27 <tidoust> scribe: tidoust
05:01:46 <jsbell> jsbell has joined #webscreens
05:01:51 <jsbell> present+
05:01:52 <anssik> Present+ Mike_Wasserman
05:01:53 <cpn> cpn has joined #webscreens
05:02:05 <mfoltzgoogle> present+ Mark_Foltz
05:02:22 <anssik> Present+ Arnoud_Mandy
05:02:31 <anssik> Present+ Alexis_Menard
05:02:32 <jsbell> present+ Joshua Bell
05:02:32 <msw> present+
05:02:42 <anssik> Present+ Chris_Needham
05:03:13 <anssik> Present+ Joshua_Bell
05:04:02 <anssik> Present+ Daniel_Libby
05:04:18 <anssik> Present+ Takumi_Fujimoto
05:04:28 <anssik> Present+ Pavlo_Buidenkov
05:05:18 <dlibby> dlibby has joined #webscreens
05:05:25 <anssik> Present+ Louay_Bassbouss
05:05:58 <tidoust> Agenda: https://github.com/w3c/secondscreen-wg/issues/3
05:07:14 <anssik> RRSAgent, draft minutes
05:07:14 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/26-webscreens-minutes.html anssik
05:07:59 <arma> arma has joined #webscreens
05:08:05 <anssik> Topic: Multi-Screen Window Placement
05:08:13 <anssik> -> https://webscreens.github.io/window-placement/ Multi-Screen Window Placement spec
05:08:27 <anssik> -> https://github.com/webscreens/window-placement/blob/main/EXPLAINER.md Multi-Screen Window Placement Explainer
05:08:39 <tidoust> anssik: Spec has been shaping up since our last meeting. Explainer completed as well.
05:08:46 <darktears> darktears has joined #webscreens
05:09:03 <tidoust> ... Mike or Joshua, could you highlight key issues?
05:09:41 <tidoust> Mike: General point is that the API is sufficiently capable. Its shape is stable and extensible enough.
05:09:54 <tidoust> ... Our aim is to get a stable release in Chromium sometime in the near future.
05:10:17 <tidoust> ... Some fairly minor issues on the spec, including TAG feedback to rename some of the properties.
05:10:35 <tidoust> ... I think we'll just go with TAG suggestions there, although we can bikeshed on that.
05:11:20 <tidoust> ... Most of the issues raised are about extending the API. Still need to go through some of them but I'm confortable that the API can accommodate the extensions afterwards if needed.
05:12:03 <tidoust> ... Maybe one big open question surrounding the use of wayland(?) in Linux.
05:12:27 <tidoust> ... Our API is partly about extending window.open coordinate values.
05:12:29 <cpn> s/wayland(?)/Wayland/
05:13:12 <tidoust> ... Wayland was willingly designed to prevent applications from knowing where windows are positioned on screen. As things stand, it breaks window primitive relative to positioning and moving.
05:13:33 <tidoust> ... In most other systems, it's not possible for windows to specify their bounds.
05:13:41 <mfoltzgoogle> q+
05:13:45 <tidoust> ... Windows get placed in certain arrangements.
05:14:19 <tidoust> ... Wayland is definitely an interesting risk. It does seem to be gaining popularity as a replacement for X as a window management.
05:14:41 <tidoust> ... I believe KDE does not have plan to deprecate X at least for now but other plans in progress.
05:14:51 <tidoust> ... I would appreciate feedback.
05:15:02 <tidoust> anssik: Is that captured in an issue?
05:15:36 <tidoust> Mike: Not yet. More of an internal risk study for now. Planning to publish that soon.
05:15:48 <tidoust> anssik: I'm aware of Wayland contributors in my company.
05:16:20 <tidoust> anssik: Second question is assessing whether Multi-Screen could be promoted as a WG deliverable in the next charter.
05:17:29 <anssik> -> https://www.w3.org/TR/cssom-view/#extensions-to-the-window-interface Extensions to the Window Interface
05:17:33 <tidoust> Mike: Breaking it down, our proposal is to extend CSSOM View. Additional argument for Fullscreen API and the main entry point for getting the array of available screens. It could be part of CSSOM View interfaces or defined as its own API.
05:18:19 <jsbell> queue+
05:18:33 <anssik> -> https://github.com/webscreens/window-placement/issues Open issues
05:18:54 <tidoust> ... A new issue for Wayland is certainly appropriate. A couple of issues around naming could benefit from feedback as well.
05:19:08 <msw> https://github.com/webscreens/window-placement/issues/54
05:19:30 <msw> https://github.com/webscreens/window-placement/issues/50
05:21:08 <tidoust> Mike: [goes through a couple of bikeshedding issues]
05:21:26 <tidoust> anssik: I'm looking at the TAG review repo. There seem to be multiple issues.
05:21:26 <msw> https://github.com/w3ctag/design-reviews/issues/602
05:21:37 <anssik> -> https://github.com/w3ctag/design-reviews/issues/602 Multi-Screen Window Placement API TAG design review
05:21:58 <tidoust> ... How much of the TAG feedback is reflected in the spec?
05:22:20 <tidoust> Mike: The main points are really about the naming of the entry points.
05:22:34 <tidoust> anssik: From a design perspective, that seems like an OK.
05:22:57 <tidoust> ... Have you discussed with security and privacy folks already at this stage?
05:23:15 <tidoust> Mike: We've gone through multiple rounds of internal security and privacy reviews.
05:23:24 <tidoust> ... As part of original trial.
05:24:26 <tidoust> ... No specific changes requested. It would be interesting to understand how some of the user affordances that we're considering may impact things.
05:24:35 <tidoust> ... E.g. partner asking to open window in fullscreen.
05:25:02 <tidoust> anssik: Back in the days, there was a proposal on gesture delegation.
05:25:10 <anssik> q?
05:25:48 <tidoust> Mike: Partners have requested the ability to open multiple pop-ups from a single gesture without triggering the pop-up blocker. And potentially be able to request fullscreen for the pop-up or request multiple fullscreens for the pop-ups.
05:26:23 <tidoust> ... I don't think that it makes sense to require the user to click "fullscreen" 7 times on multiple days, but this can be added later on.
05:27:22 <anssik> -> https://wicg.github.io/capability-delegation/spec.html Capability Delegation API
05:27:38 <tidoust> Mike: You mentioned a delegation API. One person I'm working with is actively pursuing an API that would allow an iframe to pass a token to another to delegate permission.
05:27:57 <anssik> q?
05:28:12 <tidoust> ack mfoltzgoogle
05:28:59 <tidoust> mfoltzgoogle: Back to the issue around Wayland. Potential extension to the current API that would either let a site detect that the underlying window system basically won't allow window movement, or some way to tell the app that window movement would fail if they tried.
05:29:18 <tidoust> ... Might be preferable as getting Wayland to support this would likely take time.
05:30:10 <tidoust> Mike: That's great feedback. I think it would be valuable. In one way, folks can call moveTo and see that it doesn't work, but it would be beneficial to expose somewhere whether window placement is allowed.
05:30:28 <tidoust> ... Dealing with different window managers is interesting because they sometimes have unique behaviors.
05:30:44 <tidoust> ... Never quite sure whether the window manager is done processing the latest request that you sent to it.
05:31:24 <tidoust> ... I would like a Promise-based mechanism that could resolve/reject. But being able to resolve the Promise once the window manager is done is actually a challenge.
05:31:36 <anssik> q?
05:31:41 <tidoust> ack jsbell
05:32:23 <tidoust> jsbell: About Wayland, approach is very privacy-forward in the sense that windows don't know where they are.
05:32:34 <tidoust> ... I can imagine different use cases for the APIs.
05:32:48 <tidoust> ... Multiple screens, e.g. financial interface.
05:33:04 <tidoust> ... Other scenario: pop-ups with relative coordinates.
05:33:17 <tidoust> ... First tied to window manager, the other would work.
05:34:00 <tidoust> ... In terms of the issue tracker, we've provided a lot of feedback to partners, but we haven't categorized issues as "future add", "to be done", etc.
05:34:41 <tidoust> ... We also have some internal partners that are interested and that hasn't been reflected in the issue tracker yet.
05:35:14 <tidoust> anssik: OK, making that more explicit is helpful.
05:35:55 <tidoust> jsbell: If it's going to be promoted as a WG deliverable, is explicit support from other implementers needed?
05:36:16 <tidoust> anssik: W3C Process does not mandate that.
05:37:56 <anssik> tidoust: that is correct, in general we like to see a general agreement on an API we standardize to ensure there's no dead end, process-wise no requirement for all major browsers to support a proposal before WG adoption
05:38:19 <mfoltzgoogle> q+
05:38:42 <anssik> ack mfoltzgoogle
05:38:55 <tidoust> Mike: Related adoption by the WG or going through the CSS WG, aspects should be reflected in the CSSOM View spec, but it may be very well appropriate to write the rest in a separate spec
05:39:35 <tidoust> mfoltzgoogle: You don't want to end up being split between two groups to minimize dependencies.
05:40:44 <tidoust> Mike: By defining coordinate views in CSSOM View functions. If those coordinates were not defined in main screen coordinates, we would need a dedicated API for that.
05:41:18 <tidoust> ... In that sense, it might be appropriate for getScreens to be exposing the placement of individual screens, and coordinates to all be defined in the same spec.
05:41:36 <anssik> RRSAgent, draft minutes
05:41:36 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/26-webscreens-minutes.html anssik
05:41:39 <tidoust> ... That said, part of what we're exposing will also be used by the Fullscreen API.
05:41:54 <anssik> q?
05:42:25 <tidoust> anssik: I'm hearing that this is a candidate for adoption by the WG.
05:43:12 <tidoust> ... We'll be looking into it. What is the Chrome's expected timeline for this spec? Would you like to see the spec move sooner rather than later in terms of standardization?
05:43:41 <tidoust> Mike: Some time in Q1 2022
05:43:56 <anssik> q?
05:43:59 <tidoust> anssik: OK, we probably want this to move forward then.
05:45:49 <tidoust> mfoltzgoogle: I think that's reasonable to adopt, but charter needs to be explicit about how split is expected with CSS WG.
05:46:15 <tidoust> anssik: Yes, I could see a future meeting where we sit down with the CSS WG about this spec.
05:46:27 <tidoust> jsbell: Anyone liaising with the CSS WG already?
05:46:37 <tidoust> anssik: That's a good question.
05:46:38 <cpn> q+
05:46:56 <tidoust> mfoltzgoogle: We did reach out around the Presentation API a few years ago. Nothing recent.
05:47:17 <tidoust> anssik: We can establish a connection.
05:47:49 <tidoust> mfoltzgoogle: Closer coordination between the Media WG and CSS WG around media capabilities.
05:47:56 <tidoust> ack cpn
05:47:59 <anssik> ack cpn
05:48:08 <tidoust> cpn: Was about to make the same point.
05:48:35 <tidoust> ... CSS has a large number of specs in development. You may find it challenging to get time in their agenda.
05:49:09 <tidoust> ... Not meant to say that we had difficulty with that, just acknowledging that they have lots on their plate.
05:49:21 <anssik> q?
05:50:09 <tidoust> PROPOSED RESOLUTION: CG would like the WG to consider adopting the Multi-Screen Window Placement API as a deliverable
05:50:38 <tidoust> RESOLUTION: CG would like the WG to consider adopting the Multi-Screen Window Placement API as a deliverable
05:50:56 <tidoust> anssik: We will work with the WG to try to implement this.
05:59:29 <tidoust> Topic: Window Segments Enumeration
05:59:51 <tidoust> scribe+ mfoltzgoogle
05:59:51 <mfoltzgoogle> scribe+ Mark_Foltz
06:00:27 <anssik> s/Topic: Window Segments Enumeration/Topic: Window Segments Enumeration  deprecation & new Viewport Segments Property
06:00:36 <anssik> RRSAgent, draft minutes
06:00:36 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/26-webscreens-minutes.html anssik
06:00:53 <mfoltzgoogle> anssik: Please give us an update dlibby.
06:01:07 <dlibby> https://webscreens.github.io/form-factors/
06:01:13 <mfoltzgoogle> dlibby: Concepts around foldables, dual screens, multi-window configurations.
06:01:50 <mfoltzgoogle> ...Clarify concepts in API. What viewport segments get exposed to developers.
06:01:54 <anssik> -> https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md New Viewport Segments Property explainer
06:02:08 <mfoltzgoogle> ... Came to the conclusion to move segments to Javascript, in the visualViewport API.
06:02:17 <anssik> -> https://webscreens.github.io/form-factors/ Form Factors Explained
06:02:22 <mfoltzgoogle> ... has scale, pinch-zoom, related concepts.
06:02:28 <dlibby> https://wicg.github.io/visual-viewport/
06:02:45 <mfoltzgoogle> ... Since last meeting, moved API into visualViewport, which is in WICG.
06:02:46 <dlibby> https://github.com/w3c/csswg-drafts/issues/6339
06:02:54 <mfoltzgoogle> ... has shipped in major browsers.
06:03:25 <mfoltzgoogle> ... Tentative plan is to adopt in the CSSOM View WG.
06:03:39 <dlibby> https://drafts.csswg.org/mediaqueries-5/#mf-horizontal-viewport-segments
06:03:42 <mfoltzgoogle> ... Next step is to get to Editors Draft, then onto TR.
06:03:51 <dlibby> https://drafts.csswg.org/css-env-1/#viewport-segments
06:03:57 <mfoltzgoogle> q+
06:04:08 <mfoltzgoogle> ... More ergonomic API surfaces.
06:04:20 <anssik> ack mfoltzgoogle
06:04:21 <mfoltzgoogle> anssik: Thank you.
06:06:22 <anssik> mfoltzgoogle: it is on a todo list to import the spec Visual Viewport into CSS WG soonish
06:06:26 <mfoltzgoogle> anssik: Does CSSWG need to recharter to adopt new specs?
06:06:36 <mfoltzgoogle> dlibby: Spec is flexible and wide-ranging
06:06:40 <mfoltzgoogle> s/Spec/Charter/
06:07:03 <mfoltzgoogle> anssik: Can you speak to experimental plans?
06:07:29 <mfoltzgoogle> dlibby: Running an origin trial in Edge.  The Android support library is still in beta.  Some nitty-gitty things like binary size.
06:07:47 <tidoust> [ CSS WG charter has this about adopting new deliverables: "This list of modules is not exclusive: The WG may also create new CSS modules, within its scope. Also, it may split or merge CSS modules. If no participant in the group believes a proposed module is out of scope, and the group has consensus to add it, the group may add a new module. If the participants who object sustain their objection after discussion, a re-charter to clarify the scope may
06:07:48 <tidoust> be needed." https://www.w3.org/2020/12/css-wg-charter.html#deliverables ]
06:08:01 <mfoltzgoogle> ..for Edge, dual-screen devices, it is live.  On Android, a positive reception.
06:08:19 <darktears> q+
06:08:21 <mfoltzgoogle> ... circle back and finish off integration into Chromium.   Last thing, crossing T's with TAG review.
06:08:55 <mfoltzgoogle> anssik: Expect that as part of the visualViewport spec, the segments property would be a feature?
06:09:12 <mfoltzgoogle> dlibby: The property is coming along as a "more experimental" feature.
06:09:42 <mfoltzgoogle> anssik: Propose we deprecate the old Window Segments Enumeration API.
06:09:50 <anssik> -> https://github.com/webscreens/window-segments/pull/15 Add deprecation message #15
06:09:53 <mfoltzgoogle> ...PR #15 is still open
06:11:00 <mfoltzgoogle> ACTION: dlibby to merge PR#15.
06:11:16 <anssik> q?
06:11:28 <anssik> ack darktears
06:11:44 <mfoltzgoogle> darktears: Assuming by the Android support lib, the window manager?
06:11:56 <mfoltzgoogle> ... The posture could be hard coded in the window manager.
06:12:02 <mfoltzgoogle> ... Are you connected with Samsung?
06:12:39 <mfoltzgoogle> ACTION: darktears to send Samsung contact to dlibby
06:12:53 <anssik> q?
06:13:34 <anssik> Topic: Presentation API v2 feature: Tab Self Mirroring API
06:14:28 <tidoust> mfoltzgoogle: I'll introduce this briefly. Takumi will go into details.
06:14:41 <takumif> Explainer: https://github.com/mfoltzgoogle/tab-self-mirroring/blob/main/explainer.md
06:15:12 <tidoust> ... To set a bit of context. Some partners or sites simply want to mirror themselves to a target device as opposed to having to create a new document and show it on the other device.
06:15:42 <tidoust> ... Since Chrome has a tab mirroring feature which predates the Presentation API, we activated this through a custom URI.
06:15:55 <tidoust> ... We'd like to integrate this mechanism in the Presentation API.
06:16:15 <tidoust> ... We made some changes recently.
06:16:53 <tidoust> takumif: See the explainer. Currently, with Chrome, we have Google Meet and Google Slides that use the functionality. And one other product currently working on an implementation to support this.
06:17:40 <tidoust> ... Talking to them, right now, the capabilities that they need: 1) allow them to choose whether to do the video playback on the controller or receiver side. 2) choose to change the latency of the stream that they're doing to lower it when needed.
06:18:04 <tidoust> ... Use case is when audio is played back by the controlling side.
06:18:46 <tidoust> ... There are also additional features that they would like to see in the future: choose the capabilities of the device that they choose to mirror to. Only mirror to devices with video output capabilities for instance.
06:19:09 <tidoust> ... e.g. for slides
06:20:02 <tidoust> ... In the explainer right now, the proposal is to change the constructor of the PresentationRequest. Currently, it takes a URL or an array of URLs. The proposal would have the constructor also take an array of objects with additional parameters such as capture latency
06:20:31 <tidoust> ... We're looking for feedback on whether this makes sense, or whether this should be moved to a different location.
06:20:32 <anssik> q?
06:20:59 <tidoust> anssik: Could the API be standalone?
06:21:34 <tidoust> ... How much overlap is there in terms of implementation infrastructure with the Presentation API?
06:22:00 <mfoltzgoogle> q+
06:22:01 <tidoust> takumif: I think that there is a large overlap, making it an argument to have it as part of the Presentation API.
06:22:45 <anssik> q?
06:22:47 <tidoust> anssik: We could make it an extension to the Presentation API, 2 specs with a dependency.
06:22:48 <anssik> ack mfoltzgoogle
06:23:21 <anssik> RRSAgent, draft minutes
06:23:21 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/26-webscreens-minutes.html anssik
06:23:28 <tidoust> mfoltzgoogle: I did want to mention that we've been in discussions with partners about a use case: depending on the device, they want to do self-mirroring or launch a receiver application.
06:23:50 <tidoust> ... In order for that to work without multiple buttons on the page, the best way to do that is to extend PresentationRequest.
06:24:10 <tidoust> ... Otherwise, it gets more complicated to support for the same device availability and user gesture.
06:24:10 <msw> +q
06:24:51 <tidoust> anssik: What is the stability of this feature? Link to WG rechartering?
06:25:11 <tidoust> ... We don't need to explicitly mention the feature in the charter as far as I can tell.
06:25:57 <tidoust> anssik: What is the implementation status for this? You mentioned partners.
06:26:17 <tidoust> takumif: We have a private API that is different from what we're proposing here that is currently being used.
06:26:26 <mfoltzgoogle> q+
06:26:39 <anssik> ack msw
06:27:12 <tidoust> Mike: Thanks for sharing the explainer. Two alternatives considered: Presentation API and Remote Playback API.
06:27:50 <tidoust> ... What about messaging for the streams?
06:28:09 <tidoust> takumif: We're not exposing the streams to the apps at all.
06:28:12 <anssik> q?
06:28:15 <anssik> ack mfoltzgoogle
06:28:15 <tidoust> ... The mirroring part will be part of implementations.
06:28:19 <tidoust> ack mfoltzgoogle
06:29:01 <tidoust> mfoltzgoogle: Most of the implementation is the new API shape. The functionality already exists otherwise. Most of the implementation work would be in defining the API and wiring it up.
06:29:33 <anssik> q?
06:29:35 <tidoust> ... The other question was around stability. I would say that it's still fairly early. We may want to do some more prototyping.
06:30:13 <tidoust> anssik: any plan to move it to the CG space?
06:30:42 <tidoust> mfoltzgoogle: We'll probably move the explainer. I don't expect a spec to appear until we have a little bit more experience working with it.
06:31:11 <tidoust> ACTION: takumif to move Tab Self Mirroring API explainer to Second Screen CG repository
06:32:00 <tidoust> Topic: AOB
06:32:19 <tidoust> anssik: Thank you for joining us today. Stay tuned for WG rechartering.
06:32:49 <tidoust> ... We will have calls once in a while. Let the chairs know when you feel that there's a topic that would benefit from synchronous discussions.
06:34:41 <tidoust> [some discussion on the hope to organize a real F2F soon-ish]
06:35:10 <anssik> proposal was for 9 OR 23 Nov 2021 21:00 UTC for a joint meeting with Media WG
06:35:14 <tidoust> cpn: We talked previously about organizing joint Media WG discussions around HDR capabilities discussions
06:35:19 <tidoust> ... Is that still needed?
06:35:35 <anssik> -> https://github.com/w3c/media-wg/issues/33 Joint meeting with Second Screen WG #33
06:35:37 <tidoust> anssik: Two possibilities in November.
06:35:53 <anssik> -> https://github.com/w3c/openscreenprotocol/issues/194 [Remote Playback] Capabilities for HDR rendering and display openscreenprotocol#194
06:36:06 <anssik> -> https://github.com/w3c/openscreenprotocol/issues/233 Use the same codec names as the media APIs. openscreenprotocol#233
06:36:28 <anssik> s/openscreenprotocol#233/openscreenprotocol #233
06:36:37 <tidoust> anssik: Two issues to discuss. One on HDR capabilities, the other on codec names.
06:36:47 <anssik> s/openscreenprotocol#194/openscreenprotocol #194
06:36:52 <anssik> RRSAgent, draft minutes
06:36:52 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/26-webscreens-minutes.html anssik
06:38:16 <tidoust> mfoltzgoogle: I won't be available on 23 Nov. Around Thanksgiving. Better in December or January.
06:38:44 <tidoust> cpn: December 14 or January 11 would be the Media WG meetings.
06:38:49 <anssik> q?
06:40:49 <tidoust> RRSAgent, draft minutes
06:40:49 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/26-webscreens-minutes.html tidoust
08:40:07 <Zakim> Zakim has left #webscreens