- From: Mark Foltz via GitHub <sysbot+gh@w3.org>
- Date: Tue, 25 Aug 2015 23:36:59 +0000
- To: public-secondscreen@w3.org
@mounirlamouri Well, the part of the API for receiving the PresentationSession is necessary for the page to communicate to the controller. As for the controlling side, Jonas brought up the idea of a presentation "daisy chaining" onto additional screens to display alternate content. See commit https://github.com/w3c/presentation-api/commit/3917fd8da20d67f916bb4a711799d897dca85322 for an example use case. But we don't yet have a concrete API for enabling daisy chaining or presentation to multiple displays with one user gesture. So for now limiting the controlling side of the API in a presentation context seems reasonable. Re: Fullscreen API I am not sure we should guarantee the presentation is started in fullscreen. The presentation display may be a PC running a windowing system, or I could forsee a side-by-side or picture-in-picture presentation modes for some displays. Because the current fullscreen API spec does not allow content to go fullscreen without a user gesture [1], it will require some changes to support a presentation document fullscreening itself. It seems like the main benefit to supporting fullsreen would be reuse of style sheets that expect to be used in a fullscreen mode (and have selectors for `::fullscreen` or `::backdrop`). Do we think it's worth it to force the presentation into fullscreen (even if it might not be rendered edge-to-edge in all cases)? -- GitHub Notif of comment by mfoltzgoogle See https://github.com/w3c/presentation-api/issues/99#issuecomment-134770850
Received on Tuesday, 25 August 2015 23:37:02 UTC