This specification defines an API to enable Web content to access
presentation displays and use them for presenting Web content.
Status of This Document
This section describes the status of this
document at the time of its publication. A list of current W3C
publications and the latest revision of this technical report can be found
in the W3C technical reports index at
https://www.w3.org/TR/.
Since publication as Candidate Recommendation on 01 June
2017, the Working Group updated the steps to construct a
PresentationRequest to ignore a URL with an unsupported
scheme, placed further restrictions on how receiving browsing contexts
are allowed to navigate themselves, and dropped the definition of the
BinaryType enum in favor of the one defined in the HTML
specification. Other interfaces defined in this document did not change
other than to adjust to WebIDL updates. Various clarifications and
editorial updates were also made. See the list of changes for details.
No feature has been identified as being at risk.
The Second Screen Working Group will refine the test suite for the
Presentation API during the Candidate Recommendation period and update
the preliminary
implementation report. For this specification to advance to
Proposed Recommendation, two independent, interoperable implementations
of each feature must be demonstrated, as detailed in the Candidate Recommendation exit
criteria section.
Publication as a Candidate Recommendation does not
imply endorsement by W3C and its Members. A Candidate Recommendation Draft integrates
changes from the previous Candidate Recommendation that the Working Group
intends to include in a subsequent Candidate Recommendation Snapshot.
This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than work in progress.
This document was produced by a group
operating under the
W3C Patent
Policy.
W3C maintains a
public list of any patent disclosures
made in connection with the deliverables of
the group; that page also includes
instructions for disclosing a patent. An individual who has actual
knowledge of a patent which the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
The Presentation API aims to make presentation displays such as
projectors, attached monitors, and network-connected TVs available to
the Web. It 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 Web content
to a larger audience: a group of colleagues in a conference room, or
friends and family at home, for example. Web content shown on a larger
presentation display has greater perceived quality, legibility,
and impact.
At its core, the Presentation API enables a controller page to
show a presentation page
on a presentation display and exchange messages with it. How the
presentation page is transmitted to the display and how messages are
exchanged between it and the controller page are left to the
implementation; this allows the use of a wide variety of display
technologies.
For example, if the presentation display is connected by HDMI or
Miracast, which only allow audio and video to be transmitted, the user
agent (UA) hosting the controller will also render the presentation. It then uses the
operating system to send the resulting graphical and audio output to
the presentation display. We refer to this situation as the
1-UA mode implementation of the Presentation
API. The only requirements are that the user agent is able to send
graphics and audio from rendering the presentation to the presentation
display, and exchange messages internally between the controller and
presentation pages.
If the presentation display is able to render HTML natively and
communicate with the controller via a network, the user agent
hosting the controller does not need to render the presentation. Instead, the user
agent acts as a proxy that requests the presentation display to load
and render the presentation page itself. Message exchange is done over
a network connection between the user agent and the presentation
display. We refer to this situation as the 2-UA
mode implementation of the Presentation API.
The Presentation API is intended to be used with user agents that
attach to presentation displays in 1-UA mode, 2-UA
mode, and possibly other means not listed above. To improve
interoperability between user agents and presentation displays,
standardization of network communication between browsers and displays
is being considered in the Second Screen Community
Group.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, OPTIONAL, SHOULD, and SHOULD NOT in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
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 result is equivalent. (In
particular, the algorithms defined in this specification are intended
to be easy to follow, and not intended to be performant.)
3.1
Conformance classes
This specification describes the conformance criteria for two classes
of user agents.
The term reload a document refers to steps run when the
reload() method gets called in [HTML].
The term local storage area refers to the storage areas
exposed by the localStorage attribute, and the
term session storage area refers to the storage areas
exposed by the sessionStorage attribute in
[HTML].
This specification references terms exported by other specifications,
see B.2 Terms defined by reference. It also references the
following internal concepts from other specifications:
This section shows example codes that highlight the usage of main
features of the Presentation API. In these examples,
controller.html implements the controller and
presentation.html implements the presentation. Both pages
are served from the domain https://example.org
(https://example.org/controller.html and
https://example.org/presentation.html). These examples
assume that the controlling page is managing one presentation at a
time. Please refer to the comments in the code examples for further
details.
5.1
Monitoring availability of presentation displays
This code renders a button that is visible when there is at least one
compatible presentation display that can present
https://example.com/presentation.htmlorhttps://example.net/alternate.html.
Monitoring of display availability is done by first creating a
PresentationRequest with the URLs you want to present, then
calling getAvailability to
obtain a PresentationAvailability object whose change
event will fire when presentation availability changes state.
<!-- controller.html --><buttonid="presentBtn"style="display: none;">Present</button><script>// The Present button is visible if at least one presentation display is availablevar presentBtn = document.getElementById("presentBtn");
// It is also possible to use relative presentation URL e.g. "presentation.html"var presUrls = ["https://example.com/presentation.html",
"https://example.net/alternate.html"];
// show or hide present button depending on display availabilityvar handleAvailabilityChange = function(available) {
presentBtn.style.display = available ? "inline" : "none";
};
// Promise is resolved as soon as the presentation display availability is// known.var request = new PresentationRequest(presUrls);
request.getAvailability().then(function(availability) {
// availability.value may be kept up-to-date by the controlling UA as long// as the availability object is alive. It is advised for the Web developers// to discard the object as soon as it's not needed.
handleAvailabilityChange(availability.value);
availability.onchange = function() { handleAvailabilityChange(this.value); };
}).catch(function() {
// Availability monitoring is not supported by the platform, so discovery of// presentation displays will happen only after request.start() is called.// Pretend the devices are available for simplicity; or, one could implement// a third state for the button.
handleAvailabilityChange(true);
});
</script>
5.2
Starting a new presentation
When the user clicks presentBtn, this code requests
presentation of one of the URLs in the PresentationRequest.
When start is called, the
browser typically shows a dialog that allows the user to select one
of the compatible displays that are available. The first URL in the
PresentationRequest that is compatible with the chosen display
will be presented on that display.
The start method resolves
with a PresentationConnection object that is used to track the
state of the presentation, and exchange messages with the
presentation page once it's loaded on the display.
<!-- controller.html --><script>
presentBtn.onclick = function () {
// Start new presentation.
request.start()
// The connection to the presentation will be passed to setConnection on// success.
.then(setConnection);
// Otherwise, the user canceled the selection dialog or no screens were// found.
};
</script>
5.3
Reconnecting to an existing presentation
The presentation continues to run even after the original page that
started the presentation closes its PresentationConnection,
navigates, or is closed. Another page can use the id on the PresentationConnection
to reconnect to an existing presentation and resume control of it.
This is only guaranteed to work from the same browser that started
the presentation.
<!-- controller.html --><buttonid="reconnectBtn"style="display: none;">Reconnect</button><script>var reconnect = function () {
// read presId from localStorage if existsvar presId = localStorage["presId"];
// presId is mandatory when reconnecting to a presentation.if (!!presId) {
request.reconnect(presId)
// The new connection to the presentation will be passed to// setConnection on success.
.then(setConnection);
// No connection found for presUrl and presId, or an error occurred.
}
};
// On navigation of the controller, reconnect automatically.document.addEventListener("DOMContentLoaded", reconnect);
// Or allow manual reconnection.const reconnectBtn = document.querySelector("#reconnectBtn");
reconnectBtn.onclick = reconnect;
</script>
5.4
Starting a presentation by the controlling user agent
Some browsers have a way for users to start a presentation without
interacting directly with the controlling page. Controlling pages can
opt into this behavior by setting the defaultRequest property on
navigator.presentation, and listening for a
connectionavailable event that is fired when a presentation is
started this way. The PresentationConnection passed with the
event behaves the same as if the page had called start.
<!-- controller.html --><!-- Setting presentation.defaultRequest allows the page to specify the
PresentationRequest to use when the controlling UA initiates a
presentation. --><script>
navigator.presentation.defaultRequest = new PresentationRequest(presUrls);
navigator.presentation.defaultRequest.onconnectionavailable = function(evt) {
setConnection(evt.connection);
};
</script>
5.5
Monitoring the connection state and exchanging data
Once a presentation has started, the returned
PresentationConnection is used to monitor its state and
exchange messages with it. Typically the user will be given the
choice to disconnect from or terminate the presentation from the
controlling page.
Since the the controlling page may connect to and disconnect from
multiple presentations during its lifetime, it's helpful to keep
track of the current PresentationConnection and its state.
Messages can only be sent and received on connections in a
connected state.
<!-- controller.html --><buttonid="disconnectBtn"style="display: none;">Disconnect</button><buttonid="stopBtn"style="display: none;">Stop</button><script>let connection;
// The Disconnect and Stop buttons are visible if there is a connected presentationconst stopBtn = document.querySelector("#stopBtn");
const disconnectBtn = document.querySelector("#disconnectBtn");
stopBtn.onclick = _ => {
connection && connection.terminate();
};
disconnectBtn.onclick = _ => {
connection && connection.close();
};
functionsetConnection(newConnection) {
// Disconnect from existing presentation, if not attempting to reconnectif (connection && connection != newConnection && connection.state != 'closed') {
connection.onclose = undefined;
connection.close();
}
// Set the new connection and save the presentation ID
connection = newConnection;
localStorage["presId"] = connection.id;
functionshowConnectedUI() {
// Allow the user to disconnect from or terminate the presentation
stopBtn.style.display = "inline";
disconnectBtn.style.display = "inline";
reconnectBtn.style.display = "none";
}
functionshowDisconnectedUI() {
disconnectBtn.style.display = "none";
stopBtn.style.display = "none";
reconnectBtn.style.display = localStorage["presId"] ? "inline" : "none";
}
// Monitor the connection state
connection.onconnect = _ => {
showConnectedUI();
// Register message handler
connection.onmessage = message => {
console.log(`Received message: ${message.data}`);
};
// Send initial message to presentation page
connection.send("Say hello");
};
connection.onclose = _ => {
connection = null;
showDisconnectedUI();
};
connection.onterminate = _ => {
// Remove presId from localStorage if existsdeletelocalStorage["presId"];
connection = null;
showDisconnectedUI();
};
};
</script>
5.6
Listening for incoming presentation connections
This code runs on the presented page
(https://example.org/presentation.html). Presentations
may be connected to from multiple controlling pages, so it's
important that the presented page listen for incoming connections on
the connectionList
object.
5.8
Creating a second presentation from the same controlling page
It's possible for a controlling page to start and control two
independent presentations on two different presentation displays.
This code shows how a second presentation can be added to the first
one in the examples above.
<!-- controller.html --><!-- The same controlling page can create and manage multiple presentations,
by calling start() multiple times. --><buttonid="secondPresentBtn"style="display: none;">Present Again</button><script>var secondPresentBtn = document.getElementById("secondPresentBtn");
var secondPresUrl = "https://example.com/second-presentation.html";
var secondRequest = new PresentationRequest(secondPresUrl);
// For simplicity, the logic to handle screen availability for secondRequest// and update the status of secondPresentBtn is omitted.
secondPresentBtn.onclick = function () {
// Start new presentation, likely on a different screen than the original// request.
secondRequest.start().then(setSecondConnection);
};
functionsetSecondConnection(newConnection) {
// Logic to handle messages to/from second-presentation.html.
};
</script>
6.
API
6.1
Common idioms
A presentation
display refers to a graphical and/or audio output device
available to the user agent via an implementation specific connection
technology.
A presentation
connection is an object relating a controlling browsing
context to its receiving browsing context and enables
two-way-messaging between them. Each presentation connection
has a presentation connection state, a unique
presentation
identifier to distinguish it from other presentations,
and a presentation URL that is a URL used to create
or reconnect to the presentation. A valid
presentation identifier consists of alphanumeric ASCII
characters only and is at least 16 characters long.
Some presentation displays may only be able to display a
subset of Web content because of functional, security or hardware
limitations. Examples are set-top boxes, smart TVs, or networked
speakers capable of rendering only audio. We say that such a display
is an available
presentation display for a presentation URL if the
controlling user agent can reasonably guarantee that
presentation of the URL on that display will succeed.
In a controlling browsing context, the default
presentation request, which is initially set to
null, represents the request to use when the user wishes
to initiate a presentation connection from the browser chrome.
The task source for the tasks mentioned in this specification
is the presentation task source.
Unless otherwise specified, the JavaScript realm for script
objects constructed by algorithm steps is the current realm.
The controlling user agentSHOULD initiate presentation
using the default presentation request only when the user
has expressed an intention to do so via a user gesture, for example
by clicking a button in the browser chrome.
The details of implementing the permission request and display
selection are left to the user agent; for example it may show the
user a dialog and allow the user to select an available display
(granting permission), or cancel the selection (denying
permission). Implementers are encouraged to show the user whether
an available display is currently in use, to facilitate
presentations that can make use of multiple displays.
Note
Receiving user agents are encouraged to advertise a user friendly
name for the presentation display, e.g. "Living Room TV", to assist
the user in selecting the intended display. Implementers of
receiving user agents are also encouraged to advertise the locale
and intended text direction of the user friendly name. Implementers
of controlling user agents are encouraged to render a user friendly
name using its locale and text direction when they are known.
6.3.3
Starting a presentation from a default presentation request
When the user expresses an intent to start presentation of a
document on a presentation display using the browser chrome (via a
dedicated button, user gesture, or other signal), that user agent
MUST run the following steps to start
a presentation from a default presentation request. If no
default presentation request is set on the document, these
steps MUST not be run.
Input
W, the document on which the user has expressed an
intent to start presentation
If the next step fails, abort all remaining steps and close
the presentation connectionS with
error as
closeReason, and a human readable message describing
the failure as closeMessage.
The presentationUrl should name a resource accessible to
the local or a remote user agent. This specification defines
behavior for presentationUrl using the http
or https schemes; behavior for other schemes is not
defined by this specification.
6.3.5
Reconnecting to a presentation
When the reconnect
method is called, the user agentMUST run the following
steps to reconnect to a presentation:
The following are the event handlers (and their corresponding event
handler event types) that must be supported, as event handler IDL
attributes, by objects implementing the PresentationRequest
interface:
The monitoring algorithm must be run at least one more time
after the previous step to pick up the tuple that was added to
the set of presentation availability objects.
The mechanism used to monitor presentation displays
availability and determine the compatibility of a presentation
display with a given URL is left to the user agent.
The state attribute represents the
presentation connection's current state. It can take one of
the values of PresentationConnectionState depending on
the connection state:
connected means that the presentation
connection is established and communication is possible.
closed means that the presentation connection
has been closed, or could not be opened. It may be re-opened
through a call to reconnect. No communication is
possible.
A connected
state does not mean that sending or receiving messages will
succeed, as the communication channel may be abruptly closed at any
time. Applications that wish to detect such situations as soon as
possible should implement their own keep-alive mechanism.
The binaryType attribute can take one of the values of
BinaryType. When a PresentationConnection object is
created, its binaryType attribute MUST be set to
the string "arraybuffer". On getting, it MUST return
the last value it was set to. On setting, the user agent MUST set
the attribute to the new value.
Note
The binaryType
attribute allows authors to control how binary data is exposed to
scripts. By setting the attribute to "blob", binary
data is returned in Blob form; by setting it to
"arraybuffer", it is returned in ArrayBuffer form.
The attribute defaults to "arraybuffer". This
attribute has no effect on data sent in a string form.
If the connection cannot be completed, close the
presentation connectionS with error as
closeReason, and a human readable message describing the
failure as closeMessage.
Note
The mechanism that is used to present on the remote display and
connect the controlling browsing context with the presented
document is an implementation choice of the user agent. The
connection must provide a two-way messaging abstraction capable of
carrying DOMString and binary payloads in a reliable
and in-order fashion as described in the Send a Message and
Receive a Message steps below.
No specific transport for the connection between the controlling
browsing context and the receiving browsing context is
mandated, except that for multiple calls to send it has to be ensured that
messages are delivered to the other end reliably and in sequence.
The transport should function equivalently to an RTCDataChannel
in reliable mode.
Let presentation message data be the payload data to be
transmitted between two browsing contexts. Let presentation
message type be the type of that data, one of
text or binary.
If the previous step encounters an unrecoverable error, then
abruptly close the presentation connectionpresentationConnection with error as
closeReason, and a closeMessage describing
the error encountered.
Note
To assist applications in recovery from an error sending a
message through a presentation connection, the user agent
should include details of which attempt failed in
closeMessage, along with a human readable string
explaining the failure reason. Example renditions of
closeMessage:
Unable to send text message (network_error):
"hello" for DOMString messages, where
"hello" is the first 256 characters of the failed
message.
When sending a user-visible string via a presentation
connection, the page author should take care to ensure that
locale information is also propagated so that the destination user
agent can know how to best render the string. See the examples for
one solution.
If the state property of
presentationConnection is not connected, abort these steps.
Let event be the result of creating an event
using the MessageEvent interface, with the event type
message, which does not bubble and is not cancelable.
Initialize the event's data attribute as follows:
If messageType is text, then
initialize event's data attribute to
messageData with type DOMString.
If messageType is binary, and
binaryType attribute is set to "blob", then
initialize event's data attribute to a
new Blob object with messageData as its raw
data.
If messageType is binary, and
binaryType attribute is set to
"arraybuffer", then initialize event's
data attribute to a new ArrayBuffer object
whose contents are messageData.
If the user agent encounters an unrecoverable error while
receiving a message through
presentationConnection, it MUST abruptly close the
presentation connectionpresentationConnection with
error as
closeReason. It SHOULD use a human readable description
of the error encountered as closeMessage.
wentaway means that the browser closed the connection,
for example, because the browsing context that owned the
connection navigated or was discarded.
When the reason attribute is
error, the
user agent SHOULD set the message attribute to a
human readable description of how the communication channel
encountered an error.
Start to signal to the destination browsing context the
intention to close the corresponding PresentationConnection,
passing the closeReason to that context. The user agent
does not need to wait for acknowledgement that the corresponding
PresentationConnection was actually closed before proceeding
to the next step.
Fire an event named close, that uses the
PresentationConnectionCloseEvent interface, with the
reason
attribute initialized to closeReason and the
message
attribute initialized to closeMessage, at
presentationConnection. The event must not bubble
and must not be cancelable.
6.5.6
Terminating a presentation in a controlling browsing context
When a controlling user agent is to terminate a presentation in a
controlling browsing context using connection, it
MUST run the following steps:
This could happen by an explicit user action, or as a policy of
the user agent. For example, the receiving user agent
could be configured to terminate presentations whose
PresentationConnection objects are all closed for 30
minutes.
When a receiving user agent is to terminate a presentation in a
receiving browsing context, it MUST run the following steps:
Let P be the presentation to be terminated, let
allControllers be the set of presentation
controllers that were created for P, and
connectedControllers an empty list.
For each connection in allControllers,
run the following steps:
The following are the event handlers (and their corresponding event
handler event types) that must be supported, as event handler IDL
attributes, by objects implementing the
PresentationConnection interface:
This algorithm is intended to create a well defined environment to
allow interoperable behavior for 1-UA and 2-UA
presentations, and to minimize the amount of state remaining on a
presentation display used for a 2-UA presentation.
Given the operating context of the presentation display,
some Web APIs will not work by design (for example, by requiring
user input) or will be obsolete (for example, by attempting window
management); the receiving user agent should be aware of
this. Furthermore, any modal user interface will need to be handled
carefully. The sandboxed modals flag is set on the
receiving browsing context to prevent most of these
operations.
The following are the event handlers (and their corresponding event
handler event types) that must be supported, as event handler IDL
attributes, by objects implementing the
PresentationConnectionList interface:
Event handler
Event handler event type
onconnectionavailable
connectionavailable
7.
Security and privacy considerations
This section is non-normative.
7.1
Personally identifiable information
The change event fired on the PresentationAvailability
object reveals one bit of information about the presence or absence
of a presentation display, often discovered through the
browser's local area network. This could be used in conjunction with
other information for fingerprinting the user. However, this
information is also dependent on the user's local network context, so
the risk is minimized.
A presentation is
allowed to be accessed across origins; the presentation URL
and presentation identifier used to create the presentation
are the only information needed to reconnect to a presentation from
any origin in the controlling user agent. In other words, a
presentation is not tied to a particular opening origin.
This design allows controlling contexts from different origins to
connect to a shared presentation resource. The security of the
presentation identifier prevents arbitrary origins from connecting to
an existing presentation.
This specification makes no guarantee as to the identity of any party
connecting to a presentation. Once connected, the presentation may
wish to further verify the identity of the connecting party through
application-specific means. For example, the presentation could
challenge the controller to provide a token via send that the presentation uses to
verify identity and authorization.
Display of the origin requesting presentation will help the user
understand what content is making the request, especially when
the request is initiated from a child navigable. For
example, embedded content may try to convince the user to click
to trigger a request to start an unwanted presentation.
When a user starts a
presentation, the user will begin with exclusive control of
the presentation. However, the Presentation API allows additional
devices (likely belonging to distinct users) to connect and
thereby control the presentation as well. When a second device
connects to a presentation, it is recommended that all connected
controlling user agents
notify their users via the browser chrome that the original user
has lost exclusive access, and there are now multiple controllers
for the presentation.
In addition, it may be the case that the receiving user
agent is capable of receiving user input, as well as acting
as a presentation display. In this case, the receiving
user agent should notify its user via browser chrome when a
receiving browsing context is under the control of a
remote party (i.e., it has one or more connected controllers).
7.4
Device Access
The presentation API abstracts away what "local" means for displays,
meaning that it exposes network-accessible displays as though they
were directly attached to the user's device. The Presentation API
requires user permission for a page to access any display to mitigate
issues that could arise, such as showing unwanted content on a
display viewable by others.
7.5
Temporary identifiers and browser state
The presentation URL and presentation identifier can be
used to connect to a presentation from another browsing context. They
can be intercepted if an attacker can inject content into the
controlling page.
7.6
Private browsing mode and clearing of browsing data
The content displayed on the presentation is different from the
controller. In particular, if the user is logged in in both contexts,
then logs out of the controlling browsing context, they will
not be automatically logged out from the receiving browsing
context. Applications that use authentication should pay extra
care when communicating between devices.
The set of presentations known to the user agent should be cleared
when the user requests to "clear browsing data."
Thanks to Addison Phillips, Anne Van Kesteren, Anssi Kostiainen, Anton
Vayvod, Chris Needham, Christine Runnegar, Daniel Davis, Domenic
Denicola, Erik Wilde, François Daoust, 闵洪波 (Hongbo Min), Hongki CHA,
Hubert Sablonnière, Hyojin Song, Hyun June Kim, Jean-Claude Dufourd,
Joanmarie Diggs, Jonas Sicking, Louay Bassbouss, Mark Watson, Martin
Dürst, Matt Hammond, Mike West, Mounir Lamouri, Nick Doty, Oleg
Beletski, Philip Jägenstedt, Richard Ishida, Shih-Chiang Chien, Takeshi
Kanai, Tobie Langel, Tomoyuki Shimizu, Travis Leithead, and Wayne Carr
for help with editing, reviews and feedback to this draft.
AirPlay, HDMI, Chromecast, DLNA and
Miracast are registered trademarks of Apple Inc., HDMI
Licensing LLC., Google Inc., the Digital Living Network Alliance, and
the Wi-Fi Alliance, respectively. They are only cited as background
information and their use is not required to implement the
specification.
D.
Candidate Recommendation exit criteria
For this specification to be advanced to Proposed Recommendation, there
must be, for each of the conformance classes it defines (controlling
user agent and receiving user agent), at least two
independent, interoperable implementations of each feature. Each
feature may be implemented by a different set of products, there is no
requirement that all features be implemented by a single product.
Additionally, implementations of the controlling user agent
conformance class must include at least one implementation of the
1-UA mode, and one implementation of the 2-UA mode.
2-UA mode implementations may only support non http/https
presentation URLs. Implementations of the receiving user agent
conformance class may not include implementations of the 2-UA
mode.
The API was recently restricted to secure contexts. Deprecation of the
API in non secure contexts in early implementations takes time. The
group may request transition to Proposed Recommendation with
implementations that still expose the API in non secure contexts,
provided there exists a timeline to restrict these implementations in
the future.
For the purposes of these criteria, we define the following terms:
Independent
Each implementation must be developed by a different party, and
cannot share, reuse, or derive from code used by another qualifying
implementation. Sections of code that have no bearing on the
implementation of this specification are exempt from this
requirement.
Interoperable
Passing the respective test case(s) in the official test suite.
Implementation
A user agent which:
implements one of the conformance classes of the specification.
is available to the general public. The implementation may be a
shipping product or other publicly available version (i.e., beta
version, preview release, or "nightly build"). Non-shipping product
releases must have implemented the feature(s) for a period of at
least one month in order to demonstrate stability.
is not experimental (i.e. a version specifically designed to
pass the test suite and not intended for normal usage going
forward).
E.
Change log
This section is non-normative.
This section lists changes made to the spec since it was first
published as Candidate Recommendation in July 2016, with links to
related issues on the group's issue tracker.
E.1
Changes since 01 June 2017
Added a note about receiving browsing contexts starting
presentations (#487)
Removed the definition of the BinaryType enum (#473)
Updated WebIDL to use constructor operations (#469)
Clarified how receiving browsing contexts are allowed to navigate
(#461)
Updated termination algorithm to also discard the receiving
browsing context and allow termination in a connecting state
(#421,
#423)
Dropped sandboxing section, now integrated in HTML (#437 in the Web Platform
Working Group issue tracker)
Relaxed exit criteria to match known implementations plans
(#406)
The sandboxed top-level navigation browsing context flag and the
sandboxed modals flag are now set on the receiving browsing context
to prevent top-level navigation and the ability to spawn new browsing
contexts (#414)
Moved sandboxing flag checks to PresentationRequest constructor
(#379,
#398)
Updated normative references to target stable specifications
(#295,
#396)
Made display selection algorithm reject in ancestor and
descendant browsing context (#394)
Renamed PresentationConnectionClosedReason to
PresentationConnectionCloseReason (#393)