From 8be327de6bd7ef36b6bfec5a7ff48d97d0795455 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominik=20R=C3=B6ttsches?= Date: Wed, 2 Jul 2014 14:23:47 +0300 Subject: [PATCH 01/14] Fixed typos that David found. --- Overview.src.html | 8 ++++---- index.html | 12 ++++++------ 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Overview.src.html b/Overview.src.html index 28da559..ee3478e 100644 --- a/Overview.src.html +++ b/Overview.src.html @@ -289,7 +289,7 @@

Conformance

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and terminate these steps") are to be interpreted with the meaning of the -key word ("must", "should", "may", etc) used in introducing the +key word ("must", "should", "may", etc.) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps @@ -376,13 +376,13 @@

Display Selection and Availability

system via wired connections (e.g. HDMI, DVI etc.) as well as via wireless technologies (e.g. MiraCast, DLNA or similar) that use a local or personal area network as a transport mechanism. The - discovery can be performend by using operating system APIs that + discovery can be performed by using operating system APIs that notifiy the user agent about display configuration changes or by means of network discovery for remote display technologies that are not handled by the operating system. In the latter case, the user agent or the operating system that the user agent runs on may prepare a video stream suitable for being decoded and displayed by - the wirelessly connected display.

+ the wirelessly-connected display.

Monitoring for Availability Changes

@@ -534,7 +534,7 @@

Security Considerations

References

-

Acknowledgments

+

Acknowledgements

Thanks to Wayne Carr and Anssi Kostiainen for input, thorough reviews and feedback to this draft.

diff --git a/index.html b/index.html index d5120bd..c6f6933 100644 --- a/index.html +++ b/index.html @@ -7,7 +7,7 @@ } - + + href="http://www.w3.org/community/src/css/spec/cg-final.css" type="text/css"> - + - - - + + - - - -
- -

Presentation API

-

(Draft of) Final Report [DATE]

- -
-
This Version: -
http://webscreens.github.io/presentation-api/
- -
Latest Published Version
-
http://webscreens.github.io/presentation-api/
- -
Previous Version:
-
http://webscreens.github.io/presentation-api/20131112/
- -
Participate:
-
Send feedback to the community group's mailing - list public-webscreens@w3.org, - or create or browse open issues on GitHub. Also, - you may join on the CG's IRC channel. - -
Version History: -
https://github.com/webscreens/presentation-api/commits/
- -
Editors: -
Dominik Röttsches, Intel
-
Anssi Kostiainen, Intel
-
- - -

- Copyright © 2014 the Contributors to the - Presentation API Specification, published by the Second Screen - Presentation Community Group under the - W3C Community Final Specification Agreement (CLA). -

- -
- -
- - -

Abstract

-This document standardizes access to external presentation-type -displays for web applications. - -

Status of this Document

- -This document serves as the final report of the Second Screen Presentation community group. - - +

+ Presentation API +

+

+ (Draft of) Final Report [DATE] +

+
+
+ This Version: +
+
+ http://webscreens.github.io/presentation-api/ + +
+
+ Latest Published Version +
+
+ http://webscreens.github.io/presentation-api/ + +
+
+ Previous Version: +
+
+ http://webscreens.github.io/presentation-api/20131112/ +
+
+ Participate: +
+
+ Send feedback to the community group's mailing list public-webscreens@w3.org, + or create or + browse open issues on GitHub. Also, you may join on the CG's IRC channel. +
+
+ Version History: +
+
+ https://github.com/webscreens/presentation-api/commits/ +
+
+ Editors: +
+
+ Dominik Röttsches, + Intel +
+
+ Anssi Kostiainen, + Intel +
+
+

+ Copyright + © 2014 the Contributors to the Presentation API Specification, + published by the Second Screen Presentation + Community Group under the W3C Community + Final Specification Agreement (CLA). +

+
+ +

+ Abstract +

This document standardizes access to external presentation-type + displays for web applications. +

+ Status of this Document +

This document serves as the final report of the Second Screen + Presentation community group. - - - - - -

Table of Contents

- - -

Introduction

- -This section is non-normative. - -

This specification aims to make secondary displays such as a projector or a connected TV available to the web and -takes into account displays that are attached using wired (HDMI, DVI or similar) and wireless technologies (MiraCast, - Chromecast, DLNA, AirPlay or similar).

- -

Devices with limited screen size lack the ability to show content -to a larger audience, for example a group of colleagues in a -conference room, or friends and family at home. Showing content on an -external large display helps to improve the perceived quality and -impact of the presented content.

- -

Use Cases

- -

Presentations

- -

A user is preparing a set of slides for a talk. Using a web based service, she is editing her slides and speaker -notes on the primary screen, while the secondary larger screen shows a preview of the current slide. When the slides are -done, her mobile phone allows her to access them from an online service while on the go. Coming to the conference, using -wireless display technology, she would like to present her slides on the stage screen from her mobile phone. The phone's -touch screen helps her to navigate slides and presents a slide preview, while the projector shows her slides to the -audience.

-

Requirements: R1, R3, R4, R5, R7

- -

Video and Image Sharing

- -

Using an online video or image sharing service, a user would like to show memorable moments to her friends. Using a - device with a small screen, it is impossible to show the content to a large group of people. Connecting an external - TV screen or projector to her device - with a cable or wirelessly - the online sharing service now makes use of the - connected display, allowing a wider audience to enjoy the content.

-

The web page shows UI elements that allow the user to trigger displaying content on the secondary display (e.g a "send - to second screen" ) only if there is at least one secondary screen available.

-

Requirements: R1, R3, R4, R5, R7

- -

Gaming

- -

Splitting the gaming experience into a near screen controller and a large screen visual experience, new gaming experiences can be created. Accessing the local display on the small screen device and an external larger display allows for richer web-based gaming experiences.

-

Requirements: R1, R3, R4, R5, R7

- -

Media Flinging to Multiple Screens

-Alice enters a video sharing site using a browser on her tablet. Next, Alice picks her favorite video from the site, and -the video starts to play on her tablet. While the video is playing Alice clicks a button "Share on different -screen". The browser provides a user interface that lists all the screens Alice has around her home, asking her to -select one. The screens are identified by names that are familiar to Alice. Alice picks one screen from the list, -"Alice's big TV", and the video playback continues seamlessly on the selected screen. Next she decides to switch the -playback to a different screen. She clicks the same button "Share on different screen" provided by the site, and the -browser presents the user interface that lists all the screens. Alice picks another screen from the list, "Alice's -kitchen TV", and the playback resumes on that screen. Video site also provides a feature to see the action (Alice is -watching a soccer game) from different angle. Alice clicks a button "Select screen for additional angle", and the -browser asks Alice similarly to select the screen to be used for playback. Alice picks "Alice's Projector" and the -soccer game is shown on the projector from a different angle, in parallel to the content being played back on "Alice's -kitchen TV". -

Requirements: R1, R3, R4, R5, R6, R7

- - -

Requirements

- -

Functional Requirements

- +

+ Example +

+

+ Running in a compliant user agent, code for presenting a page + example.html on the presentation display could look like the + following: +

+ 
 /* controller.html */
 
 <button disabled>Show</button>
@@ -298,48 +392,101 @@ 
Example

 }
 </script>
- -

The availability monitoring for secondary screens begins when the page adds an event listener for the availablechange - event on the navigator.presentation object. If there are already available screens when the page adds the first - event listener for the event, the UA synthesizes a single availablechange event to signal the availability.

-

Do we want to fire an event immediately after the page registers for it? What's a best practice - method for asynchronous notifications of ths kind? See below in the Open Questions section.

-

