-
Notifications
You must be signed in to change notification settings - Fork 2
Second Screen Community Group Charter
Date: 2013-11-05
The group’s goal is to define an API that allows web applications to use secondary screens to display Web content. Phones, tablets, laptops and other devices support ways to attach additional display screens. Common methods include attaching through video ports or HDMI, or wirelessly through Miracast, WiDi, or AirPlay. Screens can also be attached over a network. For many of these techniques the operating system hides how the screen is attached and provides ways for applications to use the screens. Native apps on an operating system can easily use these additional screens without having to know how they are attached to the device. The goal of this CG is to define simple APIs to request displaying an HTML page on the second screen and some means for the launching page on the first screen to communicate with and control the second page, wherever it is rendered. That API should hide the details of the underlying connection technologies and use familiar, common web technologies for messaging.
Two common modes of second screen us are:
- the second screen mirrors the first screen (e.g. display on the laptop is copied on a TV); and
- extending the first screen and acting as if the second screen is off one edge of the primary screen. In this second case, the content is not the same and apps can run entirely on the second screen (e.g. a remote control on the first screen and a video being played on the second). This group focuses on non-mirrored uses. Other groups could provide lower level APIs that expose features of different connection technologies; this CG won't do that. The user MUST always be in control of permitting use of a second screen and selecting which to use.
The group will produce the following types of deliverables:
The group will develop a Specification for an API to enable displaying an HTML page on a second screen and communicating between the initiating page and the page that is to be displayed on the second screen.
An HTML page on the primary device indicates that it wants to display another HTML page on a second screen. The user is asked for permission and to select which screen to use. The first page is given some familiar means to communicate with the second page. For example, an app in a Web Browser on a smartphone could launch a page containing full screen video on a large TV and then offer remote control from the phone for the video content. Another example would be an app in the Browser on the phone controlling a slides presentation on a large TV. Instead of a Browser, this could be a standalone packaged app that runs outside any Browser. The display on the second screen should be optimized for its screen characteristics (e.g. take advantage of a large screen). The specification created in this CG will make this existing operating system capability available to Web apps in Web Browsers or Web Runtimes (called UA’s below for User Agent). The CG should first enable these simple cases where the operating system already provides the needed underlying support.
Two different styles of APIs have been considered in developing this Charter:
- API for requesting displaying HTML page on second screen that is similar to window.open() creating an auxiliary browsing context for the second HTML page. Instead of appearing in another window or tab, the page appears full screen on the second screen. The interaction between the pages is the same as for pages in two tabs (same origin policy applies). An advantage is that manipulating the second page is through familiar techniques used for second pages in tabs or windows.
OR
- API for requesting displaying HTML page on second screen provides only message passing for communication between the two pages. An advantage to this approach is that it is simpler to support connections to second screens where the second screen can fetch and render HTML itself and the second DOM is remote. In either approach, it may be useful to define control messages similar to those available for the HTML5 Media elements for play, pause, skip to some particular time in a timed display, etc.. That could be split into a second specification produced under this Charter. The CG can use this as starting points or develop another approach. However, these suggested approaches describe the general scope for this specification.
How second screens are connected to the primary device is out of scope (e.g. Video Port, HDMI, WiDi, Miracast, AirPlay). The API abstracts this away and is independent of the means of connecting. This is not a low level API for interacting with specific types of connection. How the UA prepares and sends the screen contents to the second screen is not part of this spec. It is up to the implementation. This second page can be rendered in the UA on the primary device with video sent to the second display like Miracast or a URL could be sent to the second device and it could be rendered there. Those are UA implementations details and not in the scope of the spec. The Contributor License Agreement (CLA) Patent section does apply to Specifications.
High-quality, comprehensive and automated test suites are important interoperability drivers. The group will endeavor to create test suites for each specification it releases. Test Code will be contributed under a 3 clause BSD License. The Contributor License Agreement (CLA) Patent section does not apply to test suites.
The CG can produce use cases or requirements to explore other specifications not in the charter, either to recommend work elsewhere or to propose changes to this Charter. The CG can also produce other reports related to second screen use in HTML5 that are not technical specifications. The Contributor License Agreement (CLA) Patent section does not apply to these non-normative reports.
The group will ONLY produce Specifications listed here. To add any additional specifications, the Charter must be amended by the process described below. All deliverables for which the CLA patent section applies must be designated as such here.
- Non-Normative Reports – CLA patent section does not apply The group may produce reports, as described in the scope section.
- Specifications – CLA patent section applies Second Screen Presentation API as described in the scope section of the Charter.
- Test Suites – Contributions under BSD 3 clause license Test suites will be created for each of the Specifications in the previous section.
- For the reports produced, including use cases, it may be useful to contact members of W3C WGs such as the SysApps WG, Web Apps WG, Web Apps Security WG, CSS WG and many others.
- There are no external specs that must be created before the Specification to be developed here can be completed.
Anything in this charter that conflicts with requirements of the Community and Business Group Process is void.
This group chooses their Chair(s) and can replace the Chair(s) at any time using whatever means they prefer. However, if 5 participants – no two from the same organization – call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).
Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes.
Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual who receives the most votes – no two from the same organization – is elected chair. In case of a tie, RFC2777 is used to break the tie. An elected Chair may appoint co-Chairs. Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
This group will seek to make decisions when there is consensus. When the group discusses an issue on the mailing list and there is a call from the group for assessing consensus, after due consideration of different opinions, the Chair should record a decision and any objections. Participants may call for an online vote if they feel the Chair has not accurately determined the consensus of the group or if the Chair refuses to assess consensus. The call for a vote must specify the duration of the vote which must be at least 7 days and should be no more than 14 days. The Chair must start the vote within 7 days of the request. The decision will be based on the majority of the ballots cast. It is the Chair’s responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favor or discriminate against any group participant or their employer.
The group will conduct all of its technical work on its public mailing list. Any decisions reached at any meeting are tentative and must be confirmed on the mail list.
The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.