- From: Mark Foltz (Google) via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Jun 2022 00:54:04 +0000
- To: public-secondscreen@w3.org
_Summary of developments since this issue was first filed:_ The primary use case that was in mind when the explainer was written was to allow presentation applications to make use of multiple displays. These applications wish to present slides or other content on the secondary display and controls and speaker notes on the primary display. The Presentation API doesn't allow the two documents to share state which was a blocker. If the secondary display is a wired attached display, then the [Multi-Screen Window Placement API](https://w3c.github.io/window-placement/) handles this use case by giving the application the ability to place a new window on that secondary display. The [Fullscreen Companion Window](https://github.com/w3c/window-placement/blob/main/EXPLAINER_initiating_multi_screen_experiences.md) makes the flow even simpler than what was proposed here (not requiring additional browser dialogs). If the secondary display is a wireless display, the application can open the presentation content in a new tab, control it by cross-window messaging, and then invoke the [Tab Self-Mirroring API](https://github.com/webscreens/site-initiated-mirroring/blob/main/explainer.md) to project it to the secondary display. As the core use cases are being handled by ongoing work in the community and working groups, we don't plan on pursuing this feature any further. I plan on closing this out once the CG charter is updated to reflect that it's no longer a work item for the group. -- GitHub Notification of comment by mfoltzgoogle Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/347#issuecomment-1149326879 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 June 2022 00:54:05 UTC