The "Show" button's disabled state (initially disabled) informs the user of the availability of secondary screen(s), - and the button's state is updated if the availability changes. (The rationale of putting the actual boolean - information into a property of the event e.available is to allow the implementation to optimize power consumption - for network discovery of remote wireless screens. If this information was provided in a globally accessible flag, - the network discovery could never be suspended for keeping the flag up to date.)

-

Once the user clicks the "Show" button, the show() function is called.

-

By calling navigator.presentation.requestSession(url), the script on the page tries to launch or resume a - presentation on a secondary screen. Based on the url argument, the UA looks for existing sessions and available - screens, and presents a screen picker user interface to the user. Out of the list of existing sessions or available - screens the user selects one item. If an existing session was selected, the session is resumed by establishing a - communication channel. If a new screen was selected, the UA connects to the selected screen, brings up a new window - on the selected screen, starts to show the content denoted by the url argument, and the UA establishes a - communication channel with this window.

-

When navigator.presentation.requestSession(url) function is called, the UA immediately returns a session object to -the script which represents a handle to the current presentation session, used for communication and state handling.

-

If the user has selected a screen, the content is shown and a communication channel was established, the state of the -session object changes from "disconnected" to "connected", which signals the presentation session is up and running, and -the opener page can communicate with the presentation page. For communication with the presentation page, the session -object's postMessage() is used to send, and the onmessage event handler to receive messages.

-

If the user cancels the screen selection and never selects a screen, no state transition happens and the session - object remains in the "disconnected" state.

- -

Open Questions

-

Do we need to insert into the description an additional permission prompt to grant the page access to the "one ore more screens are available" Information?

-

If there are already connected screens when the page subscribes to the onavailablechange event, we can handle this in two ways: We can synthesize one initial event to notify the page about available screens as soon as the first event handler is installed (as described). Or we can add another message like navigator.presentation.getAvailable(function(available) { } ); to notify the page about available screens using this one-time asynchronous getter. Which way should we go?

-

Do we still need to pass an options parameter to the requestSession() call in order to specify continuous playback or would we leave this an implementation detail to the UA? Given that there is a close() function and disconnect notifications through the state property, this should be sufficient to implement the continuous playback use case.

-

Do we need an additional state like resumed in order to identify resumed session? It seems that - this could be handled on the page level. The opener page could ask the presentation page whether it is "new" or - "resumed".

- -

Usage on Remote Screen

- -For addressing the requirement of communication between originating page and presentation page/screen, we can now use -the same session object on the remote side. - -
+    

+      The availability monitoring for secondary screens begins when the page
+      adds an event listener for the availablechange event on the
+      navigator.presentation object. If there are already available screens
+      when the page adds the first event listener for the event, the UA
+      synthesizes a single availablechange event to signal the availability.
+    

+    

+      Do we want to fire an event immediately after the page registers for it?
+      What's a best practice method for asynchronous notifications of ths kind?
+      See below in the Open Questions section.
+    

+    

+      The "Show" button's disabled state (initially disabled) informs the user
+      of the availability of secondary screen(s), and the button's state is
+      updated if the availability changes. (The rationale of putting the actual
+      boolean information into a property of the event e.available is to allow
+      the implementation to optimize power consumption for network discovery of
+      remote wireless screens. If this information was provided in a globally
+      accessible flag, the network discovery could never be suspended for
+      keeping the flag up to date.)
+    

+    

+      Once the user clicks the "Show" button, the show() function is called.
+    

+    

+      By calling navigator.presentation.requestSession(url), the script on the
+      page tries to launch or resume a presentation on a secondary screen.
+      Based on the url argument, the UA looks for existing sessions and
+      available screens, and presents a screen picker user interface to the
+      user. Out of the list of existing sessions or available screens the user
+      selects one item. If an existing session was selected, the session is
+      resumed by establishing a communication channel. If a new screen was
+      selected, the UA connects to the selected screen, brings up a new window
+      on the selected screen, starts to show the content denoted by the url
+      argument, and the UA establishes a communication channel with this
+      window.
+    

+    

+      When navigator.presentation.requestSession(url) function is called, the
+      UA immediately returns a session object to the script which represents a
+      handle to the current presentation session, used for communication and
+      state handling.
+    

+    

+      If the user has selected a screen, the content is shown and a
+      communication channel was established, the state of the session object
+      changes from "disconnected" to "connected", which signals the
+      presentation session is up and running, and the opener page can
+      communicate with the presentation page. For communication with the
+      presentation page, the session object's postMessage() is used to send,
+      and the onmessage event handler to receive messages.
+    

+    

+      If the user cancels the screen selection and never selects a screen, no
+      state transition happens and the session object remains in the
+      "disconnected" state.
+    

+    

+      Open Questions
+    

+    

+      Do we need to insert into the description an additional permission prompt
+      to grant the page access to the "one ore more screens are available"
+      Information?
+    

+    

+      If there are already connected screens when the page subscribes to the
+      onavailablechange event, we can handle this in two ways: We can
+      synthesize one initial event to notify the page about available screens
+      as soon as the first event handler is installed (as described). Or we can
+      add another message like
+      navigator.presentation.getAvailable(function(available) { } ); to notify
+      the page about available screens using this one-time asynchronous getter.
+      Which way should we go?
+    

+    

+      Do we still need to pass an options parameter to the requestSession()
+      call in order to specify continuous playback or would we leave this an
+      implementation detail to the UA? Given that there is a close() function
+      and disconnect notifications through the state property, this should be
+      sufficient to implement the continuous playback use case.
+    

+    

+      Do we need an additional state like resumed in order to identify resumed
+      session? It seems that this could be handled on the page level. The
+      opener page could ask the presentation page whether it is "new" or
+      "resumed".
+    

+    

+      Usage on Remote Screen
+    
For addressing the requirement of communication between originating
+    page and presentation page/screen, we can now use the same
+    session object on the remote side.
+    
 navigator.presentation.onpresent = function(e) {
   // Communicate with opener page.
   e.session.postMessage(/*...*/);
@@ -353,60 +500,83 @@ 
Usage on Remote Screen

   };
 };
 

-
-
When the content denoted by the url argument in the requestSession() example above is loaded, the page on the
-    presentation screen receives a present event, with a session property representing the session. This session is a
-    similar object as in the first example. Here, its initial state is "connected", which means we can use it to
-    communicate with the opener page using postMessage() and onmessage.

-
We can also monitor the connection state by listening for statechange events. When the state changes to "disconnected"

-
the page is made aware of the fact that communication with the opener page was lost, but it can continue to display
-    the current content. The communication can be re-established when a new present event fires on the
-    navigator.presentation object.
-
-
-
Conformance

