W3C home > Mailing lists > Public > public-secondscreen@w3.org > August 2015

Re: [presentation-api] Define behavior of Window and Fullscreen APIs in the presentation browsing context

From: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Tue, 25 Aug 2015 23:36:59 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-134770850-1440545817-sysbot+gh@w3.org>
@mounirlamouri Well, the part of the API for receiving the 
PresentationSession is necessary for the page to communicate to the 

As for the controlling side, Jonas brought up the idea of a 
presentation "daisy chaining" onto additional screens to display 
alternate content.  See commit  
 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
Received on Tuesday, 25 August 2015 23:37:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 August 2015 23:37:02 UTC