HTML Slidy remote

A Presentation API demo


  1. Enter the URL of a slide show made with HTML Slidy above.
    The slide show origin must be one of http(s):// or
  2. Hit "Open slide show"
    The slide show will open on a second screen if available or in a separate window otherwise.
    Ensure this page is allowed to open pop-up windows!
  3. Use the Slidy remote on this page to control the running slide show.
    Key presses and gestures are supported as well

Implementation details

The source code is available on GitHub under a W3C Software license.

Presentation API shim

Under the hoods, the demo uses a JavaScript shim of the Presentation API that supports:

Google Cast devices
Support for Google Cast devices requires Google Chrome with the Google Cast extension
Second screens attached through a video port
Support for these second screens requires that you run this page in a modified version of Chromium specifically prepared to demo the Presentation API.
Supported attachment methods include regular video ports (HDMI, VGA) as well as wireless equivalent (e.g. Miracast, WiDi).
If there are more than one second screen available, the demo selects the first one.
Separate window
This is used as a fallback when the shim cannot find available second screens
Note that your Web browser is likely going to block this attempt to open a pop-up window by default! It should offer a way to authorize it though.

NB: The shim uses a w3c prefix for interfaces exposed on navigator and window: navigator.w3cPresentation and w3cPresentationRequest.

How the demo works

When the user requests to present the given slide show, this page creates a PresentationRequest and starts it to open the appropriate HTML Slidy receiver application on a second screen. The call returns a PresentationConnection object. The page then uses that object to have the HTML Slidy receiver application open the requested slide show and to send Slidy commands afterwards.

The HTML Slidy receiver application is an empty page that retrieves the first incoming presentation connection using navigator.w3cPresentation.receiver.getConnection() and listens to message events on that connection. When it receives the appropriate message, it loads the requested slide show in a child iframe that takes up 100% of the viewport and controls the Slidy instance of the slide show within that iframe in reaction to further presentation messages it receives.

Due to usual security restrictions, the origins of the HTML Slidy receiver application and of the slide show must match. The receiver application would not be able to control the slide show otherwise. This page only knows of two HTML Slidy receiver applications:

You may extend the code to support receiver applications on other domain names. Both HTML Slidy receiver applications have been registered with Google and may run on any Chromecast device.

Why use an iframe on the receiving side?

Since the iframe triggers the same origin constraint, it would be tempting to drop it altogether. It could be done in theory provided HTML Slidy is updated to retrieve the right incoming connection and listen to message events.

In practice, this would require slide shows to use that updated (and likely unstable) version of HTML Slidy, which is probably not a good idea for actual slide shows. Also note that there is no way to run arbitrary receiver applications with Google Cast devices for the time being: any receiver application must first be registered with Google. Having to register all existing slide shows would be somewhat tedious.

Slidy commands

Slidy commands can be sent to the second screen using the Slidy remote that this page will display once the presentation session has started. Key presses and gestures are also supported.

There are a few known restrictions at this stage:


For feedback on the demo or on the Presentation API itself, use the mailing-list (with public archive) or get in touch with Francois Daoust if you do not wish your comment to appear in public.

Feel free to use GitHub issue tracker to report bugs and feature requests.


This work was done with support from the European Commission under grant agreement no: 610404 (MediaScape).