- 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