forked from w3c/presentation-api
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Overview.src.html
executable file
·1840 lines (1816 loc) · 75.5 KB
/
Overview.src.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en-US">
<head>
<meta charset="UTF-8">
<title>
Presentation API
</title>
<style>
@media print {
[data-anolis-spec]::after { content:"[" attr(data-anolis-spec) "]"; font-size:.6em; vertical-align:super; text-transform:uppercase }
}
</style>
<link rel="stylesheet" type="text/css" href=
"http://www.w3.org/StyleSheets/TR/W3C-[STATUS]">
<style type="text/css">
/* Note formatting taken from HTML5 spec */
.note { border-left-style: solid; border-left-width: 0.25em; background: none repeat scroll 0 0 #E9FBE9; border-color: #52E052; }
.note em, .warning em, .note i, .warning i { font-style: normal; }
p.note, div.note { padding: 0.5em 2em; }
span.note { padding: 0 2em; }
.note p:first-child { margin-top: 0; }
.note p:last-child { margin-bottom: 0; }
p.note:before { content: 'NOTE: '; }
.open-issue { border-left-style: solid; border-left-width: 0.25em; background: none repeat scroll 0 0 #fbfbe9; border-color: #faf9a5; }
.open-issue em, .warning em, .open-issue i, .warning i { font-style: normal; }
p.open-issue, div.open-issue { padding: 0.5em 2em; }
span.open-issue { padding: 0 2em; }
.open-issue p:first-child { margin-top: 0; }
.open-issue p:last-child { margin-bottom: 0; }
.non-normative { border-left-style: solid; border-left-width: 0.25em; background: none repeat scroll 0 0 #E9FBE9; border-color: #52E052; }
p.non-normative:before { content: 'Non-normative: '; font-weight: bolder;}
p.non-normative, div.non-normative { padding: 0.5em 2em; }
/* Pre.idl formatting taken from HTML5 spec */
pre.idl { border: solid thin #d3d3d3; background: #FCFCFC; color: black; padding: 0.5em 1em; position: relative; }
pre.idl :link, pre.idl :visited { color: inherit; background: transparent; }
pre.idl::before { content: "IDL"; font: bold small sans-serif;
padding: 0.5em; background: white; position: absolute; top: 0;
margin: -1px 0 0 -4em; width: 1.5em; border: thin solid;
border-radius: 0 0 0 0.5em }
/* .example idl formatting taken from HTML5 nightly spec */
.example {
display: block;
color: #222222;
background: #FCFCFC;
border-left-style: solid;
border-color: #c0c0c0;
border-left-width: 0.25em;
margin-left: 1em;
padding-left: 1em;
padding-bottom: 0.5em;
}
.algorithm li {
margin-bottom: 0.5em;
}
.interface dd, .parameters dt {
margin-bottom: 0.5em;
}
code { color: orangered; }
table { border-collapse: collapse; border-style: hidden hidden none hidden; }
table thead, table tbody { border-bottom: solid; }
table td, table th { border-left: solid; border-right: solid; border-bottom: solid thin; vertical-align: top; padding: 0.2em; }
dfn { font-weight: bolder; font-style: normal; }
#use-cases-and-requirements dd { margin-top: 0.5em; margin-bottom: 1em; }
.copyright { font-size: small; }
</style>
</head>
<body>
<div class="head">
<!--logo-->
<h1>
Presentation API
</h1>
<h2 class="no-num no-toc">
[LONGSTATUS] [DATE]
</h2>
<dl>
<dt>
This version:
</dt>
<dd>
<!--begin-link-->http://w3c.github.io/presentation-api/
<!--end-link-->
</dd>
<dt>
Latest published version:
</dt>
<dd>
<!--begin-link-->http://www.w3.org/TR/presentation-api/
<!--end-link-->
</dd>
<dt>
Latest editor's draft:
</dt>
<dd>
<!--begin-link-->http://w3c.github.io/presentation-api/
<!--end-link-->
</dd>
<dt>
Version history:
</dt>
<dd>
<!--begin-link-->https://github.com/w3c/presentation-api/commits/
<!--end-link-->
</dd>
<dt>
Participate:
</dt>
<dd>
Send feedback to <a href=
"https://lists.w3.org/Archives/Public/public-secondscreen/">public-secondscreen@w3.org</a>
or <a href="https://github.com/w3c/presentation-api/issues/new">open
a new issue</a> (<a href=
"https://github.com/w3c/presentation-api/issues/">open issues</a>)
</dd>
<dt>
Editors:
</dt>
<dd>
<a href="mailto:mfoltz@google.com">Mark Foltz</a>, Google
</dd>
<dd>
Dominik Röttsches, Intel (until April 2015)
</dd>
</dl>
<p class="copyright">
<a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
© 2015 <a href="http://www.w3.org/"><abbr title=
"World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href=
"http://www.csail.mit.edu/"><abbr title=
"Massachusetts Institute of Technology">MIT</abbr></a>, <a href=
"http://www.ercim.eu/"><abbr title=
"European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
<a href="http://www.keio.ac.jp/">Keio</a>, <a href=
"http://ev.buaa.edu.cn/">Beihang</a>). W3C <a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a href=
"http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply.
</p>
<hr>
</div>
<section>
<h2 class="no-num no-toc">
Abstract
</h2>
<p>
This specification defines an API to enable web content to access
external presentation-type displays and use them for presenting web
content.
</p>
</section>
<section>
<h2 class="no-num no-toc" id="sotd">
Status of This Document
</h2>
<p>
<em>This section describes the status of this document at the time of
its publication. Other documents may supersede this document. A list of
current W3C publications and the latest revision of this technical
report can be found in the <a href="http://www.w3.org/TR/">W3C
technical reports index</a> at http://www.w3.org/TR/.</em>
</p>
<p>
This document was published by the <a href=
"http://www.w3.org/2014/secondscreen/">Second Screen Presentation
Working Group</a> as an Editor's Draft. If you wish to make comments
regarding this document, please send them to <a href=
"mailto:public-secondscreen@w3.org">public-secondscreen@w3.org</a>
(<a href=
"mailto:public-secondscreen-request@w3.org?subject=subscribe">subscribe</a>,
<a href=
"http://lists.w3.org/Archives/Public/public-secondscreen/">archives</a>).
All comments are welcome.
</p>
<p>
This document is a <b>work in progress</b> and is subject to change. It
builds on the <a href=
"http://www.w3.org/2014/secondscreen/presentation-api/20141118/" title=
"Presentation API W3C Community Group Final Report">final report</a>
(dated 18 November 2014) produced by the Second Screen Presentation
Community Group. Algorithms have been drafted in particular. Most
sections are still incomplete or underspecified. Privacy and security
considerations are missing. A few open issues are noted inline. Please
check the group's <a href=
"https://github.com/w3c/presentation-api/issues">issue tracker</a> on
GitHub for an accurate list. Feedback from early experimentations is
encouraged to allow the Second Screen Presentation Working Group to
evolve the specification based on implementation issues.
</p>
<p>
Publication as a First Public Working Draft does not imply endorsement
by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership.
This draft document 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.
</p>
<p>
This document was produced by a group operating under the <a id=
"sotd_patent" rel="w3p:patentRules" href=
"http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004
<abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
<abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href=
"http://www.w3.org/2004/01/pp-impl/74168/status" rel=
"disclosure">public list of any patent disclosures</a> 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 that the individual believes contains <a href=
"http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
Claim(s)</a> must disclose the information in accordance with <a href=
"http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent
Policy</a>.
</p>
<p>
This document is governed by the <a id="w3c_process_revision" href=
"http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title=
"World Wide Web Consortium">W3C</abbr> Process Document</a>.
</p>
</section>
<section>
<h2 class="no-num no-toc">
Table of Contents
</h2><!--toc-->
</section>
<section>
<h2>
Introduction
</h2><em>This section is non-normative.</em>
<p>
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).
</p>
<p>
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.
</p>
<p>
At its core, this specification enables an exchange of messages between
a requesting page and a presentation page shown in the secondary
display. How those messages are transmitted is left to the UA in order
to allow for the use of display devices that can be attached to a wide
variety of ways. For example, when a display device is attached using
HDMI or MiraCast, the UA on the requesting device can render the
requested presentation page in that same UA. Instead of displaying in a
window on that same device, however, it can use whatever means the
operating system provides for using those external displays. In that
case, both the requesting page and the presentation page run on the
requesting device and the operating system is used to route the
presentation display output to the other display device. The second
display device doesn't need to know anything about this spec or that
the content involves HTML5.
</p>
<p>
Alternately, some types of external displays may be able to render
HTML5 themselves and may have defined their way to send messages to
that content. In that case, the UA on the requesting device would not
need to render the presentation page itself. Instead, the UA could act
as a proxy translating the request to show a page and the messages into
the form understood by the display device.
</p>
<p>
This way of attaching to displays could be enhanced in the future by
defining a standard protocol for delivering these types of messages
that display devices could choose to implement.
</p>
<p>
The API defined here is intended to be used with UAs that attach to
display devices through any of the above means.
</p>
</section>
<section id="use-cases-and-requirements">
<h2>
Use cases and requirements
</h2>
<section id="use-cases">
<h3>
Use cases
</h3>
<dl>
<dt>
Presentations
</dt>
<dd>
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.
</dd>
<dt>
Video and image sharing
</dt>
<dd>
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, however, a user cannot 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.
</dd>
<dt>
Multiplayer gaming
</dt>
<dd>
Splitting the gaming experience into a near screen controller and a
large screen visual experience can create new gaming experiences.
Accessing the local display on the small screen device and an
external larger display allows for richer web-based gaming
experiences.
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/27">ISSUE
27: Define a multiplayer gaming use case</a>
</p>
</dd>
<dt>
Media flinging to multiple screens
</dt>
<dd>
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 at 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 a different angle. Alice
clicks a button "Select screen for additional angle", and the
browser asks Alice similarly to select the screen 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".
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/40">ISSUE
40: Screen availability mechanism for multiple sessions</a>
</p>
</dd>
</dl>
</section>
<section id="requirements">
<h3>
Requirements
</h3>
<p>
The requirements enumerated in this section are derived from the
<a href="#use-cases">use cases</a>.
</p>
<section>
<h4>
Functional requirements
</h4>
<dl>
<dt>
Discovery & availability
</dt>
<dd>
The UA must provide a way to find out whether at least one
secondary screen is available.
</dd>
<dt>
Launching presentation
</dt>
<dd>
The UA must provide a means of start sending content to the
secondary screen.
</dd>
<dt>
Resuming presentation
</dt>
<dd>
The UA must be able to resume an existing session with the
content being displayed on the secondary screen.
</dd>
<dt>
Communication
</dt>
<dd>
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. The UA must not make assumptions
about the execution locality of the UA of the remote page it
communicates with (i.e. the secondary page might run on a remote
UA, and thus the link between these two pages must be loosely
coupled).
</dd>
<dt>
Signaling disconnection
</dt>
<dd>
The UA must signal disconnection from the presentation page to
the primary page and vice versa.
</dd>
</dl>
<p class="note">
Multi-screen enumeration and named identification requirement was
removed after <a rel="nofollow" class="external free" href=
"http://lists.w3.org/Archives/Public/public-webscreens/2014Feb/0021.html">
discussion on the mailing list</a>.
</p>
</section>
<section>
<h4>
Non-functional requirements
</h4>
<dl>
<dt>
Power saving friendly
</dt>
<dd>
All API design decisions must be analyzed from a power efficiency
point of view. Especially when using wireless display
technologies or 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.
</dd>
</dl>
</section>
</section>
</section>
<section>
<h2>
Conformance
</h2>
<p>
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.
</p>
<p>
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. <span data-anolis-ref="">RFC2119</span>
</p>
<p>
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.
</p>
<p>
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.)
</p>
</section>
<section>
<h2>
Terminology
</h2>
<p>
The terms <span data-anolis-spec="w3c-html">browsing context</span>,
<span data-anolis-spec="w3c-html">event handlers</span>, <span title=
"event handler event type" data-anolis-spec="w3c-html">event handler
event types</span>, <span data-anolis-spec="w3c-html" title=
"concept-event-fire">firing an event</span>, <span data-anolis-spec=
"w3c-html">navigate</span>, <span data-anolis-spec="w3c-html" title=
"queue a task">queing a task</span> are defined in
<span data-anolis-ref="">HTML5</span>.
</p>
<p>
The term <span data-anolis-spec="dom" title=
"domexception">DOMException</span> is defined in <span data-anolis-ref=
"dom">DOM</span>.
</p>
<p>
The term <span data-anolis-spec="es6" title=
"promise-objects">Promise</span> is defined in <span data-anolis-ref=
"">ES6</span>. The terms <span data-anolis-spec="promguide" title=
"resolve-reject">resolving a Promise, and rejecting a Promise</span>
are used as explained in <span data-anolis-ref="">PROMGUIDE</span>.
</p>
<p>
The term <span data-anolis-spec="url">URL</span> is defined in the
WHATWG URL standard: <span data-anolis-ref="url">URL</span>.
</p>
<p>
The terms <span data-anolis-spec="typedarray">ArrayBuffer</span>,
<span data-anolis-spec="typedarray">ArrayBufferView</span> are defined
in the Typed Array specification: <span data-anolis-ref=
"typedarray">TYPEDARRAY</span>.
</p>
<p>
The term <span data-anolis-spec="fileapi">Blob</span> is defined in the
File API specification: <span data-anolis-ref="fileapi">FILEAPI</span>.
</p>
<p>
This document provides interface definitions using the
<span data-anolis-ref="webidl">WEBIDL</span> standard.
</p>
</section>
<section>
<h2>
Examples
</h2>
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/42">ISSUE 42:
Make the Example section more concise</a>
</p>
<p>
This section shows example codes that highlight the usage of main
features of the Presentation API. In these examples,
<code>controller.html</code> represents the controlling page that runs
in the opener UA and <code>presentation.html</code> represents the
presenting page that runs in the presenting UA. Both pages are served
from the domain <code>http://example.org</code>
(<code>http://example.org/controller.html</code> and
<code>http://example.org/presentation.html</code>). Please refer to the
comments in the code examples for further details.
</p>
<section>
<h3>
Monitor availability of presentation displays example
</h3>
<pre class="example">
<!-- controller.html -->
<button id="castBtn" style="display: none;">Cast</button>
<script>
// the cast button is visible if at least one presentation display is available
var castBtn = document.getElementById("castBtn");
// availablechange event is fired when the presentation display availability changes
navigator.presentation.onavailablechange = function (evt) {
// show or hide cast button depending on display availability
castBtn.style.display = evt.available ? "inline" : "none";
};
</script>
</pre>
</section>
<section>
<h3>
Starting a new presentation session example
</h3>
<pre class="example">
<!-- controller.html -->
<script>
// it is also possible to use relative presentation URL e.g. "presentation.html"
var presUrl = "http://example.com/presentation.html";
// create random presId
var presId = Math.random().toFixed(6).substr(2);
// Start new session. presId is optional.
navigator.presentation.startSession(presUrl, presId)
// the new started session will be passed to setSession on success
.then(setSession)
// user cancels the selection dialog or an error is occurred
.catch(endSession);
</script>
</pre>
</section>
<section>
<h3>
Joining a presentation session example
</h3>
<pre class="example">
<!-- controller.html -->
<script>
// read presId from localStorage if exists
var presId = localStorage && localStorage["presId"] || null;
// presId is mandatory for joinSession.
presId && navigator.presentation.joinSession(presUrl, presId)
// The joined session will be passed to setSession on success
.then(setSession)
// no session found for presUrl and presId or an error is occurred
.catch(endSession);
</script>
</pre>
</section>
<section>
<h3>
Monitor session's state and exchange data example
</h3>
<pre class="example">
<!-- controller.html -->
<script>
var session;
var setSession = function (theSession) {
// end existing session, if any
endSession();
// set the new session
session = theSession;
if (session) {
// save presId in localStorage
localStorage && (localStorage["presId"] = session.id);
// monitor session's state
session.onstatechange = function () {
if (this == session && this.state == "disconnected")
endSession();
};
// register message handler
session.onmessage = function (evt) {
console.log("receive message", evt.data);
};
// send message to presentation page
session.send("say hello");
}
};
var endSession = function () {
// close old session if exists
session && session.close();
// remove old presId from localStorage if exists
localStorage && delete localStorage["presId"];
};
</script>
</pre>
<pre class="example">
<!-- presentation.html -->
<script>
var session = navigator.presentation.session;
session.onstatechange = function () {
// session.state is either 'connected' or 'disconnected'
console.log("session's state is now", session.state);
};
session.onmessage = function (evt) {
if (evt.data == "say hello")
session.send("hello");
};
</script>
</pre>
</section><!--
<p>
Running in a compliant user agent, code for presenting a page
<code>http://example.org/presentation.html</code> on the presentation
display looks as follows:
</p>
<pre class="example">
/* controller.html */
<button disabled id=show>Show</button>
<button disabled id=stop>Stop</button>
<script>
var presentation = navigator.presentation,
showButton = document.getElementById('show'),
stopButton = document.getElementById('stop');
var session = null;
var screenAvailable = false;
var presentationUrl = 'http://example.org/presentation.html';
var presentationId = localStorage['presentationId'] ||
new String((Math.random() * 10000).toFixed(0));
// Join an existing presentation if one exists.
presentation.joinSession(presentationUrl, presentationId).then(
function(existingSession) {
setSession(existingSession);
updateButtons();
},
function() {
// No session to join.
});
presentation.onavailablechange = function(e) {
screenAvailable = e.available;
updateButtons();
};
function updateButtons() {
stopButton.disabled = !session;
stopButton.onClick = session ? stopPresent : null;
showButton.disabled = !screenAvailable;
showButton.onclick = screenAvailable ? startPresent : null;
};
function startPresent() {
presentation.startSession(presentationUrl, presentationId).then(
function(newSession) {
setSession(newSession);
updateButtons();
},
function() {
// User cancelled, etc.
});
};
function stopPresent() {
if (!session) return;
session.close();
delete localStorage['presentationId'];
};
function setSession(theSession) {
// NOTE: We could instead close the current session.
if (session) return;
session = theSession;
localStorage['presentationId'] = session.id;
session.onstatechange = function() {
switch (session.state) {
case 'connected':
session.send(/*...*/);
session.onmessage = function() { /*...*/ };
break;
case 'disconnected':
console.log('Disconnected.');
break;
}
};
}
</script>
</pre>
<p>
The availability monitoring for secondary screens begins when the page
adds an event listener for the <code>availablechange</code> event on
the <code>navigator.presentation</code> object. If there are already
available screens when the page adds the first event listener for the
event, the UA synthesizes a single <code>availablechange</code> event
to signal the availability.
</p>
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/8">ISSUE 8:
Timing of availablechange event to signal screen availability</a>
</p>
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/9">ISSUE 9: How
to filter available screens according to the content being
presented</a>
</p>
<section>
<h4>
Starting new presentations or manually connecting to existing
presentations
</h4>
<p>
The "Show" button's 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
<code>e.available</code> 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.)
</p>
<p>
Clicking the "Show" button calls
<code>navigator.presentation.startSession()</code>, which causes the
user agent to request from the user a screen to show the
presentation. The <code>url</code> argument indicates the content to
be presented. The <code>presentationId</code> argument (optional)
allows the page to identify this presentation instance, and control
which other pages may connect to it by setting a hard-to-guess id.
</p>
<p class="open-issue">
As previously discussed on the mailing list - we can add convenience
here by default-generating an ID.
</p>
<p>
If the user selects a screen with an existing presentation showing
the same <code>url</code> under the same <code>presentationId</code>,
the <span>opening browsing context</span> is connected to that
existing presentation. If the user selects a screen without an
existing presentation, or a screen presenting a different
<code>url</code> or <code>presentationId</code>, the UA connects to
the selected screen, brings up a new presentation window on it, and
starts to show the content denoted by the <code>url</code> argument.
The UA then connects the <span>opening browsing context</span> to
this new presentation and allows the <span>opening browsing
context</span> to exchange messages with it.
</p>
<p>
<code>navigator.presentation.startSession(url, presentationId)</code>
returns a <code>Promise</code> to the <span>opening browsing
context</span>. When the user selects a screen, the presentation page
is shown and a communication channel has been established the
<code>Promise</code> resolves to a <code>PresentationSession</code>
object, which acts as a handle to the presentation for communication
and state handling. Initially, the state of the
<code>PresentationSession</code> is <code>"connected"</code>. At this
point, the <span>opening browsing context</span> can communicate with
the presentation page using the session's <code>send()</code>
to send messages and its <code>onmessage</code> event handler to
receive messages. The presentation page will also have access to
<code>PresentationSession</code> that it can use to send and receive
messages with the <span>opening browsing context</span> (see <a href=
"#usage-on-remote-screen">Usage on remote screen</a>).
</p>
<p>
If the user cancels screen selection, the <code>Promise</code>
returned by <code>startSession(url, presentationId)</code> remains
unresolved.
</p>
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/20">ISSUE 20:
Define return value for cancelled/missing session for
<code>startSession()</code>/<code>joinSession()</code></a>
</p>
<p>
While there is a pending call to <code>startSession</code> asking the
user to select a screen (that the user has not yet accepted or
canceled), the browser may choose to reject subsequent calls to
<code>startSession</code> from the same page, by returning a
<code>Promise</code> that never resolves. This will prevent the
browser from needing to 'queue up' requests to present to the user.
</p>
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/21">ISSUE 21:
Define whether multiple simultaneous calls are permitted to
<code>startSession()</code></a>
</p>
</section>
<section>
<h4>
Automatically reconnecting to existing presentations
</h4>
<p>
The <span>opening browsing context</span> may wish to reconnect to an
existing presentation without prompting the user to select a screen.
For example, the site could allow media items from different pages to
be shown on the same presentation page, and does not want to prompt
the user on each page to reconnect to that presentation. To reconnect
automatically, the page may call <code>joinSession(url,
presentationId)</code>, which returns a <code>Promise</code> that
resolves to an existing <code>PresentationSession</code> if one
exists that is presenting the same <code>url</code> with the same
<code>presentationId</code> as was passed originally into
<code>startSession</code>. The <span>opening browsing context</span>
can then communicate with the presentation as if the user had
manually connected to it via <code>startSession</code>.
</p>
<p>
At the time the <code>joinSession(url, presentationId)</code> method
is called, if the browser is not aware of any
<code>PresentationSession</code> with a matching <code>url</code> and
<code>presentationId</code>, the <code>Promise</code> should remain
unresolved. The browser may become aware of such a session at a later
time (for example, by switching to a WiFi network that has a screen
showing that URL). In this case, the browser may resolve the Promise
to allow the page to connect to the running session.
</p>
<p>
If the browser knows of multiple matching sessions, it should connect
the page to the session that was most recently connected to; if that
cannot be determined by the browser (for example, if the matching
sessions have never been connected), then the <code>Promise</code>
should remain unresolved.
</p>
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/39">ISSUE 39:
Resumption of multiple sessions</a>
</p>
<p>
If the page calls <code>startSession(url, presentationId)</code> and
there is a pending <code>Promise</code> from a call to
<code>joinSession(url, presentationId)</code> (with the same
<code>url</code> and <code>presentationId</code>, and the user
selects a screen in response to <code>startSession</code>, then the
<code>Promise</code> from <code>startSession</code> will be resolved
and the <code>Promise</code> from <code>joinSession</code> will not.
</p>
</section>
<section>
<h4>
Open questions
</h4>
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/10">ISSUE 10:
Is user permission required to prompt for screen availability
information?</a>
</p>
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/12">ISSUE 12:
Necessity of an additional state to indicate a session was
resumed</a>
</p>
</section>
<section>
<h3>
Usage on remote screen
</h3>
<p>
For addressing the requirement of communication between originating
page and presentation page/screen, the presenting page can now use
the same <code>session</code> object. It accesses this object through
the <code>navigator.presentation.session</code> property, which is
only non-<code>null</code> for the page on the presentation screen.
</p>
<pre class="example">
if (navigator.presentation.session) {
var session = navigator.presentation.session;
// Communicate with opening browsing context
session.send(/*...*/);
session.onmessage = function() {/*...*/};
session.onstatechange = function() {
switch (this.state) {
case "disconnected":
// Handle disconnection from opening browsing context
}
};
};
</pre>
<p>
When the content denoted by the <code>url</code> argument in the
<code>startSession()</code> example above is loaded, the page on the
presentation screen will have its
<code>navigator.presentation.session</code> property set to the
session. This session is a similar object as in the first example.
Here, its initial state is <code>"connected"</code>, which means we
can use it to communicate with the <span>opening browsing
context</span> using <code>send()</code> and
<code>onmessage</code>.
</p>
<p>
The presentation page can also monitor the connection state by
listening for <code>statechange</code> events. When the state changes
to <code>"disconnected"</code> the page is made aware of the fact
that communication with the <span>opening browsing context</span> was
lost, but it can continue to display the current content. The
communication can be re-established when a <code>statechange</code>
event fires with a new state of <code>"connected"</code>.
</p>
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/19">ISSUE 19:
Specify behavior when multiple controlling pages are connected to the
session</a>
</p>
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/18">ISSUE 18:
Define reconnection for cross-page navigation on presenting user
agent</a>
</p>
<p class="open-issue">
<a href="https://github.com/w3c/presentation-api/issues/14">ISSUE 14:
Define user agent context for rendering the presentation</a>
</p>
</section>
-->
</section>
<section>
<h2>
API
</h2>
<section>
<h3>
Common idioms
</h3>
<p>
A <dfn>presentation display</dfn> refers to an external screen
available to the user agent via an implementation specific connection
technology.
</p>
<p>
A <dfn title="concept-presentation">presentation</dfn> is an active
connection between a user agent and a <span>presentation
display</span> for displaying web content on the latter at the
request of the former.
</p>
<p>
A <dfn title="concept-presentation-session">presentation
session</dfn> is an object relating an <span>opening browsing
context</span> to its <span>presentation display</span> and enabling
two-way-messaging between them. Each such object has a
<dfn>presentation session state</dfn> and a <dfn>presentation session
identifier</dfn> to distinguish it from other <span title=
"concept-presentation-session">presentation sessions</span>.
</p>
<p>
An <dfn>opening browsing context</dfn> is a <span data-anolis-spec=
"w3c-html">browsing context</span> that has initiated or resumed a
<span>presentation session</span> by calling
<code><span>startSession</span>()</code> or
<code><span>joinSession</span>()</code>.
</p>
<p>
The <dfn>presenting browsing context</dfn> is the browsing context