W3C home > Mailing lists > Public > public-secondscreen@w3.org > June 2016

[minutes] WG F2F - Mountain View - Day 1/2

From: Francois Daoust <fd@w3.org>
Date: Wed, 1 Jun 2016 09:57:08 +0200
To: <public-secondscreen@w3.org>
Message-ID: <04eb01d1bbdb$32f82450$98e86cf0$@w3.org>
Hi all,

I cleaned up the minutes of last week's F2F a bit, in particular to better highlight proposed resolutions and link back to GitHub issues where appropriate. Minutes of day 1 are available at:

... and copied as raw text below.


Second Screen WG F2F - Day 1/2
24 May 2016


          Louay_Bassbouss, Anssi_Kostiainen, Mark_Foltz,
          Mounir_Lamouri, Rick_Smit, Hyojin_Song, Chris_Needham,
          Shih-Chiang_Chien, Yavor_Goulishev, Francois_Daoust,
          Jonas_Sicking, Jer_Noble, Ed_Connor
          Francois, Mark, Chris

     * [4]Topics
         1. [5]Welcome and Introductions
         2. [6]Remote Playback API
              1. [7]Do we need remote.getAvailability()? (#39)
              2. [8]onstatechange vs. onconnect, onconnecting,
                 etc. (#36)
              3. [9]Allow websites to stop the remote playback
              4. [10]Define the UA behavior when the
                 disableRemotePlayback attribute is added during
                 the remote playback (#6)
              5. [11]Allow the user agent to choose which media
                 element source to play remotely (#7)
              6. [12]Specify the transition between the local and
                 remote playback when changing remote.state (#25)
              7. [13][Meta] Guidance for HTMLMediaElement,
                 HTMLAudioElement, HTMLVideoElement behaviors
                 during remoting (#41)
              8. [14]Define the interaction with Media Session
              9. [15]Publication as a FPWD (#12)
         3. [16]Presentation API
              1. [17]Is a new Permission type required for
                 presentation display availability (#255)
              2. [18]Topic: User Data Controls in Web Browsers
                 guidelines (#275)
              3. [19]Interoperability and presentation request URL
                 fallback mechanism (#153)
              4. [20]Define behavior of Window and Fullscreen APIs
                 in the presentation browsing context (#99)
              5. [21]Presentation API testing
              6. [22]Remaining issues
     * [23]Summary of Action Items

   See also the [24]minutes of day 2.
     [24] http://www.w3.org/25-webscreens-minutes.html

   NB: Minutes are rough, imprecise, and possibly wrong from time
   to time. Check issues on GitHub, linked from these minutes, for
   additional context.

Welcome and Introductions

   Anssi: [welcoming everyone]. Thanks to our host. Glad to see
   new faces in the group.
   ... Introducing the Second Screen WG: very focused group. 2
   specs in the pipe with the Presentation API and the Remote
   Playback API.
   ... I work for Intel, I'm chair of this group, also active in
   other groups and specs in W3C.
   ... It's been a fun ride to chair this WG, because it's been
   highly functional.
   ... My role is to remove impedance on the way so that you can
   work progress.

   Mark: I'm the editor of the Presentation API, working for
   Google Chrome.
   ... My team is working on multi-screen experiences.

   Mounir: Also working for Google. Together with Anton, we are
   editors of the Remote Playback API.
   ... Also involved in implementation of the Presentation API on

   Rick: I work for Vigour. We develop multiscreen experiences,
   heavily building on Web technologies.
   ... We just joined W3C.

   Hyojin: I work for LG Electronics. I've been working in several
   second screen experiences in the last few years.

   Chris: From the BBC, national broadcaster with an online video
   ... We're interested in the Presentation API as a way for users
   to watch iPlayer content.
   ... Also been involved with Francois in an EU project called
   MediaScape where researched multiscreen use cases.

   SC: Working for Mozilla. Doing implementation work for Firefox
   browser and also Firefox TV.

   Yavor: Working for Google.
   ... Youtube live in chrome. Running HTML5 apps on millions of
   TV. Interested in transport protocols for multi-screen

   Louay: I work for Fraunhofer FOKUS.
   ... We developed prototypes for the Presentation API.
   ... We do a lot of prototypes for HbbTV 2.0 standards as well.
   ... I'm also interested in the discussion of open protocols

   <Louay> I need to leave the office now I will connected in few
   minutes via Hangout mobile

   Anton: Working for Google. Implemented the Presentation API.
   Editor with Mounir of the Remote Playback API.

   Jonas: Hi, I'm from Mozilla.

   Ed: Hi, from Apple

   Jer: Hi, from Apple as well.

   Anssi: Thanks for the introductions. Looking at the agenda:
   we'll start with the Remote Playback API. The spec has much
   improved lately.
   ... In the afternoon, we'll look at the Presentation API with a
   goal to publish a CR soon.
   ... At the end of the day, we'll talk about testing of the
   Presentation API.
   ... [discussing dinner arrangements]

Remote Playback API

   Anssi: Thanks for everyone who contributed to this work
   recently. Feedback from Apple products is great.
   ... I'm going to ask Anton and Mounir to walk us through the
   issues and highlight the most important ones.
   ... Let's start with an overview of the spec.

   Anton: [projecting slides]
   ... Goal is to play media on external (remote) devices, e.g.
   wireless speakers.
   ... The API is needed to narrow the use cases to audio/video
   content which in turn should help reaching out more devices,
   more browsers.
   ... No real problem with messaging either, since we can just
   reuse the MediaElement API.
   ... Most browsers have a similar feature that is only a UI
   feature so far, and not exposed to the Web app.
   ... For app developers, it's less work if they only want to
   playback audio/video content.
   ... Looking at requirements, one of the important ones is not
   to break media websites.
   ... You don't want to throw exceptions
   ... We'd like to be compatible with Safari's API as well.
   ... Taking a quick look at the spec [Anton projecting IDL].
   ... An attribute to disable remote playback and an attribute to
   access the remote interface.
   ... The remote interface is similar to that of the Presentation
   ... The call to connect() yields a Promise that gets resolved
   when the user picks up the remote device.
   ... getAvailability() lets one assess whether there are
   compatible devices available.
   ... We're on GitHub.
   ... Looking at differences with Safari's API, the main
   difference is that availability is implemented as a simple
   attribute. There are also no Promise returned so no way to
   really assess success or failure.

   Anssi: One question, I think you looked at Windows 10 API, any

   Anton: I haven't looked at it, actually.

   Anssi: OK, I remember looking at a Wiki page that mentions it.

   Mounir: I think that was just a mention.
   ... Firefox also has some kind of remoting.

   SC: In Firefox Android, we're trying to introduce a Cast button
   in the playback controls interface so that when the browser
   recognizes supported devices such as Roku, it can propose
   remote playback.

   Anssi: In terms of the spec...

   SC: That's media flinging.

   Anssi: OK. Let's go through issues then.
   ... What would be a good start to make this session logical?

Do we need remote.getAvailability()? (#39)

   -> [25]Issue #39

     [25] https://github.com/w3c/remote-playback/issues/39

   Mark: I wanted to probe this API a little bit.
   ... The 3 issues I wanted us to tackle are: what does it mean
   to call getAvailability() multiple times on the same media
   ... We tweaked the Presentation API so that it returns the same
   ... The second issue which is different in this case is what
   happens if the source list changes.
   ... The third issue is what happens to the availability object
   when the media element is discarded.

   Jer: At least for Safari's initial implementation, I don't
   think that's necessarily a good idea to have an explicit
   start/stop listening.

   Anssi: Not having side effects on event listeners seems to be
   good practice.

   Ed: I would argue that the fact that we don't care until
   there's an event listener attached is just a side effect in
   this case.

   Jonas: Do we need to stop things?

   Jer: When things are garbage collected?

   Jonas: It's not a good idea to tie this to garbage collection
   because it can take minutes.
   ... It kind of works, but it's not super.
   ... I think in APIs that we have that have been aligned with
   the GC, we're kind of regretting it a little bit.

   Jer: Note we have use cases where the media element is detached
   from the DOM but still playing to the remote device.

   Mounir: Right, you could imagine people using MSE, with things
   outside of the DOM.

   Jer: That's a different problem, but yes.

   Mounir: More simply, there is audio, no one adds audio to the

   Anssi: Is the intersection observer the solution?

   <anssik> [26]https://wicg.github.io/IntersectionObserver/

     [26] https://wicg.github.io/IntersectionObserver/

   Mounir: observe/unobserve methods.
   ... media.remote.observe(), you would start observing

   Jer: That wouldn't be an explicit observable object in this

   Mounir: No.

   Anssi: That sounds like a solution.

   <scribe> ACTION: Anton to craft a PR to use observe/unobserve
   pattern for availability [recorded in

   Jonas: Isn't the observer pattern sometimes returning an object
   that can be canceled?

   Mounir: Right.
   ... It actually even takes a callback, which I feel we don't
   really need here.

   Mark: Do we want the page to know the difference between "there
   are no devices" and "the user did not want to pick up one"?

   Anssi: So how granular we want to be in the API. Question is:
   what are the use cases for exposing the different cases of

   Mark: I think that's mostly a power-saving feature.

   Anssi: Working out the differences through polling is also
   pretty bad.

   Jer: 3 levels: 1) No one's monitoring. 2) Someone's interested
   but no need to show the list. 3) Filling up the selection list.
   ... This might be a UA call in the end.
   ... We want to be able to have these 3 cases.

   Anssi: I don't see any negative.

   Mark: The proposal is not to expose the fact that background
   monitoring is not available.

   Mounir: The reason why we exposed that in the Presentation API
   is that a Web site will want to know whether there are devices
   available before showing the button.
   ... And there are devices where you cannot check for
   ... We need to tell the apps that we cannot tell whether a
   device is available.

   Jer: How do they use that information?

   Mounir: At least they know, and can decide whether they display
   the picker or not.

   Anssi: As a developer, I would know that when the user presses
   the button, there is some expectation that the list won't be

   Mounir: Exactly.

   Anssi: How is Safari doing this in the default controls?

   Jer: All the controls are implemented in terms of the
   underlying JavaScript API. The button will appear as soon as a
   device is detected when the controlling device goes to e.g.
   Wifi, in other words level 2.

   Anssi: My personal view is that if, as a user, I click a button
   and get that spinner that ends up with an empty list, that's
   not perfect but that's acceptable.

   Jer: We have available, non available, or unknown as states.
   Would adding an unknown state be a solution?

   Mounir: I guess the unknown state is a problem because on some
   platforms, it will always be unknown.
   ... We probably need to tell the Web page whether we know the
   state is not going to change.

   Jer: OK, so there's a seeking state as well.

   Mounir: Also, Android does not recommend doing any background
   monitoring in some situations, e.g. low battery.

   Anton: Another use case comes to mind where you can pair your
   device without wireless networks.

   Anssi: I'm not sure whether we can settle on the unknown state,
   but we have some direction at least.

   Mounir: We can do something that is similar to IndexedDB
   Observer, where there is an isAlive method that returns a

   Anton: We could add this to the availability object.


     [28] https://github.com/dmurph/indexed-db-observers/blob/gh-pages/EXPLAINER.md

   Mark: I think we have consensus on the Observe/Unobserve
   pattern. Question is whether we want to add features for
   devices that do not support background monitoring.

   Francois: Does this discussion affect the Presentation API as

   Mark: I would have to think about similarity of use cases, but
   it might be a good idea to raise an issue.

   Anssi: That's use case based.

   Mark: the bar is higher for the Presentation API, because the
   spec is mostly stable now.

   Anssi: I agree.

onstatechange vs. onconnect, onconnecting, etc. (#36)

   -> [29]Issue #36

     [29] https://github.com/w3c/remote-playback/issues/36

   Mark: The proposal is merely to break up the "statechange"
   handlers into separate events to have consistency with other
   ... The other questions was whether we need "connecting".

   Mounir: I think we need "connecting", yes.

   Anton: We felt that it would be useful to return this state,
   yes. The connection is established already so you can send

   Jer: Does this duplicate the functionality of the Promise?

   Anton: Yes.
   ... You would only get the event for cases where the user did
   not use default controls.

   PROPOSED RESOLUTION: break up the statechange into 3 different
   events as described in:

     [30] https://github.com/w3c/remote-playback/issues/36#issue-156024443

Allow websites to stop the remote playback (#4)

   -> [31]Issue #4

     [31] https://github.com/w3c/remote-playback/issues/4

   Jer: I've never got a request from people to add a "stop"
   ... It also links to whether the disableRemotePlayback
   attribute is live or just evaluated at start time. In our
   implementation, it's live but I don't have any metric on
   whether it gets used that way.
   ... I can't imagine a good use case that requires a stop
   method. At least in our case, we'll always have local playback
   in the list of devices to choose from.

   Mounir: In that case, we could rename the method into
   "selectDevice" instead of "connect" that suggests
   ... My worry is we might be forcing the UI onto all

   Jer: It's always easier to add a stop method afterwards.
   ... Would a Web site be able to call "stop" whenever it wants?
   I don't know, I think the user should always be in charge.

   Anssi: If user gesture is required to start, it seems logical
   to require user gesture to stop it.
   ... The conclusion seems to me that we don't want a "stop"
   method at this stage and can revisit that if there are
   compelling use cases.

   Anton: That is fine with me.

   Jonas: I feel I don't have enough experience with how the user
   will interact with the feature.

   SC: Right now, we don't have an explicit plan to implement this
   API yet.

   Jer: If every UA is going to have a "stop" button in the
   picker, then having a method called "connect" is a bit weird,

   PROPOSED RESOLUTION: For issue #4, no "stop" method, add
   guidance that UA should provide a way to disconnect, and rename
   "connect" method into something like "showDevicePicker"

   <anssik> coffee break, back 10:45am

Define the UA behavior when the disableRemotePlayback attribute is
added during the remote playback (#6)

   -> [32]Issue #6

     [32] https://github.com/w3c/remote-playback/issues/6

   Anton: How should disableremoteplayback behave when it changes
   after playback starts?
   ... Simple way, if playback is happening, ignore it.
   ... Other way, is harder, to make the attribute live. If set,
   we disconnect and stop remote playback, reject Promises.
   ... In Safari it's live.

   Jer: Not a use case driving that decision. We chose to do it

   Jonas: Removing it should be false.

   Jer: Don't think there's a use case. Fine with simplifying

   Edward: Example is muted. Changing it later does not have an

   Anton: allowfullscreen is only respected when the iframe is
   created. Changing afterward is no effect.

   Anssi: For consistency, we should follow the cow path of
   allowfullscreen et all.

   Jonas: If the attribute is removed, it should revert to default
   false (live).
   ... The UI should show up (or be removed) on insertion/removal.
   ... Live for enabling discovery, but not for shutting down

   Anton: How would availability behave? Would it affect the
   availability state/

   Jer: Could make it a UA decision. Anton: If we remove it,
   re-enable discovery.

   PROPOSED RESOLUTION: Use Anton's first proposal (no spec
   language to address this case). Add a non-normative note that
   existence of attribute is a hint for discovery.

   PROPOSED RESOLUTION: Refine behavior of existing alg's for
   attribute, i.e. Promise rejections would reference it.

Allow the user agent to choose which media element source to play
remotely (#7)

   -> [33]Issue #7

     [33] https://github.com/w3c/remote-playback/issues/7

   Anton: How the user agent chooses which source to play
   remotely. Does page provide hint, does UA provide source.

   Ideally, pass all sources to remote device, it chooses.

   Jer: YouTube, could not remote a MSE URL. When they want to
   AirPlay, they would have to swap source, or use a hidden

   Jonas: Could have a remote source URL

   Edward: Remote friendly attribute for src

   Jer: If you want it to work naively, hand entire set of
   elements to device, have it choose which ones to remote.

   Edward: Way to flag elements that are particularly good for

   Anssi: The only reason is if you knew something about the
   remote device.

   Edward: There is a media attribute which could be used for this

   Jonas: Does MSE override any source attributes?

   Jer: Create a blob URL from a media source, assign it to

   Mounir: We do want to support MSE. Anton: Can use mirroring or

   Jonas: Should availability reflect the source list?

   Edward: For power saving, can't always determine capabilities
   of individual devices.

   Mounir: Spec does take source list into account. Implementation
   may vary because of codec reasons.

   Jer: If you choose to play, you would get a network or format
   error if the chosen device isn't compatible.
   ... Similar to local playback.
   ... Do we need to spec source selection? Mounir: Not sure, ask

   <scribe> ACTION: Investigate HTML source selection algorithm to
   decide if it is applicable. [recorded in

   (Assign to Phillip b/c he's not here)

   PROPOSED RESOLUTION: Anton to update spec to be clear that
   entire source list is considered for availability (if possible)
   and remote playback

Specify the transition between the local and remote playback when
changing remote.state (#25)

   -> [35]Issue #25

     [35] https://github.com/w3c/remote-playback/issues/25

   Anton: When does the state need to be synchronized between
   remote playback and media element state?

   Jer: Maybe we don't need to be explicit about this as long as
   the behavior of the element is defined.

   Anton: What about connecting state? How should changes to the
   element take effect, do we need to buffer them?

   Jer: HTML media is async. Can fire events later, after state is
   synchronized to remote playback.

   Mounir: When connecting, what happens if you call connect()
   then play(). User experience will differ unless specified.

   Francois: May be adding unknown latency depending on
   responsiveness of the device.

   Jer: If we can have all the normal events fire, without having
   spec language. For example, playing would fire when the remote
   device had buffered enough data.

   Mark: "connecting" adds latency for network sensitive events
   that would normally fire during playback.

   Mounir: While you are connecting, remote player becomes active

   Anton: We don't have these concepts in the spec.

   (remote player vs. active player)

   Anton: Websites don't change experience, so we may end up with
   broken player if the Promise rejects during connecting.

   Mounir: Could say that during remote playback (connected),
   anything in HTML5 media applies to remote player.

   Anton: In connecting state, act as if local playback is

   PROPOSED RESOLUTION: Anton to define local and remote player
   concepts in spec as source of behavior for media element. In
   connecting/disconnected state, local player is active. In
   connected state, remote player is active.

[Meta] Guidance for HTMLMediaElement, HTMLAudioElement,
HTMLVideoElement behaviors during remoting (#41)

   -> [36]Issue #41

     [36] https://github.com/w3c/remote-playback/issues/41

   Mark: Question is if you are remoting, will there be any
   visible difference for apps?
   ... In some cases, devices may not support some of the media
   features, such as playbackRate, closed captioning, etc.
   ... How should things behave?
   ... I don't expect this to be solved today, but that will
   improve the quality of the spec over time.

   Mounir: That's also what my proposal about "local player" and
   "remote player" is about.
   ... We should have a list of features that are mandated (such
   as play, pause) and others that don't need to be such as
   ... Do you want to specify everything explicitly?

   Mark: There should be a set of defined behaviors, a set of
   undefined behaviors, and a few things in between.

   Mounir: What happens when you set the volume in iOS?

   Jer: There is no volume attribute on iOS so you cannot set it.

   Mounir: You can definitely imagine that the UA connecting to a
   device without knowing all the capabilities of the device.

   Anssi: I think we're moving to this new territory where we have
   UAs with different capabilities.

   Mark: Here we have one element that can be in two different

   Anssi: We cannot anticipate all the features that media
   elements will have in the future.

   Jer: Would it be enough that UA should make best effort to
   reflect the remote playback locally?

   Mounir: I think that would be fine.

   Anton: I think listing all the features in the spec would be a
   bit of a stretch.

   Mark: The more we leave it to implementations, the more the
   risk that we may break existing Web sites that may expect the
   "local" behavior.

   Francois: Right, e.g. sync use cases with TextTracks that would
   expect currentTime to be accurate.

   Anton: We could extend the requirements doc to list the set of
   minimal features that we would expect devices to support.

   Anssi: Guidance or normative assertions?

   Anton: Tests for play/pause and seek would be good.

   Anssi: You also mentioned setting playbackRate, fast seek.

   Mounir: For example, playbackRate was not supported on Android.
   ... Maybe we can expose a capabilities project if we detect
   issues with implementations.
   ... Over-engineering the issue right now is probably not a good

   Jer: You could specify the list of capabilities as in
   getUserMedia to filter the list of remote devices displayed to
   the user in the picker.
   ... I don't think we should do it now.

   Mounir: Yes, I would expect most sites to just require
   play/pause and seek.

   PROPOSED RESOLUTION: Extend the requirements doc as a start,
   best effort for UAs to reflect remote state locally otherwise.

Define the interaction with Media Session (#10)

   -> [37]Issue #10

     [37] https://github.com/w3c/remote-playback/issues/10

   Anton: For media sessions, do we want media element to stop
   playback of the other one.
   ... Do we want any behaviors to be excluded?

   Mounir: Remote playback should have its own MediaSession. When
   element leaves, it leaves its session.

   Anton: Two independent remote playbacks should be possible.

   Edward: Global controls work the same way. Can't play locally
   and remotely
   ... Could wire up hardware controls to Airplay from desktop.

   Mounir: On Android if you Cast to two devices, and locally,
   they are independent.

   Jonas: If you create a session that is remote on one page, and
   play some content on another page, the first page should not be
   ... Hard to do if Media Session is not as well defined.

   Mounir: Media Session got shaved aggressively. Jer: Intern
   implemented a subset of it behind a compile flag.

   Jonas: Not moving forward with implementation at this time
   given recent state of the spec.

   Anssi: A bit premature to think of integration.

   <scribe> ACTION: Mounir to update issue with comments about
   remote and local don't fight over output, and suggestion that
   remote playback can access keys. No spec changes at this
   juncture. [recorded in

Publication as a FPWD (#12)

   -> [39]Issue #12

     [39] https://github.com/w3c/remote-playback/issues/12

   Anssi: Requirements are met by changes to this juncture.

   Edward: Collect edits from this meeting.

   Anton: Can publish a FPWD in about 4 weeks.

   Anssi: As early as possible, send a 2? week CFC. Target end of
   ... Triggers call for exclusions so scope is important to get

   <scribe> ACTION: Anssi to send a CFC once edits are done.
   [recorded in

   <scribe> ACTION: Anton to collect edits and coordinate timing
   with Anssi. [recorded in


     [42] https://github.com/w3c/remote-playback/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3AF2F

Presentation API

   Anssi: Goal is to go through issues that block publication as
   ... The spec has had many iterations already. Next step is
   Candidate Recommendation.
   ... If all goes well here, we should be able to publish a CR
   sometimes in June.
   ... By publishing a CR, we say that all features are in,
   technical issues are closed, and we signal people that they can
   look at the spec and start implementations (already started in
   ... We have processed a long list of issues prior to the F2F
   ... Summary of recent changes?

   Francois: First one is horizontal review with accessibility
   group. Agreement not to change anything in the spec.

   Mark: Possibility to use Stream interfaces. Streams are still
   at an early phase today. We discussed possible changes, but
   we're not going to do it today.
   ... The spec now recommends the controlling UA to pass on the
   locale settings to the receiver UA so that it may use these
   settings to fetch and render content
   ... Fourth issue was around providing a congestion control
   mechanism (bufferedAmount property). The conclusion was that
   without having a concrete messaging protocol, it would be hard
   to specify

   Francois: And no one really asked us to add it at this point.

   Mark: The spec now recommends to use the UUID algorithm to
   generate the Presentation identifer and passed from the
   controller to the receiver side.
   ... When you call getAvailability more than once, you now get
   the same object back.
   ... Last one was about setting the default value of the closed

   Anssi: Thanks. That leaves us with four main issues for the

Is a new Permission type required for presentation display
availability (#255)

   -> [43]Issue #255

     [43] https://github.com/w3c/presentation-api/issues/255

   Mark: The conclusion from Mounir is that a new permission type
   is not required.

   Mounir: Exactly. Note I'm the editor of the spec.

   Jonas: The one thing that people want with the Permissions API
   is to tell whether there will be a prompt.
   ... If I call start, will there always be a prompt?

   Mark: It can not be 100% guaranteed.
   ... There may be cases where the UA knows that the user gave
   permission to use a remote device, it may skip the permission
   ... No one has done that though.

   Mounir: It's a selection list.

   Jonas: As long as no one has implemented it, then we don't need
   to worry about that.

   PROPOSED RESOLUTION: re. #255, no new permission type required

   <scribe> ACTION: Mark to close issue #255 with summary of
   discussions. [recorded in

Topic: User Data Controls in Web Browsers guidelines (#275)

   -> [45]Issue #275

     [45] https://github.com/w3c/presentation-api/issues/275

   Mark: Travis gave us a report from TAG related to the Privacy
   mode spec.

   Francois: [going through review]
   ... By having normative prose in the spec, we're forcing a
   definition of privacy mode onto implementers and we are not

   Mark: To be clear, this is not about defining a privacy mode,
   but an interoperability issue.

   tidoust: can we in our spec say: clear site data
   ... and have that be the normative step
   ... including IndexedDB, Cookies, etc. to be open for future
   extensions to what constitutes site data

   sicking: private browsing is an area that is evolving, no
   interest to write a spec

   mounir: can we say empty all site data, and reference the TAG
   document that defines what is site data

   tidoust: we omit Service Workers, AppCache already in the spec

   mfoltzgoogle: agree this needs to be future-proof

   tidoust: can add an informative guidance referencing the TAG

   PROPOSED RESOLUTION: complete the clear site data steps in the
   spec (add AppCache, Service Workers) and add non-normative note
   referencing TAG document for more complete list, add note
   clarifying this is not about defining private mode

   <scribe> ACTION: tidoust to inform TAG when the PR re clear
   site data lands and submits his feedback to TAG [recorded in

Interoperability and presentation request URL fallback mechanism

   -> [47]Issue #153

     [47] https://github.com/w3c/presentation-api/issues/153

   Mark: I can give an implementation update on interoperability.
   ... Google Chrome supports Cast devices and DIAL devices as
   secondary displays.
   ... as well as other device types that are specific to Google.
   ... We don't currently support any truly generic display.
   ... We have intention to support wired secondary displays as
   well as potential Bluetooth or other wireless devices, but not
   concrete timeline.

   SC: In Mozilla, we try to aggregate the protocols for the
   discovery and device communication. It's only a draft spec for
   the time being.

   Mark: That's for the open protocol discussion of tomorrow,

   SC: Right.

   Mark: Any proprietary support you can talk about?

   SC: For 1UA, we try to support HDMI.
   ... For 2UA, we have one proprietary implementation for our
   Firefox-only devices but I'm also co-developing an open
   ... For 2UA, since we are casting the entire Web page to the
   device, it does not really specify what type of video you can

   Mark: For Cast devices, we only support 2UA mode, and only for
   applications registered.
   ... The only other 2UA experience we support is Youtube through
   ... We also have plans for 1UA support through WebRTC on Cast,
   but some plumbing still required.

   Jonas: For 2UA mode, is that an HTML application that gets
   installed on your Chromecast device?

   Mark: You have to register the app, which gives you an ID.
   ... Through the Presentation API, you just pass the URL, and
   the ID needs to be added by the developer.

   Jonas: If I add my own ID, does it ignore the URL?

   Mark: Currently, yes.

   Jonas: That seems problematic. If I register a Cast application
   and get abc123 and call the Presentation API with
   [48]https://gmail.com/blah#abc123, you'll just be fine and
   ignore the URL.

     [48] https://gmail.com/blah#abc123,

   Mark: Yes.

   Jonas: Generally speaking, if people can pass anything, they
   will pass anything. So when you start playing with 1UA mode and
   start to take the URL into account, you'll start to have
   strange behaviors.
   ... It seems safer to pass chromecast://[id] URL.
   ... It seems wrong to pass an ID within a URL that is not
   designed for that. It may break interoperability.

   Mark: Practically speaking, we don't expect the Presentation
   API to be used outside of the Cast SDK.

   Francois: What worries me is that, as a developer, it is as if
   I have two parameters with one being used by one implementation
   and another one being used by another implementation.
   ... So I could have a typo in the URL and that would still work
   in the Cast case but not in other cases.

   Jonas: Using a URL is the right thing to do. But using an HTTP
   URL seems wrong.

   Mark: This is forward-looking for the 1UA case.
   ... We could switch to "cast://" URL easily.

   Anssi: The practical issue that will come up next is with
   regards to testing.

   Mounir: When I suggested to use an array of URLs, feedback was
   that the developer could simply re-implement the behaviour

   Mark: both Cast and DIAL have proprietary extensions.

   Anssi: Would it be better to massage that as a specific

   SC: I don't think we should add too many things on the URL,
   because it would then need to be decoded before it can be used.

   Anssi: I think this is a pretty critical issue to solve.

   Chris: Is this the same issue as Matt Hammond raised for
   compatibility with HbbTV?

   Francois: Yes, although in the case of HbbTV, you need
   additional parameters on top of the URL. In the case of Cast,
   the app ID replaces the URL.

   SC: But you will expect other receivers to load content for the
   HTTP URL, not to resolve the app ID, right?

   Mark: Right, we won't require such a resolution.

   [Discussion on using specific URL for specific implementations,
   which would require developers to try alternatives]

   Mark: If you have both a Cast device and a DIAL device, there
   would be no way to give a choice to use both devices in the
   selection list

   Mounir: In that case, you need PresentationRequest to take an
   array of URLs.

   Francois: Other implementers may also require a fragment
   identifier for their own registration mechanism. The developer
   would have no way to combine the URLs in the same call if they
   cannot pass an array.

   Mark: The concern about the array is what do they mean. Order?

   Jonas: Yes, the goal would be to display a union of the devices
   that can support these URLs.

   Anssi: How would the algorithm work? The order would be

   Mounir: The UI would show the list of all compatible devices.
   When the user picks up a device, the UA should pick up the
   first URL that appears in the list that is compatible with the
   ... That may not be complicated to specify.

   Mark: The one argument that I agree with is that it breaks
   interoperability with fragment identifiers.
   ... I need to check internally, I support the switch to an
   array of URLs if that's the case.

   [Further discussion between Mark and Mounir about Cast examples
   that involve Firefox for Android]

   Mark: Generic question is on ways to support proprietary

   Jonas: The situation is similar to what happens to codec, it's
   a reality of life.
   ... I would definitely imagine that Netflix might want to use a
   DIAL app if it's there and then fall back to an HTML5 app if

   Anssi: Should we park this issue for the time being and get
   back to it tomorrow morning?
   ... Two proposals: 1) do nothing, 2) have an array of URLs

   [group agrees to get back to issue [49]on day 2]

     [49] http://www.w3.org/25-webscreens-minutes.html#item03

Define behavior of Window and Fullscreen APIs in the presentation
browsing context (#99)

   -> [50]Issue #99

     [50] https://github.com/w3c/presentation-api/issues/99

   Mark: Several related questions raised in this issue.
   ... Some of them are much more CSS-oriented
   ... which is not my area of expertise.
   ... First issue is for presentations. Do we want to block the
   use of certain APIs that require user interaction?
   ... Prompt, confirmation, print, etc.
   ... We could say nothing, prevent them, change behavior

   Jonas: I think no one uses that in real apps. We did a great
   job at making prompt ugly ;)
   ... I don't think it's worth spending time on this.
   ... I do think that it would be nice to support input controls
   on a TV.
   ... It would be good to have a way to tell capabilities first,
   and then a way to get remote control inputs.
   ... That's a bigger task.

   Mark: Generally, in the long term, we're interested in how to
   design applications that can accept inputs and send outputs
   from/to multiple devices
   ... Here, we'd just want to ensure developers do not expect to
   get input from users.

   Anssi: Most of these things are historical things.

   Mounir: Yes, and some of them are ignored already in some
   situations (window resizing, open, etc.)
   ... We should add a note that alerts UA that APIs that require
   user interaction will not work and should be treated

   Anssi: Informative guidance.
   ... There was also the Inception case.

   Mark: I don't think it should be forbidden, it's just one of
   these examples where user input is likely going to be required

   Jer: Why should the Fullscreen API be supported?

   Mounir: It's not a requirement. It may just not work.

   PROPOSED RESOLUTION: For methods that would require user input,
   add informative guidance to UAs about the need to handle them

   Mark: About ::fullscreen and ::backdrop

   <Louay> My Slides for Testing session:

     [51] https://drive.google.com/file/d/0B5Pu35LKfJOIMXZtOVdkTlVmOVk/view

   Ed: I don't think we need to do anything there

   Mark: About requirements for media queries

   Jonas: It would be nice to be able to style things differently
   if we ran on the TV.

   Ed: The problem is that the types are exclusive.
   ... A TV is a screen.

   Anssi: Historical context is that "handheld" evolved over the

   Mark: I think it's not about TV vs. non-TV, but more about
   interactive vs. non-interactive.

   Jonas: My argument is that you probably need both.
   ... It's a little fluffy what the definition is.
   ... We have a spectrum today from laptop to smartphone, and the
   mobile query is extremely popular.

   Ed: I think that the distance from the screen which might want
   to make you to use a larger font has the counter argument that
   CSS pixels are optical, and that's totally fine.
   ... Etc.
   ... What is the case that makes the TV different?

   Jonas: What is the case where you want things different on
   ... A perfect developer would want to detect the things that
   impact them. In practice, it's much more realistic for them to
   target "mobile".
   ... Many people parse the User-Agent string to detect "mobile"
   and use that accordingly.

   Ed: In a lot of cases, we've mitigated the need by adding
   additional media queries properties

   Mounir: What do you do with TV in Firefox?

   SC: there is "TV" in the User-Agent string.

   Jonas: Having a way to detect "TV" in the User-agent string
   through media queries would be great

   Francois: Isn't there a proposal to have that in the latest
   version of CSS Media Queries with scripted criteria?
   ... Probably not implemented anywhere.

   Anssi: so it would be in CSS spec in any case. We can resolve
   this issue with a note that if there is a good use case, people
   should work with the CSS WG.

   Jonas: I think we should add a recommendation that "tv" should
   be in the User-Agent string

   Anssi: Would it be a problem to fiddle with the Chromecast
   user-agent string?

   Mounir: It would be, because you can present to things that are
   not TV.

   Jonas: True, but I don't know where we could stick that
   recommendation instead of in the Presentation API.

   PROPOSED RESOLUTION: No change to the Presentation API, feature
   would be addressed by the CSS WG if a strong use case motivates
   it. Open another issue about recommending to add "TV" to the
   User-Agent string.

   <Louay> Please use this link

     [52] https://drive.google.com/file/d/0B5Pu35LKfJOIbGNXeTNOaUIteHM/view

   <hyojin> WAVE Project:

     [53] https://standards.cta.tech/kwspub/wave/

   <hyojin> I think It could be referred for an interoperability
   of Remote Playback API.

Presentation API testing

   Anssi: We'd like an update on where we are with testing,
   potential issues identified, and next steps

   Louay: I've prepared a few slides, the link is in IRC
   ... 2 weeks ago we published the first test report for the
   Presentation API
   ... covering only IDL tests. We'll publish a second report this
   ... We plan to publish a 3rd test report by end of june. This
   could include messaging fuctionality
   ... [going through the slides]
   ... The working mode slide shows how to set up the test
   environment and conribute
   ... When we submit tests, we need them to be reviewed, and also
   run tests in different browsers
   ... In the last test report we tested on Google Cast devices,
   not sure about the Mozilla implementation
   ... It would be good to involve implementers in the testing
   activity to get more device coverage
   ... In the first report we had only IDL tests - in two parts,
   one for the Controlling UA, other for the Receiving UA
   ... We should also differentiate the 1-UA from the 2-UA cases
   ... [WPT slide] The green items are published, those in yellow
   are under review
   ... We need to do manual tests for cases where some user
   intervention is required - these are the files with
   -manual.html in the name

   Mark: Why does the reconnect have to be a manual test?

   Louay: Not sure, may be Zhiqiang can comment
   ... You need to first start a presentation, store the id, and
   then reconnect - it may be manual due to the starting the

   Zhiqiang: The test logic can be automatic, I think

   Louay: I hope this week or next to have a final version of
   these tests, and we'll publish a new version of the test

   Anssi: Mark, do you have any manual tests in your suite?

   Mounir: There are some for things that need gestures
   ... I'll get in touch with Louay and Zhiqiang

   <scribe> ACTION: Mounir to contact Louay and Zhiqiang to add to
   the test suite [recorded in

   Louay: [problems and open questions]
   ... If we need to run tests using the web platform test runner,
   this raises errors on receiver devices
   ... As the test runner opens windows for each test file, and
   this won't work on Chromecast and most receiver devices that
   have only one window
   ... We could use the Controlling UA and launch the presentation
   pages we want to test using the Presentation API

   Anssi: We could add a feature to the test runner, they accept
   pull requests

   Louay: We could use iframes in one page, but I'm not sure about
   the API implementation inside iframes, there may be differences
   from the main window
   ... For the IDL tests, I used a native application to start
   these tests on Chromecast
   ... Maybe we can use the Presentation API communication channel
   to report the test results back to the Controlling UA
   ... and run the test runner in the Controlling UA

   Anssi: Mark and Mounir, how is your test set up?

   Mounir: We don't have tests for receiving mode

   Zhiqiang: IN other scenarios we have used
   ... one iframe and communicated with another
   ... I've used the WPT test runner to run automated tests, and
   do the others manually, then combine the results

   Anssi: If that's doable, that's the right way forwards I guess

   Louay: The next open question needs feedback from the group -
   should we have different test reports for Controlling UAs and
   Receiving UAs?
   ... For the IDL tests, as they are independent of each other,
   we can split the tests and have two test reports
   ... For other tests, because the functions rely on both UAs,
   maybe we can collect the test results into one test report
   ... We need some identifiers for different combinations of
   Controlling and Receiving UAs, for devices such as Chromecast
   and Miracast etc
   ... We'll know more when we do the next test report

   Francois: We have to specify exit criteria to get the spec to
   CR status
   ... As part of this we need to provide the test reports to show
   at least 2 conformance passes
   ... It would be better to have separate implementation reports
   ... These could be manually generated from test reports from
   separate platforms

   Anssi: How many different back-ends should we require -
   Chromecast and Miracast were mentioned, where do we draw the

   Francois: We specify this in our exit criteria, we want two
   implementations of each feature
   ... The exit criteria will be reviewed by the Director when we
   go to CR
   ... I can start to draft something based on other recent specs,
   eg, getUserMedia
   ... Our case is a bit more complex as we have two conformance
   ... and two modes of operation
   ... The goal of the exit criteria is to determine
   interoperability, so we need enough coverage to show that

   Mark: The only representative implementations now are 2-UA

   Francois: I think the exit critera should cover both 1-UA and

   Mark: To demonstrate conformance with the Receiving UA, does
   this need to be in 1-UA and 2-UA? Do they have to be two
   different UAs?
   ... Is the goal of the exit criteria to show conformance of the
   UA in both 1-UA and 2-UA modes?

   Francois: Yes
   ... The implementation report needs to show that each feature
   is implemented in at least 2 UAs

   Mark: For 1-UA mode, would Chrome and Firefox be required to
   produce distinct implementations of the Receiving UA?

   Anssi: If we have two browsers using Blink, these often don't
   qualify as two interoperable implementations
   ... We may not have specific language in the Charter to define
   the implementations
   ... [describes charter]
   ... There's some flexibility for us to decide

   Mark: For 1-UA, Chrome and/or Firefox could support wired
   ... For 2-UA mode we have a couple of options, but to open this
   up to other browser vendors would require the open protocol

   Francois: We can have columns with Chromecast and Firefox OS TV
   as receivers

   Mark: Is each vendor required to implement both modes?

   Francois: No, that's not a requirement

   Anssi: We can always refine the test suite and add more
   implementation data, adding more columns for different devices
   as senders and receivers
   ... It could be even more complex, with a matrix of senders and
   ... Some vendors could only implement the sender, others only
   the receiver, this is one of the goals of the open protocol

   Francois: I propose to draft exit criteria

   <scribe> ACTION: Francois to craft exit criteria for PR status
   [recorded in

   Louay: To run some presentations on Google Cast we need to
   register in the Cast console, then use an ID as a hash
   parameter in the URL
   ... [describes test]
   ... [discussion of Google Cast app ID and client ID values]

     [56] https://github.com/w3c/web-platform-tests/pull/3062/files

   Zhiqiang: We should also use the relative URL in our test suite

   Louay: Are relative URLs supported in Google Cast?

   Mark: I believe so, but you'd have to try it

   Louay: Do we need to include some Cast receiver library in the
   receiver page?

   Mark: I believe you need to include the SDK and initialise it

   Louay: Is there a specific name used for the communication

   Mark: You can make up a name and sent it across, I can share
   some docs on how to do that

   Louay: Another question for Mozilla: Is there any way to run
   these tests on Firefox, what receiver devices can we use?

   schien: The receiver part is only on Firefox TV, so not
   available right now
   ... Our plan is to ship the 1-UA mode in Firefox for Android,
   then in September open up the 2-UA mode for Firefox for Android
   and Firefox TV

   Louay: We need at least one implementation to make sure our
   tests work
   ... We're currently working on testing in Chrome
   ... I may need more information when we look at messaging
   ... For the current features: availability, connect, launch,
   we're fine testing in Chrome

   Anssi: Do the IDL tests currently match the latest editor's

   Louay: Our last report wasn't on the latest draft, but I'll
   take another snapshot for the next test report
   ... Extracting the IDL from the spec is automated

   Anssi: What kind of test suite is needed for CR?

   Francois: We need a plan, but there's no requirement for a
   preliminary test report

   Mark: Do you run the tests on both Chrome desktop and Chrome

   Louay: Yes
   ... "CA50" indicates Chrome Android and "CD50" Chrome desktop

   Anssi: Maybe add a legend to expand these names

   Louay: The WPT has a readme file in each folder, where we
   describe the names

   Anssi: Thanks for all the work you've done
   ... It looks like we have what we need for PR
   ... We should keep up the speed and momentum

   Louay: We'd like to have more contributors for testing, I
   currently have two students working on it
   ... available until the end of July

   Anssi: Hyojin, could the WAVE project contribute tests?

   Hyojin: I'll check with the person in charge and contact Louay

   Zhiqiang: I have another person joining me to contribute tests

   Anssi: So there are 5 people now working on testing

   Louay: I'm not sure about the dates to target

   Anssi: Any other topics for testing?

   <scribe> ACTION: Louay to verify the URL issue is fixed in
   Chrome canary v5.3 [recorded in

   <scribe> ACTION: Mark to send Louay documentation on how to
   send messages to receiver apps [recorded in

   <scribe> ACTION: Everyone review the tests [recorded in

   Anssi: Any other topics?

Remaining issues

   Francois: There are still some open issues in GitHub to go
   through, looking those tagged as Enhancement
   ... There a 5 issues, four are P3
   ... Are we OK to address this in a future spec version?

   Anssi: I suggest changing the Enhancement tag to V2

   Francois: What needs to be done for #242?

   Mark: It's not a spec issue, I took an action to do this a
   while ago

   Francois: #283 error handling

   Mark: There's detail in step 5, can be put into a pull request

   <scribe> ACTION: schien to send a pull request to define error
   handling on failure to establish presentation connection (#283)
   [recorded in

   Francois: I think #293 has been done?

   Mark: It's still open from the previous pull request

   <scribe> ACTION: Mounir to resolve #293 [recorded in

   Francois: #295 - references - I'm not sure if we can reference
   the WHATWG spec

   Mounir: The Remote Playback API currently only references

   Francois: That's fine for now
   ... It's only when we get to CR and PR that we need stable
   ... #299 Instead of patching HTML in our spec, we should
   propose a change to the HTML spec

   [ -adjourned- ]

Summary of Action Items

   [NEW] ACTION: Anssi to send a CFC once edits are done.
   [recorded in
   [NEW] ACTION: Anton to collect edits and coordinate timing with
   Anssi. [recorded in
   [NEW] ACTION: Anton to craft a PR to use observe/unobserve
   pattern for availability [recorded in
   [NEW] ACTION: Investigate HTML source selection algorithm to
   decide if it is applicable. [recorded in
   [NEW] ACTION: Mark to close issue #255 with summary of
   discussions. [recorded in
   [NEW] ACTION: Mounir to contact Louay and Zhiqiang to add to
   the test suite [recorded in
   [NEW] ACTION: Mounir to update issue with comments about remote
   and local don't fight over output, and suggestion that remote
   playback can access keys. No spec changes at this juncture.
   [recorded in
   [NEW] ACTION: tidoust to inform TAG when the PR re clear site
   data lands and submits his feedback to TAG [recorded in
   [NEW] ACTION: Everyone review the tests [recorded in
   [NEW] ACTION: Francois to craft exit criteria for PR status
   [recorded in
   [NEW] ACTION: Louay to verify the URL issue is fixed in Chrome
   canary v5.3 [recorded in
   [NEW] ACTION: Mark to send Louay documentation on how to send
   messages to receiver apps [recorded in
   [NEW] ACTION: Mounir to resolve #293 [recorded in
   [NEW] ACTION: schien to send a pull request to define error
   handling on failure to establish presentation connection (#283)
   [recorded in
   [End of minutes]
Received on Wednesday, 1 June 2016 07:57:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 1 June 2016 07:57:17 UTC