-
All diagrams, examples, and notes in this specification are
-non-normative, as are all sections explicitly marked non-normative.
-Everything else in this specification is normative.
-
-
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
-"OPTIONAL" in this document are to be interpreted as described in RFC 2119.
-For readability, these words do not appear in all uppercase letters in this
-specification. RFC2119
-
-
Requirements phrased in the imperative as part of algorithms
-(such as "strip any leading space characters" or "return false and
-terminate these steps") are to be interpreted with the meaning of the
-key word ("must", "should", "may", etc.) used in introducing the
-algorithm.
-
-
Conformance requirements phrased as algorithms or specific steps
-may be implemented in any manner, so long as the end result is
-equivalent. (In particular, the algorithms defined in this
-specification are intended to be easy to follow, and not intended to
-be performant.)
-
-
Terminology

-
-
The term presentation display refers to an external screen connected to the device that the user agent runs on.

-
-
The terms opener browsing context
-    and auxiliary browsing context are defined
-    in HTML5.
-
-
The terms event handlers
-  and event handler event types are
-  defined in HTML5.

-
-
This document provides interface definitions using the WEBIDL standard.

-
-
Interfaces

-
-
NavigatorPresentation

-
-
+    

+      When the content denoted by the url argument in the requestSession()
+      example above is loaded, the page on the presentation screen receives a
+      present event, with a session property representing the session. This
+      session is a similar object as in the first example. Here, its initial
+      state is "connected", which means we can use it to communicate with the
+      opener page using postMessage() and onmessage.
+    

+    

+      We can also monitor the connection state by listening for statechange
+      events. When the state changes to "disconnected"
+    

+    

+      the page is made aware of the fact that communication with the opener
+      page was lost, but it can continue to display the current content. The
+      communication can be re-established when a new present event fires on the
+      navigator.presentation object.
+    

+    

+      Conformance
+    

+    

+      All diagrams, examples, and notes in this specification are
+      non-normative, as are all sections explicitly marked non-normative.
+      Everything else in this specification is normative.
+    

+    

+      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+      "OPTIONAL" in this document are to be interpreted as described in RFC
+      2119. For readability, these words do not appear in all uppercase letters
+      in this specification. RFC2119
+    

+    

+      Requirements phrased in the imperative as part of algorithms (such as
+      "strip any leading space characters" or "return false and terminate these
+      steps") are to be interpreted with the meaning of the key word ("must",
+      "should", "may", etc.) used in introducing the algorithm.
+    

+    

+      Conformance requirements phrased as algorithms or specific steps may be
+      implemented in any manner, so long as the end result is equivalent. (In
+      particular, the algorithms defined in this specification are intended to
+      be easy to follow, and not intended to be performant.)
+    

+    

+      Terminology
+    

+    

+      The term presentation display
+      refers to an external screen connected to the device that the user agent
+      runs on.
+    

+    

+      The terms opener browsing context and auxiliary
+      browsing context are defined in HTML5.
+    

+    

+      The terms event handlers and
+      event
+      handler event types are defined in HTML5.
+    

+    

+      This document provides interface definitions using the
+      WEBIDL standard.
+    

+    

+      Interfaces
+    

+    

+      NavigatorPresentation
+    

+    
 interface NavigatorPresentation : EventTarget {
   PresentationSession requestSession(DOMString url);
   attribute EventHandler onavailablechange;
@@ -417,12 +587,14 @@ 
NavigatorPresentation

   readonly attribute NavigatorPresentation presentation;
 };
 

-
-
AvailableChangeEvent

-
-
Fired at the primary screen's NavigatorPresentation object, when screen availability changes.

-
-
+    

+      AvailableChangeEvent
+    

+    

+      Fired at the primary screen's NavigatorPresentation object,
+      when screen availability changes.
+    

+    
 [Constructor(DOMString type, optional AvailableChangeEventInit eventInitDict)]
 interface AvailableChangeEvent : Event {
   readonly attribute boolean available;
@@ -432,10 +604,11 @@ 
AvailableChangeEvent

   boolean available;
 };
 

-
-
PresentEvent

-Fired at the secondary screen's NavigatorPresentation object, when the presentation session is established.
-
+    

+      PresentEvent
+    
Fired at the secondary screen's NavigatorPresentation
+    object, when the presentation session is established.
+    
 [Constructor(DOMString type, optional PresentEventInit eventInitDict)]
 interface PresentEvent : Event {
   readonly attribute PresentationSession session;
@@ -445,12 +618,13 @@ 
PresentEvent

   PresentationSession session;
 };
 

-
-
PresentationSession

-
-
An object representing the established presentation session.

-
-
+    

+      PresentationSession
+    

+    

+      An object representing the established presentation session.
+    

+    
 enum PresentationSessionState { "connected", "disconnected" /*, "resumed" */ };
 
 interface PresentationSession : EventTarget {
@@ -461,13 +635,16 @@ 
PresentationSession

   attribute EventHandler onstatechange;
 };
 

-
-
References

-

-
-
Acknowledgements

-
-
Thanks to Wayne Carr, Louay Bassbous, Anssi Kostiainen, 闵洪波 (Hongbo Min), Anton Vayvod for help with editing, reviews and feedback to this draft.

-
-
+    

+      References
+    

+    

+    

+      Acknowledgements
+    

+    

+      Thanks to Wayne Carr, Louay Bassbous, Anssi Kostiainen, 闵洪波 (Hongbo Min),
+      Anton Vayvod for help with editing, reviews and feedback to this draft.
+    

+  
 
diff --git a/index.html b/index.html
index 5101b5e..1eb31e1 100644
--- a/index.html
+++ b/index.html
@@ -1,15 +1,16 @@
 
-  
-  Presentation API
-  
-
-  
-  
+    
+    
- 
- 
-
-

- 
+    
+  
+  
+    

+      
 
 
W3C

 
- 
Presentation API

- 
(Draft of) Final Report 2 July 2014

-
- 

-  
This Version:
-  
http://webscreens.github.io/presentation-api/

-
-  
Latest Published Version

-  
http://webscreens.github.io/presentation-api/

-
-  
Previous Version:

-  
http://webscreens.github.io/presentation-api/20131112/

-
-  
Participate:

-  
Send feedback to the community group's mailing
-  list public-webscreens@w3.org,
-  or create or browse open issues on GitHub. Also,
-  you may join on the CG's IRC channel.
-
-  
Version History:
-  
https://github.com/webscreens/presentation-api/commits/

-
-  
Editors:
-      
Dominik Röttsches, Intel

-      
Anssi Kostiainen, Intel

- 

-
-
-

-    Copyright © 2014 the Contributors to the
-    Presentation API Specification, published by the Second Screen
-    Presentation Community Group under the
-    W3C Community Final Specification Agreement (CLA).
-

-
-

-
-

-
-
-
Abstract

-This document standardizes access to external presentation-type
-displays for web applications.
-
-
Status of this Document

-
-This document serves as the final report of the Second Screen Presentation community group.
-
-http://webscreens.github.io/presentation-api/ 
+          
+        
+        

+          Latest Published Version
+        

+        

+          http://webscreens.github.io/presentation-api/ 
+          
+        

+        

+          Previous Version:
+        

+        

+          http://webscreens.github.io/presentation-api/20131112/
+        

+        

+          Participate:
+        

+        

+          Send feedback to the community group's mailing list public-webscreens@w3.org,
+          or create or
+          browse open issues on GitHub. Also, you may join on the CG's IRC channel.
+        

+        

+          Version History:
+        

+        

+          https://github.com/webscreens/presentation-api/commits/
+        

+        

+          Editors:
+        

+        

+          Dominik Röttsches,
+          Intel
+        

+        

+          Anssi Kostiainen,
+          Intel
+        

+      
+      

+        Copyright
+        © 2014 the Contributors to the Presentation API Specification,
+        published by the Second Screen Presentation
+        Community Group under the W3C Community
+        Final Specification Agreement (CLA).
+      

+      

+    

+    

+      Abstract
+    
This document standardizes access to external presentation-type
+    displays for web applications.
+    

+      Status of this Document
+    
This document serves as the final report of the Second Screen
+    Presentation community group. 
-
-
-
-
-
-
Table of Contents

-
+     
+    

+      Table of Contents
+    

 
 
    
- 
  1. 1 Introduction
+ 
  2. 1 
+      Introduction
+    
   
      
-   
    1. 1.1 Use Cases
+   
    2. 1.1 
+      Use Cases
+    
     
        
-     
      1. 1.1.1 Presentations
        2. 
-     
      2. 1.1.2 Video and Image Sharing
        3. 
-     
      3. 1.1.3 Gaming
        4. 
-     
      4. 1.1.4 Media Flinging to Multiple Screens
    3. 
- 
  3. 2 Requirements
+     
  4. 1.1.1 
+      Presentations
+    
    5. 
+     
  5. 1.1.2 
+      Video and Image Sharing
+    
    6. 
+     
  6. 1.1.3 
+      Gaming
+    
    7. 
+     
  7. 1.1.4 
+      Media Flinging to Multiple Screens
+    

+ 
  • 2 
+      Requirements
+    
   
      
-   
    1. 2.1 Functional Requirements
      2. 
-   
    2. 2.2 Non-Functional Requirements
      3. 
-   
    3. 2.3 Example
+   
    4. 2.1 
+      Functional Requirements
+    
      5. 
+   
    5. 2.2 
+      Non-Functional Requirements
+    
      6. 
+   
    6. 2.3 
+      Example
+    
     
        
-     
      1. 2.3.1 Open Questions
      7. 
-   
    7. 2.4 Usage on Remote Screen
    • 
- 
  • 3 Conformance
    • 
- 
  • 4 Terminology
    • 
- 
  • 5 Interfaces
+     
  • 2.3.1 
+      Open Questions
+    
    • 
+   
  • 2.4 
+      Usage on Remote Screen
+    
    • 
+ 
  • 3 
+      Conformance
+    
    • 
+ 
  • 4 
+      Terminology
+    
    • 
+ 
  • 5 
+      Interfaces
+    
   
      
-   
    1. 5.1 NavigatorPresentation
      2. 
-   
    2. 5.2 AvailableChangeEvent
      3. 
-   
    3. 5.3 PresentEvent
      4. 
-   
    4. 5.4 PresentationSession
    • 
- 
  • References
    • 
- 
  • Acknowledgements
+   
  • 5.1 
+      NavigatorPresentation
+    
    • 
+   
  • 5.2 
+      AvailableChangeEvent
+    
    • 
+   
  • 5.3 
+      PresentEvent
+    
    • 
+   
  • 5.4 
+      PresentationSession
+    
    • 
+ 
  • 
+      References
+    
    • 
+ 
  • 
+      Acknowledgements
+    
 
-
-
    1 Introduction
    
-
-This section is non-normative.
-
-
    This specification aims to make secondary displays such as a projector or a connected TV available to the web and
-takes into account displays that are attached using wired (HDMI, DVI or similar) and wireless technologies (MiraCast,
-    Chromecast, DLNA, AirPlay or similar).
    
-
-
    Devices with limited screen size lack the ability to show content
-to a larger audience, for example a group of colleagues in a
-conference room, or friends and family at home. Showing content on an
-external large display helps to improve the perceived quality and
-impact of the presented content.
    
-
-
    1.1 Use Cases
    
-
-
    1.1.1 Presentations
    
-
-
    A user is preparing a set of slides for a talk. Using a web based service, she is editing her slides and speaker
-notes on the primary screen, while the secondary larger screen shows a preview of the current slide. When the slides are
-done, her mobile phone allows her to access them from an online service while on the go. Coming to the conference, using
-wireless display technology, she would like to present her slides on the stage screen from her mobile phone. The phone's
-touch screen helps her to navigate slides and presents a slide preview, while the projector shows her slides to the
-audience.
    
-
    Requirements: R1, R3, R4, R5, R7
    
-
-
    1.1.2 Video and Image Sharing
    
-
-
    Using an online video or image sharing service, a user would like to show memorable moments to her friends. Using a
-    device with a small screen, it is impossible to show the content to a large group of people. Connecting an external
-    TV screen or projector to her device - with a cable or wirelessly - the online sharing service now makes use of the
-    connected display, allowing a wider audience to enjoy the content.
    
-
    The web page shows UI elements that allow the user to trigger displaying content on the secondary display (e.g a "send
-    to second screen" ) only if there is at least one secondary screen available.
    
-
    Requirements: R1, R3, R4, R5, R7
    
-
-
    1.1.3 Gaming
    
-
-
    Splitting the gaming experience into a near screen controller and a large screen visual experience, new gaming experiences can be created. Accessing the local display on the small screen device and an external larger display allows for richer web-based gaming experiences.
    
-
    Requirements: R1, R3, R4, R5, R7
    
-
-
    1.1.4 Media Flinging to Multiple Screens
    
-Alice enters a video sharing site using a browser on her tablet. Next, Alice picks her favorite video from the site, and
-the video starts to play on her tablet. While the video is playing Alice clicks a button "Share on different
-screen". The browser provides a user interface that lists all the screens Alice has around her home, asking her to
-select one. The screens are identified by names that are familiar to Alice. Alice picks one screen from the list,
-"Alice's big TV", and the video playback continues seamlessly on the selected screen. Next she decides to switch the
-playback to a different screen. She clicks the same button "Share on different screen" provided by the site, and the
-browser presents the user interface that lists all the screens. Alice picks another screen from the list, "Alice's
-kitchen TV", and the playback resumes on that screen. Video site also provides a feature to see the action (Alice is
-watching a soccer game) from different angle. Alice clicks a button "Select screen for additional angle", and the
-browser asks Alice similarly to select the screen to be used for playback. Alice picks "Alice's Projector" and the
-soccer game is shown on the projector from a different angle, in parallel to the content being played back on "Alice's
-kitchen TV".
-
    Requirements: R1, R3, R4, R5, R6, R7
    
-
-
-
    2 Requirements
    
-
-
    2.1 Functional Requirements
    
-
      
-    
    •  Discovery / Availability
+    
      1 
+      Introduction
+    
      This section is non-normative.
+    
      
+      This specification aims to make secondary displays such as a projector or
+      a connected TV available to the web and takes into account displays that
+      are attached using wired (HDMI, DVI or similar) and wireless technologies
+      (MiraCast, Chromecast, DLNA, AirPlay or similar).
+    
      
+    
      
+      Devices with limited screen size lack the ability to show content to a
+      larger audience, for example a group of colleagues in a conference room,
+      or friends and family at home. Showing content on an external large
+      display helps to improve the perceived quality and impact of the
+      presented content.
+    
      
+    
      1.1 
+      Use Cases
+    
      
+    
      1.1.1 
+      Presentations
+    
      
+    
      
+      A user is preparing a set of slides for a talk. Using a web based
+      service, she is editing her slides and speaker notes on the primary
+      screen, while the secondary larger screen shows a preview of the current
+      slide. When the slides are done, her mobile phone allows her to access
+      them from an online service while on the go. Coming to the conference,
+      using wireless display technology, she would like to present her slides
+      on the stage screen from her mobile phone. The phone's touch screen helps
+      her to navigate slides and presents a slide preview, while the projector
+      shows her slides to the audience.
+    
      
+    
      
+      Requirements: R1, R3, R4, R5, R7
+    
      
+    
      1.1.2 
+      Video and Image Sharing
+    
      
+    
      
+      Using an online video or image sharing service, a user would like to show
+      memorable moments to her friends. Using a device with a small screen, it
+      is impossible to show the content to a large group of people. Connecting
+      an external TV screen or projector to her device - with a cable or
+      wirelessly - the online sharing service now makes use of the connected
+      display, allowing a wider audience to enjoy the content.
+    
      
+    
      
+      The web page shows UI elements that allow the user to trigger displaying
+      content on the secondary display (e.g a "send to second screen" ) only if
+      there is at least one secondary screen available.
+    
      
+    
      
+      Requirements: R1, R3, R4, R5, R7
+    
      
+    
      1.1.3 
+      Gaming
+    
      
+    
      
+      Splitting the gaming experience into a near screen controller and a large
+      screen visual experience, new gaming experiences can be created.
+      Accessing the local display on the small screen device and an external
+      larger display allows for richer web-based gaming experiences.
+    
      
+    
      
+      Requirements: R1, R3, R4, R5, R7
+    
      
+    
      1.1.4 
+      Media Flinging to Multiple Screens
+    
      Alice enters a video sharing site using a browser on her tablet. Next,
+    Alice picks her favorite video from the site, and the video starts to play
+    on her tablet. While the video is playing Alice clicks a button "Share on
+    different screen". The browser provides a user interface that lists all the
+    screens Alice has around her home, asking her to select one. The screens
+    are identified by names that are familiar to Alice. Alice picks one screen
+    from the list, "Alice's big TV", and the video playback continues
+    seamlessly on the selected screen. Next she decides to switch the playback
+    to a different screen. She clicks the same button "Share on different
+    screen" provided by the site, and the browser presents the user interface
+    that lists all the screens. Alice picks another screen from the list,
+    "Alice's kitchen TV", and the playback resumes on that screen. Video site
+    also provides a feature to see the action (Alice is watching a soccer game)
+    from different angle. Alice clicks a button "Select screen for additional
+    angle", and the browser asks Alice similarly to select the screen to be
+    used for playback. Alice picks "Alice's Projector" and the soccer game is
+    shown on the projector from a different angle, in parallel to the content
+    being played back on "Alice's kitchen TV".
+    
      
+      Requirements: R1, R3, R4, R5, R6, R7
+    
      
+    
      2 
+      Requirements
+    
      
+    
      2.1 
+      Functional Requirements
+    
      
+    
        
+      
      • 
+        Discovery / Availability
         
          
-            
        •  R1: The UA must provide a way to find out whether at least one secondary screen is available.            
          • 
+          
        • R1: The UA must provide a way to find out whether at least one
+          secondary screen is available.
+          
          • 
         
        
-    
        • 
-
      
-
      Multi-Screen enumeration and named identification removed, after discussion on the mailing list, cmp. http://lists.w3.org/Archives/Public/public-webscreens/2014Feb/0021.html :
-
        
-    
      •  Launching Presentation
+      
        • 
+    
      
+    
      
+      Multi-Screen enumeration and named identification removed, after
+      discussion on the mailing list, cmp. 
+      http://lists.w3.org/Archives/Public/public-webscreens/2014Feb/0021.html :
+    
      
+    
        
+      
      • 
+        Launching Presentation
         
          
-            
        •  R3: The UA must provide a means of start sending content to the secondary screen.
          • 
+          
        • R3: The UA must provide a means of start sending content to the
+          secondary screen.
+          
          • 
         
        
-    
        • 
-    
      •  Resuming Presentation
+      
        • 
+      
      • 
+        Resuming Presentation
         
          
-            
        •  R4: The UA must be able to resume an existing session with content being displayed on the secondary screen. 
-            
          • 
+          
        • R4: The UA must be able to resume an existing session with
+          content being displayed on the secondary screen.
+          
          • 
         
        
-    
        • 
-    
      •  Communication
+      
        • 
+      
      • 
+        Communication
         
          
-            
        •  R5: The UA must enable exchanging data between the primary and the secondary screen in order to have a
-            control channel between the primary and secondary page.
          • 
-            
        •  R6: The UA must not make assumptions about the the execution locality of the user agent of the remote
-            page it communicates with (i.e. the secondary page might run on a remote user agent and thus the link
-            between the two pages' UA must be loosely coupled).
          • 
+          
        • R5: The UA must enable exchanging data between the primary and
+          the secondary screen in order to have a control channel between the
+          primary and secondary page.
+          
          • 
+          
        • R6: The UA must not make assumptions about the the execution
+          locality of the user agent of the remote page it communicates with
+          (i.e. the secondary page might run on a remote user agent and thus
+          the link between the two pages' UA must be loosely coupled).
+          
          • 
         
        
-    
        • 
-
      
-
        
-    
      •  Signaling Disconnection
+      
        • 
+    
      
+    
        
+      
      • 
+        Signaling Disconnection
         
          
-            
        •  R7: The UA must signal disconnection from the presentation page to the primary page and vice versa.
-            
          • 
+          
        • R7: The UA must signal disconnection from the presentation page
+          to the primary page and vice versa.
+          
          • 
         
        
-    
        • 
-
      
-
      2.2 Non-Functional Requirements
      
-
        
-    
      • Power Saving Friendly
+      
        • 
+    
      
+    
      2.2 
+      Non-Functional Requirements
+    
      
+    
        
+      
      • 
+        Power Saving Friendly
         
          
-            
        •  All API design decisions must be analyzed from a power efficiency point of view. Especially when using wireless display technologies or querying availability anything over a radio channel, care needs to be taken to design the API in a way that does not pose obstacles to using radio resources in an efficient way. For example, powering up the wireless display detection only when needed.
-            
          • 
+          
        • All API design decisions must be analyzed from a power efficiency
+          point of view. Especially when using wireless display technologies or
+          querying availability anything over a radio channel, care needs to be
+          taken to design the API in a way that does not pose obstacles to
+          using radio resources in an efficient way. For example, powering up
+          the wireless display detection only when needed.
+          
          • 
         
        
-    
        • 
-
      
-
-
      2.3 Example
      
-
-
      Running in a compliant user agent, code for presenting a page example.html on the presentation display could look like the following:
      
-
-
      /* controller.html */
+      
      • 
+    
    
+    
    2.3 
+      Example
+    
    
+    
    
+      Running in a compliant user agent, code for presenting a page
+      example.html on the presentation display could look like the
+      following:
+    
    
+    
    /* controller.html */
 
 <button disabled>Show</button>
 
@@ -326,48 +457,101 @@ 
    2.3 Example
    
 }
 </script>
 
    
-
-
    The availability monitoring for secondary screens begins when the page adds an event listener for the availablechange
-    event on the navigator.presentation object. If there are already available screens when the page adds the first
-    event listener for the event, the UA synthesizes a single availablechange event to signal the availability.
    
-
    Do we want to fire an event immediately after the page registers for it? What's a best practice
-    method for asynchronous notifications of ths kind? See below in the Open Questions section.
    
-
    The "Show" button's disabled state (initially disabled) informs the user of the availability of secondary screen(s),
-    and the button's state is updated if the availability changes. (The rationale of putting the actual boolean
-    information into a property of the event e.available is to allow the implementation to optimize power consumption
-    for network discovery of remote wireless screens. If this information was provided in a globally accessible flag,
-    the network discovery could never be suspended for keeping the flag up to date.)
    
-
    Once the user clicks the "Show" button, the show() function is called.
    
-
    By calling navigator.presentation.requestSession(url), the script on the page tries to launch or resume a
-    presentation on a secondary screen. Based on the url argument, the UA looks for existing sessions and available
-    screens, and presents a screen picker user interface to the user. Out of the list of existing sessions or available
-    screens the user selects one item. If an existing session was selected, the session is resumed by establishing a
-    communication channel. If a new screen was selected, the UA connects to the selected screen, brings up a new window
-    on the selected screen, starts to show the content denoted by the url argument, and the UA establishes a
-    communication channel with this window.
    
-
    When navigator.presentation.requestSession(url) function is called, the UA immediately returns a session object to
-the script which represents a handle to the current presentation session, used for communication and state handling.
    
-
    If the user has selected a screen, the content is shown and a communication channel was established, the state of the
-session object changes from "disconnected" to "connected", which signals the presentation session is up and running, and
-the opener page can communicate with the presentation page. For communication with the presentation page, the session
-object's postMessage() is used to send, and the onmessage event handler to receive messages.
    
-
    If the user cancels the screen selection and never selects a screen, no state transition happens and the session
-    object remains in the "disconnected" state.
    
-
-
    2.3.1 Open Questions
    
-
    Do we need to insert into the description an additional permission prompt to grant the page access to the "one ore more screens are available" Information?
    
-
    If there are already connected screens when the page subscribes to the onavailablechange event, we can handle this in two ways: We can synthesize one initial event to notify the page about available screens as soon as the first event handler is installed (as described). Or we can add another message like navigator.presentation.getAvailable(function(available) { } ); to notify the page about available screens using this one-time asynchronous getter. Which way should we go?
    
-
    Do we still need to pass an options parameter to the requestSession() call in order to specify continuous playback or would we leave this an implementation detail to the UA? Given that there is a close() function and disconnect notifications through the state property, this should be sufficient to implement the continuous playback use case.
    
-
    Do we need an additional state like resumed in order to identify resumed session? It seems that
-    this could be handled on the page level. The opener page could ask the presentation page whether it is "new" or
-    "resumed".
    
-
-
    2.4 Usage on Remote Screen
    
-
-For addressing the requirement of communication between originating page and presentation page/screen, we can now use
-the same session object on the remote side.
-
-
    navigator.presentation.onpresent = function(e) {
+    
    
+      The availability monitoring for secondary screens begins when the page
+      adds an event listener for the availablechange event on the
+      navigator.presentation object. If there are already available screens
+      when the page adds the first event listener for the event, the UA
+      synthesizes a single availablechange event to signal the availability.
+    
    
+    
    
+      Do we want to fire an event immediately after the page registers for it?
+      What's a best practice method for asynchronous notifications of ths kind?
+      See below in the Open Questions section.
+    
    
+    
    
+      The "Show" button's disabled state (initially disabled) informs the user
+      of the availability of secondary screen(s), and the button's state is
+      updated if the availability changes. (The rationale of putting the actual
+      boolean information into a property of the event e.available is to allow
+      the implementation to optimize power consumption for network discovery of
+      remote wireless screens. If this information was provided in a globally
+      accessible flag, the network discovery could never be suspended for
+      keeping the flag up to date.)
+    
    
+    
    
+      Once the user clicks the "Show" button, the show() function is called.
+    
    
+    
    
+      By calling navigator.presentation.requestSession(url), the script on the
+      page tries to launch or resume a presentation on a secondary screen.
+      Based on the url argument, the UA looks for existing sessions and
+      available screens, and presents a screen picker user interface to the
+      user. Out of the list of existing sessions or available screens the user
+      selects one item. If an existing session was selected, the session is
+      resumed by establishing a communication channel. If a new screen was
+      selected, the UA connects to the selected screen, brings up a new window
+      on the selected screen, starts to show the content denoted by the url
+      argument, and the UA establishes a communication channel with this
+      window.
+    
    
+    
    
+      When navigator.presentation.requestSession(url) function is called, the
+      UA immediately returns a session object to the script which represents a
+      handle to the current presentation session, used for communication and
+      state handling.
+    
    
+    
    
+      If the user has selected a screen, the content is shown and a
+      communication channel was established, the state of the session object
+      changes from "disconnected" to "connected", which signals the
+      presentation session is up and running, and the opener page can
+      communicate with the presentation page. For communication with the
+      presentation page, the session object's postMessage() is used to send,
+      and the onmessage event handler to receive messages.
+    
    
+    
    
+      If the user cancels the screen selection and never selects a screen, no
+      state transition happens and the session object remains in the
+      "disconnected" state.
+    
    
+    
    2.3.1 
+      Open Questions
+    
    
+    
    
+      Do we need to insert into the description an additional permission prompt
+      to grant the page access to the "one ore more screens are available"
+      Information?
+    
    
+    
    
+      If there are already connected screens when the page subscribes to the
+      onavailablechange event, we can handle this in two ways: We can
+      synthesize one initial event to notify the page about available screens
+      as soon as the first event handler is installed (as described). Or we can
+      add another message like
+      navigator.presentation.getAvailable(function(available) { } ); to notify
+      the page about available screens using this one-time asynchronous getter.
+      Which way should we go?
+    
    
+    
    
+      Do we still need to pass an options parameter to the requestSession()
+      call in order to specify continuous playback or would we leave this an
+      implementation detail to the UA? Given that there is a close() function
+      and disconnect notifications through the state property, this should be
+      sufficient to implement the continuous playback use case.
+    
    
+    
    
+      Do we need an additional state like resumed in order to identify resumed
+      session? It seems that this could be handled on the page level. The
+      opener page could ask the presentation page whether it is "new" or
+      "resumed".
+    
    
+    
    2.4 
+      Usage on Remote Screen
+    
    For addressing the requirement of communication between originating
+    page and presentation page/screen, we can now use the same
+    session object on the remote side.
+    
    navigator.presentation.onpresent = function(e) {
   // Communicate with opener page.
   e.session.postMessage(/*...*/);
   e.session.onmessage = function() {/*...*/};
@@ -380,59 +564,79 @@ 
    2.4 Usage on Remote S
   };
 };
 
    
-
-
    When the content denoted by the url argument in the requestSession() example above is loaded, the page on the
-    presentation screen receives a present event, with a session property representing the session. This session is a
-    similar object as in the first example. Here, its initial state is "connected", which means we can use it to
-    communicate with the opener page using postMessage() and onmessage.
    
-
    We can also monitor the connection state by listening for statechange events. When the state changes to "disconnected"
    
-
    the page is made aware of the fact that communication with the opener page was lost, but it can continue to display
-    the current content. The communication can be re-established when a new present event fires on the
-    navigator.presentation object.
-
-
-
    3 Conformance
    
-
    All diagrams, examples, and notes in this specification are
-non-normative, as are all sections explicitly marked non-normative.
-Everything else in this specification is normative.
-
-
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
-"OPTIONAL" in this document are to be interpreted as described in RFC 2119.
-For readability, these words do not appear in all uppercase letters in this
-specification. [RFC2119]
-
-
    Requirements phrased in the imperative as part of algorithms
-(such as "strip any leading space characters" or "return false and
-terminate these steps") are to be interpreted with the meaning of the
-key word ("must", "should", "may", etc.) used in introducing the
-algorithm.
-
-
    Conformance requirements phrased as algorithms or specific steps
-may be implemented in any manner, so long as the end result is
-equivalent. (In particular, the algorithms defined in this
-specification are intended to be easy to follow, and not intended to
-be performant.)
-
-
    4 Terminology
    
-
-
    The term presentation display refers to an external screen connected to the device that the user agent runs on.
    
-
-
    The terms opener browsing context
-    and auxiliary browsing context are defined
-    in [HTML5].
-
-
    The terms event handlers
-  and event handler event types are
-  defined in [HTML5].
    
-
-
    This document provides interface definitions using the [WEBIDL] standard.
    
-
-
    5 Interfaces
    
-
-
-
-
    interface NavigatorPresentation : EventTarget {
+    
    
+      When the content denoted by the url argument in the requestSession()
+      example above is loaded, the page on the presentation screen receives a
+      present event, with a session property representing the session. This
+      session is a similar object as in the first example. Here, its initial
+      state is "connected", which means we can use it to communicate with the
+      opener page using postMessage() and onmessage.
+    
    
+    
    
+      We can also monitor the connection state by listening for statechange
+      events. When the state changes to "disconnected"
+    
    
+    
    
+      the page is made aware of the fact that communication with the opener
+      page was lost, but it can continue to display the current content. The
+      communication can be re-established when a new present event fires on the
+      navigator.presentation object.
+    
    
+    
    3 
+      Conformance
+    
    
+    
    
+      All diagrams, examples, and notes in this specification are
+      non-normative, as are all sections explicitly marked non-normative.
+      Everything else in this specification is normative.
+    
    
+    
    
+      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+      "OPTIONAL" in this document are to be interpreted as described in RFC
+      2119. For readability, these words do not appear in all uppercase letters
+      in this specification. [RFC2119]
+    
    
+    
    
+      Requirements phrased in the imperative as part of algorithms (such as
+      "strip any leading space characters" or "return false and terminate these
+      steps") are to be interpreted with the meaning of the key word ("must",
+      "should", "may", etc.) used in introducing the algorithm.
+    
    
+    
    
+      Conformance requirements phrased as algorithms or specific steps may be
+      implemented in any manner, so long as the end result is equivalent. (In
+      particular, the algorithms defined in this specification are intended to
+      be easy to follow, and not intended to be performant.)
+    
    
+    
    4 
+      Terminology
+    
    
+    
    
+      The term presentation display
+      refers to an external screen connected to the device that the user agent
+      runs on.
+    
    
+    
    
+      The terms opener browsing context and auxiliary
+      browsing context are defined in [HTML5].
+    
    
+    
    
+      The terms event handlers and
+      event
+      handler event types are defined in [HTML5].
+    
    
+    
    
+      This document provides interface definitions using the
+      [WEBIDL] standard.
+    
    
+    
    5 
+      Interfaces
+    
    
+    
+    
    interface NavigatorPresentation : EventTarget {
   PresentationSession requestSession(DOMString url);
   attribute EventHandler onavailablechange;
   attribute EventHandler onpresent;
@@ -442,12 +646,14 @@ 
    
-
-
    5.2 AvailableChangeEvent
    
-
-
    Fired at the primary screen's NavigatorPresentation object, when screen availability changes.
    
-
-
    [Constructor(DOMString type, optional AvailableChangeEventInit eventInitDict)]
+    
    5.2 
+      AvailableChangeEvent
+    
    
+    
    
+      Fired at the primary screen's NavigatorPresentation object,
+      when screen availability changes.
+    
    
+    
    [Constructor(DOMString type, optional AvailableChangeEventInit eventInitDict)]
 interface AvailableChangeEvent : Event {
   readonly attribute boolean available;
 };
@@ -456,10 +662,11 @@ 
    5.2 AvailableChan
   boolean available;
 };
 
    
-
-
    5.3 PresentEvent
    
-Fired at the secondary screen's NavigatorPresentation object, when the presentation session is established.
-
    [Constructor(DOMString type, optional PresentEventInit eventInitDict)]
+    
    5.3 
+      PresentEvent
+    
    Fired at the secondary screen's NavigatorPresentation
+    object, when the presentation session is established.
+    
    [Constructor(DOMString type, optional PresentEventInit eventInitDict)]
 interface PresentEvent : Event {
   readonly attribute PresentationSession session;
 };
@@ -468,12 +675,13 @@ 
    5.3 PresentEvent
-
-
    5.4 PresentationSession
    
-
-
    An object representing the established presentation session.
    
-
-
    enum PresentationSessionState { "connected", "disconnected" /*, "resumed" */ };
+    
    5.4 
+      PresentationSession
+    
    
+    
    
+      An object representing the established presentation session.
+    
    
+    
    enum PresentationSessionState { "connected", "disconnected" /*, "resumed" */ };
 
 interface PresentationSession : EventTarget {
   readonly attribute PresentationSessionState state;
@@ -483,9 +691,10 @@ 
    5.4 PresentationSe
   attribute EventHandler onstatechange;
 };
 
    
-
-
    References
    
-
    [HTML5]
+    
    
+      References
+    
    
+    
    [HTML5]
 
    HTML5, Robin Berjon, Steve Faulkner, Travis Leithead et al.. W3C.
 
 
    [RFC2119]
@@ -495,10 +704,12 @@ 
    References
    
 
    Web IDL, Cameron McCormack. W3C.
 
 
    
-
-
    Acknowledgements
    
-
-
    Thanks to Wayne Carr, Louay Bassbous, Anssi Kostiainen, 闵洪波 (Hongbo Min), Anton Vayvod for help with editing, reviews and feedback to this draft.
    
-
-
+    
    
+      Acknowledgements
+    
    
+    
    
+      Thanks to Wayne Carr, Louay Bassbous, Anssi Kostiainen, 闵洪波 (Hongbo Min),
+      Anton Vayvod for help with editing, reviews and feedback to this draft.
+    
    
+  
 

From 1cd6c8676ab2ea39d051cf5e47dd127f5fabe290 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dominik=20R=C3=B6ttsches?= 
Date: Wed, 2 Jul 2014 16:05:26 +0300
Subject: [PATCH 07/14] Moving Conformance and Terminology sections, minor
 fixes.

---
 Overview.src.html | 238 ++++++++++++++++++++-------------------
 index.html        | 275 +++++++++++++++++++++++-----------------------
 2 files changed, 252 insertions(+), 261 deletions(-)

diff --git a/Overview.src.html b/Overview.src.html
index d9ec88d..0f16dad 100644
--- a/Overview.src.html
+++ b/Overview.src.html
@@ -123,8 +123,8 @@ 
    
           Intel
         
         
    
-          Anssi Kostiainen,
-          Intel
+          Anssi Kostiainen,
+          Intel
         
    
       
    
       
    
@@ -145,8 +145,9 @@ 
    
     displays for web applications.
     
    
       Status of this Document
-    
    This document serves as the final report of the Second Screen
-    Presentation community group. 
-     
-    
-     
+    
+    
    
+      This specification was published by the Second Screen Presentation
+      Community Group. It is not a W3C Standard nor is it on the W3C
+      Standards Track. Please note that under the W3C Community Final
+      Specification Agreement (FSA) other conditions apply. Learn more
+      about W3C Community and Business
+      Groups.
+    
    
+    
    
+      This report documents the use cases, requirements, examples, and other
+      feedback on the general approach of the Presentation API as discussed in
+      the Second Screen Presentation Community Group. Additionally, it
+      documents the interfaces that represent an evolved version of the
+      Presentation API to the extend discussed in the group. The previous version
+      of the Presentation API was used as a starting point for this work.
+    
    
     
    
       Table of Contents
     
    
diff --git a/index.html b/index.html
index 347716c..af34983 100644
--- a/index.html
+++ b/index.html
@@ -144,41 +144,23 @@ 
    
     
    
     
    
       Status of this Document
-    
    This document serves as the final report of the Second Screen Presentation
-    community group. 
-     
-    
-     
+    
+    
    
+      This specification was published by the Second Screen Presentation
+      Community Group. It is not a W3C Standard nor is it on the W3C
+      Standards Track. Please note that under the W3C Community Final
+      Specification Agreement (FSA) other conditions apply. Learn more
+      about W3C Community and Business
+      Groups.
+    
    
+    
    
+      This report documents the use cases, requirements, examples, and other
+      feedback on the general approach of the Presentation API as discussed in
+      the Second Screen Presentation Community Group. Additionally, it
+      documents the interfaces that represent an evolved version of the
+      Presentation API to the extend discussed in the group. The previous version
+      of the Presentation API was used as a starting point for this work.
+    
    
     
    
       Table of Contents
     
    

From 6d26955c32e1ad7716e285808a5cff547c688424 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dominik=20R=C3=B6ttsches?= 
Date: Thu, 3 Jul 2014 11:20:03 +0300
Subject: [PATCH 11/14] Extended introduction for the Interfaces section.
 Addresses github issue #3.

---
 Overview.src.html | 14 +++++++++++++-
 index.html        | 13 ++++++++++++-
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Overview.src.html b/Overview.src.html
index 0c8e2f5..41e0eb0 100644
--- a/Overview.src.html
+++ b/Overview.src.html
@@ -92,7 +92,7 @@ 
    
           
         
         
    
-          Previous Version:
+          Previous Version:
         
    
         
    
           
     
    
       Interfaces
     
    
+    
    
+      The interfaces described herein address the requirements outlined in the
+      Use Cases section, and specifically, also
+      consider the Media Flinging
+      to Multiple Screens use case unaddressed by the previous version of the Presentation API. This
+      section describes the interfaces to the extend discussed in the Second
+      Screen Presentation Community Group. Readers are encouraged to consult
+      the Example section together with this section for
+      a more complete understanding of the technical parts of this
+      specification.
+    
    
     
    
       NavigatorPresentation
     
    
diff --git a/index.html b/index.html
index af34983..28b92ab 100644
--- a/index.html
+++ b/index.html
@@ -94,7 +94,7 @@ 
    
           
         
    
         
    
-          Previous Version:
+          Previous Version:
         
    
         
    
           http://webscreens.github.io/presentation-api/20131112/
@@ -615,6 +615,17 @@ 
    5.2 
     
    6 
       Interfaces
     
    
+    
    
+      The interfaces described herein address the requirements outlined in the
+      Use Cases section, and specifically, also
+      consider the Media Flinging
+      to Multiple Screens use case unaddressed by the previous version of the Presentation API. This
+      section describes the interfaces to the extend discussed in the Second
+      Screen Presentation Community Group. Readers are encouraged to consult
+      the Example section together with this section for
+      a more complete understanding of the technical parts of this
+      specification.
+    
    
     

From b0facf977c015f19d2ab7cb4c0d33e87062dff51 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dominik=20R=C3=B6ttsches?= 
Date: Thu, 3 Jul 2014 11:24:05 +0300
Subject: [PATCH 12/14] Removed (Draft of) status

---
 Overview.src.html | 2 +-
 index.html        | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Overview.src.html b/Overview.src.html
index 41e0eb0..6c96f6b 100644
--- a/Overview.src.html
+++ b/Overview.src.html
@@ -74,7 +74,7 @@ 
    
         Presentation API
       
    
       
    
-        (Draft of) Final Report [DATE]
+        Final Report [DATE]
       
    
       
    
         
    
diff --git a/index.html b/index.html
index 28b92ab..7e11632 100644
--- a/index.html
+++ b/index.html
@@ -73,8 +73,8 @@
       
    
         Presentation API
       
    
-      
    
-        (Draft of) Final Report 3 July 2014
+      
    
+        Final Report 3 July 2014
       
    
       
    
         
    

From b436446f1bce3f30dd466257903e4b41c624b7bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dominik=20R=C3=B6ttsches?= 
Date: Thu, 3 Jul 2014 11:43:03 +0300
Subject: [PATCH 13/14] Anssi removed as editor.

---
 Overview.src.html | 4 ----
 index.html        | 4 ----
 2 files changed, 8 deletions(-)

diff --git a/Overview.src.html b/Overview.src.html
index 6c96f6b..bd86ab2 100644
--- a/Overview.src.html
+++ b/Overview.src.html
@@ -122,10 +122,6 @@ 
    
           Dominik Röttsches,
           Intel
         
    
-        
    
-          Anssi Kostiainen,
-          Intel
-        
    
       
       
    
         
           Dominik Röttsches,
           Intel
         
-        
    
-          Anssi Kostiainen,
-          Intel
-        
    
       
       
    
         Copyright

From 9cd2840fa20ad2432f50858ee0ef6198a8f2353f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dominik=20R=C3=B6ttsches?= 
Date: Thu, 3 Jul 2014 17:42:17 +0300
Subject: [PATCH 14/14] Incorporated Francois' suggestions.

---
 Overview.src.html | 27 ++++++++++++++-------------
 index.html        | 34 +++++++++++++++++++---------------
 2 files changed, 33 insertions(+), 28 deletions(-)

diff --git a/Overview.src.html b/Overview.src.html
index bd86ab2..98e7317 100644
--- a/Overview.src.html
+++ b/Overview.src.html
@@ -157,13 +157,14 @@ 
    
       Groups.
     
    
     
    
-      This report documents the use cases, requirements, examples, and other
-      feedback on the general approach of the Presentation API as discussed in
-      the Second Screen Presentation Community Group. Additionally, it
-      documents the interfaces that represent an evolved version of the
-      Presentation API to the extend discussed in the group. The previous version
-      of the Presentation API was used as a starting point for this work.
+      This report documents the use cases, requirements, examples and
+      interfaces needed to enable web pages to display web content on secondary
+      screens. It is an evolved version of the initial
+      Presentation API that represents the result of discussions within the
+      Second Screen Presentation Community Group so far. API semantics still
+      need to be specified. The report may serve as starting point for a
+      possible Working Group chartered to work on the same topic.
     
    
     
    
       Table of Contents
@@ -332,10 +333,10 @@ 
    
         
      
           
    • All API design decisions must be analyzed from a power efficiency
           point of view. Especially when using wireless display technologies or
-          querying availability anything over a radio channel, care needs to be
-          taken to design the API in a way that does not pose obstacles to
-          using radio resources in an efficient way. For example, powering up
-          the wireless display detection only when needed.
+          querying availability over a radio channel, care needs to be taken to
+          design the API in a way that does not pose obstacles to using radio
+          resources in an efficient way. For example, powering up the wireless
+          display detection only when needed.
           
      • 
         
    
       
    • 
@@ -374,14 +375,14 @@ 
    
       The term presentation display
       refers to an external screen connected to the device that the user agent
       runs on.
-    
    
-    
    
+    
    
     
    
       The terms event handlers and
       event
diff --git a/index.html b/index.html
index 1e0be3c..d16885e 100644
--- a/index.html
+++ b/index.html
@@ -150,12 +150,13 @@ 
    
       Groups.
     
    
     
    
-      This report documents the use cases, requirements, examples, and other
-      feedback on the general approach of the Presentation API as discussed in
-      the Second Screen Presentation Community Group. Additionally, it
-      documents the interfaces that represent an evolved version of the
-      Presentation API to the extend discussed in the group. The previous version
-      of the Presentation API was used as a starting point for this work.
+      This report documents the use cases, requirements, examples and
+      interfaces needed to enable web pages to display web content on secondary
+      screens. It is an evolved version of the initial
+      Presentation API that represents the result of discussions within the
+      Second Screen Presentation Community Group so far. API semantics still
+      need to be specified. The report may serve as starting point for a
+      possible Working Group chartered to work on the same topic.
     
    
     
    
       Table of Contents
@@ -393,10 +394,10 @@ 
    2.2 
         
      
           
    • All API design decisions must be analyzed from a power efficiency
           point of view. Especially when using wireless display technologies or
-          querying availability anything over a radio channel, care needs to be
-          taken to design the API in a way that does not pose obstacles to
-          using radio resources in an efficient way. For example, powering up
-          the wireless display detection only when needed.
+          querying availability over a radio channel, care needs to be taken to
+          design the API in a way that does not pose obstacles to using radio
+          resources in an efficient way. For example, powering up the wireless
+          display detection only when needed.
           
      • 
         
    
       
@@ -435,11 +436,14 @@ 
    4 
       The term presentation display
       refers to an external screen connected to the device that the user agent
       runs on.
-    
    
-    
    
-      The terms opener browsing context and auxiliary
-      browsing context are defined in [HTML5].
-    
    
+    
    
     
    
       The terms event handlers and
       event