- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Mon, 30 Jun 2014 12:49:25 +0000
- To: Francois Daoust <fd@w3.org>
- CC: "public-webscreens@w3.org" <public-webscreens@w3.org>
Hi Francois, On 30 Jun 2014, at 13:30, Francois Daoust <fd@w3.org> wrote: > Great demo! One question, see inline. Thanks, happy to hear you liked it! > In the demo code [1], is there a reason for "requestShow" to return a pointer to the second screen (or a Promise to get that second screen)? The only need seems to be to close the show, but that could e.g. be handled with a call to an hypothetical "v.exitShow" function, which would avoid introducing another construct, and be somewhat consistent with the approach taken by the FullScreen API. You’re correct. I implemented the exitShow() in the requestshowmedia.js to get a feel of it as it was a trivial addition: https://github.com/webscreens/requestshowmedia/commit/22aee1df236b138474ec935dbf61a2be2e8ada66 ... and updated the demo accordingly: https://github.com/webscreens/requestshowmedia/commit/1965887c98cada8fe7981df7c3d289a21534477a I think this simplified the API even further. In the demo, I now retain the state of the second screen (i.e. showing or not) in a 'data-active' data-* attribute associated with the ‘show' button instead of checking against the ‘secondScreen' reference. There may be a need to be able to query the state of the second screen using the API for more advanced use cases? Or, are we covered if we can just listen to ‘closesecondscreen’ events implemented by the prollyfill currently? The Fullscreen API has a ‘fullscreenEnabled’ flag for that. Thanks for the suggestion! -Anssi > [1] https://github.com/webscreens/requestshowmedia/blob/gh-pages/demo/index.html#L40
Received on Monday, 30 June 2014 12:51:22 UTC