23:08:44 RRSAgent has joined #webscreens 23:08:44 logging to http://www.w3.org/2015/10/28-webscreens-irc 23:08:51 RRSAgent, make logs public 23:08:58 RRSAgent, this meeting spans midnight 23:09:14 Meeting: Second Screen WG F2F - TPAC 2015 - Day 1/2 23:09:18 Chair: Anssi 23:09:55 Agenda: https://www.w3.org/wiki/Second_Screen/Meetings/Oct_2015_F2F#Agenda 23:10:36 RRSAgent, draft minutes 23:10:36 I have made the request to generate http://www.w3.org/2015/10/28-webscreens-minutes.html tidoust 23:27:09 anssik has joined #webscreens 23:40:32 jinwoo_mbp has joined #webscreens 23:40:38 Youngsun has joined #webscreens 23:42:41 Louay has joined #webscreens 23:42:50 Present+ Anssi_Kostiainen 23:42:55 Present+ Francois_Daoust 23:42:59 Present+ Mohammed_Dadas 23:43:35 Present+ Shih-Chiang_Chien 23:44:09 Present+ Hyojin_Song 23:44:15 Present+ Louay_Bassbouss 23:46:15 Present+ Alexandra_Mikityuk 23:46:21 kenneth_ has joined #webscreens 23:46:32 hyojin has joined #webscreens 23:46:44 Present+ Kenneth_Christiansen 23:47:00 mdadas has joined #webscreens 23:47:23 Present+ Taejeoung_Kim 23:47:38 Present+ Jinwoo_Song 23:48:08 Present+ Mohammed Dadas 23:50:26 Present+ Youngsun_Ryu 23:51:03 Present+ Yukinori_Endo 23:51:36 Present+ Oliver_Friedrich 23:53:16 Present+ Edward_O'Connor 23:54:15 jcdufourd has joined #webscreens 23:55:02 TaejeoungKim has joined #webscreens 23:55:45 mdadas has joined #webscreens 23:56:06 Present+ Chris_Needham 23:58:06 Present+ Mark_Foltz 23:58:11 hyojin_ has joined #webscreens 00:00:38 Present+ Takeshi_Kanai 00:01:30 scribe: tidoust 00:01:58 Louay has joined #webscreens 00:02:17 takeshi has joined #webscreens 00:02:59 Present+ Rijubrata_Bhaumik 00:03:55 [Anssi kicking off the meeting] 00:04:53 Zakim has joined #webscreens 00:05:01 q+ want to ask about something 00:05:19 q- want 00:05:26 q+ to ask about something 00:05:31 q? 00:05:32 tomoyuki has joined #webscreens 00:05:32 cpn has joined #webscreens 00:05:45 Present+ Tomoyuki_Shimizu 00:06:12 mfoltzgoogle has joined #webscreens 00:06:20 RRSAgent, draft minutes 00:06:20 I have made the request to generate http://www.w3.org/2015/10/28-webscreens-minutes.html tidoust 00:06:35 Anssi: [a few reminders]. All the decisions we take at this meeting are provisional. 00:06:56 ... People who can't attend this meeting will have the possibility to react to these resolutions. 00:07:10 ... Pending no comment, the resolutions are considered final two weeks after the meeting. 00:08:11 ... Plan is to close at 03:00pm to allow people to go to ad-hoc meetings. 00:08:31 ... If we consider that we haven't reached our goals, we may extend this deadline. 00:08:47 ... Meeting starts at 09:00 tomorrow as well. 00:09:02 i/[Anssi kicking off the meeting]/Topic: Introductions 00:09:14 Anssi: Quick round of intro. 00:09:22 ... I'm the chair of this group. From Intel. Interested to make progress. 00:09:55 Mark: From Google. I'm the editor of the Presentation API. Also working on the implementation in Chrome. My interest is to enable second screen in general. 00:10:19 Tomoyuki: From KDDI. Several use cases that use both the tablet and a large screen. 00:10:45 Takeshi: From Sony. Working on an ink notepad. Intersted to share the screen on this device. 00:10:53 ... Also interested to control that device remotely. 00:11:12 Chris: From the BBC. Discovery of devices on local networks. 00:11:39 SC: From Mozilla. Firefos OS engine. Open solution for the Presentation API. 00:12:19 Hyojin: From LG. Applying the API to LG product is intersting for us. 00:12:37 Louay: From Fraunhofer FOKUS. Work in the Multi-Screen domain since 5-6 years. 00:13:00 ... Interested to see an interoperable solution 00:13:17 Ed: From Apple. New participant of the WG since Tuesday. 00:13:23 Anssi: Welcome to the group. 00:14:18 Youngsun: From Samsung. First time in the Second Screen WG. Working on broadcasting standardisation (ATSC, HbbTV). Interested to align the spec with these standards. 00:14:29 ... e.g. with HbbTV which has some second screen solutions. 00:15:00 Taejeoung: From Samsung. Interested in applying the Presentation API to products. 00:15:00 Youngsun has joined #webscreens 00:15:41 Jinwood: From Samsung. Samsung Web engine. Presentation API for Samsung mobile devices and TV browsers. Looking forward for interoperability between devices and browsers. 00:16:07 hober has joined #webscreens 00:16:09 Mohammed: From Orange. Interested to see how we can use the Presentation API in Orange services. 00:16:13 fwtnb has joined #webscreens 00:17:11 Francois: From W3C. Interested in standards, of course. Excited about multi-device. 00:17:36 [Looking at the agenda] 00:17:51 Anssi: Before lunch, plan is to go for P1 issues. 00:18:34 mdadas has joined #webscreens 00:18:34 ... Then we'll go over P2 issues. 00:19:26 Mark: We're doing the horizontal reviews and someone coming from WebAppSec tomorrow. Would it make sense to move issue #80 to tomorrow so that Mike West can contribute to this discussion? 00:19:54 Anssi: WebAppSec is next door. Let's see if we have confirmation that he can join. 00:20:50 [agenda updated on the Wiki] 00:21:19 Anssi: Any additional item that you'd like to discuss that has been brought up in discussion this week for instance? 00:21:36 Topic: Assess interoperability of Presentation API in implementations (#153) 00:21:56 -> https://github.com/w3c/presentation-api/issues/153 Issue #153 00:22:07 Anssi: Brought up by Anne as part of the TAG review 00:22:23 ... Anne would have liked to see the whole stack specified. 00:22:43 ... Mark looked at this, Louay worked on a landscape document. 00:23:04 ... We should come up with a group proposal to address the issue. 00:23:29 ... Clearly, under the group's charter, we cannot mandate protocols. But, this work could happen in other groups or other organizations, e.g. IETF. 00:24:14 Mark: I think the charter is fine as it is. The API should work both with open and proprietary protocols. I do acknowledge that there is no protocol right now that we can point to that addresses our need. 00:24:53 ... I'm happy to collaborate with others, but I need to identify collaborators to work on that. 00:24:54 q? 00:24:59 q- anssik 00:25:12 akitsugu has joined #webscreens 00:25:21 ... We're having a meeting with Mozilla in a couple of weeks, and this is on the agenda. If we agree, then we could perhaps propose something. 00:25:57 ... There are different protocols that are of interest for the different pieces, including WebRTC, TLS, mDNS and the like. 00:26:05 ... Some good discussion in a breakout session yesterday. 00:26:24 ... Based on internal discussions, the IETF is probably the right place to start the work on creating a stack for that. 00:26:44 ... One spec that defines the API and one spec that defines the protocol stack. 00:26:47 fwtnb_ has joined #webscreens 00:27:16 SC: This topic has been discussed. Mozilla has not shared all of our protocol stack with Google yet. 00:27:28 Mark: We wanted the spec to stabilize a bit before. 00:28:14 Anssi: It seems that the group's response is that we want to leave the door open for implementations to use their own protocols and also to standardise protocols. 00:28:14 Secure communications with LAN devices breakout session: https://www.w3.org/wiki/TPAC/2015/SessionIdeas#Secure_communication_with_local_network_devices 00:28:40 Ed: Presentation API for local display presentations do not require protocols at all, actually. 00:28:57 Anssi: True. Airplay, Miracast are good examples of 1-UA protocols. 00:29:48 Francois: This issue is indeed scoped to the 2-UA case. Does not apply to the 1-UA case at all. 00:30:15 [Presenting interoperability document] 00:30:25 mdadas has joined #webscreens 00:30:28 Louay: Lists the technologies that are interesting to implement this API. 00:30:42 ... Two parts, one for 1-UA cases and one for 2-UA cases. 00:31:07 ... As Mark said, there is not a single protocol that can achieve the whole thing. I split topics into different steps. 00:31:45 ... In the 2-UA case, you have a controlling user agent, with two parts for the Presentation API, one running on the controller and the other running on the receiver. 00:32:33 ... The controller needs to discover the receiver, launch the browser and URL on the receiver, creates a communication channel. Also, for signaling, there needs to be some way to exchange the state of the presentation session. 00:32:41 ... And of course there are security considerations. 00:32:55 https://github.com/w3c/presentation-api/blob/gh-pages/interoperability.md 00:33:14 ... For discovery, SSDP, mDNS, BLE are just examples here. Other things such as QR code or NFC would be possible. 00:33:44 ... These discovery protocols are often linked to launch mechanisms. For instance, DIAL uses SSDP. Chromecast uses mDNS. 00:34:30 ... For Launch, DIAL, Google Cast. HbbTV 2.0 is more than just launch since it also touches on communication. 00:34:41 ... In HbbTV, there will be a WebSocket server in the HbbTV device. 00:35:07 ... HbbTV compatibility is discussed in another issue. 00:35:29 ... For communication, WebSockets, WebRTC, Raw Socket or Google Cast are examples of technologies. 00:35:47 ... For signaling, this is open. That part is specific to the Presentation API. 00:36:19 ... For security, different solutions are possible, open issue for the group. 00:37:01 ... Now, in the 1-UA case, the question of interoperability is less of a concern, because everything is done by the controlling side. 00:37:26 ... HDMI, Intel WiDi, Miracast, Airplay, MHL (although I'm not 100% sure). 00:38:13 ... I don't think we can use WebRTC directly. You need some sort of discovery mechanism, as mDNS in Google Cast. 00:38:42 Mark: Discovery gives you the signaling endpoint, and then you use the signaling endpoint to launch the application, and then establish the communication channel. 00:39:41 wonsuk has joined #webscreens 00:40:30 ... Back to signaling, a signal connection will be used for different presentations. The standard will have to address how you address multiplexing on either end. 00:40:43 ... You want to share that connection between presentation sessions. 00:41:13 SC: In our current implementation, we try to establish individual connections for each session but only use one entry point for bootstrapping the communication channel. 00:41:33 ... We want to isolate all the communications between the end points to make it more secure. 00:42:35 a12u has joined #webscreens 00:42:58 Anssi: Thinking about how to move forward with this issue. Anne's concern was that the full stack is not given. What are the gaps for RF standards? 00:44:01 Francois: I think the main gap is around launch and signaling. 00:44:17 Anssi: Would we need to extend the existing protocols? 00:44:41 SC: My understanding is that we're still missing blue parts between protocols. 00:45:03 ... For instance, for discovery, you need to specify which type of service you're willing to launch. 00:45:06 s/blue/glue/ 00:45:40 Mark: I believer that there are uncumbered technologies, but indeed the link between them is not necessarily specified. 00:46:08 ... Authentication handshake, etc. I'm not concerned about each of them but someone has to do the links, indeed. 00:46:34 Anssi: OK, I think that there are different places where this could be done. I guess we'd want the place where we'd have the least friction. 00:46:48 ... One option would be the Community Group. Another would be to approach IETF. 00:47:05 ... Do group participants have preferences? Would you want to contribute? 00:47:28 Mark: Most likely interested 00:47:39 SC: we would have something to contribute 00:47:45 Louay: As well. 00:50:18 Francois: I think the CG would provide the right framework for this to incubate the idea and precise the gaps. It may be too early to go the IETF, although it's certainly the right place to do that and I'm sure you have connections in it. 00:51:23 Anssi: OK, the CG has been dormant for the time being. I'm chair of the CG as well. It seems a good idea to look into re-chartering that group to incubate idea of interoperable protocols for the Presentation API. 00:52:20 ACTION: Anssi to trigger the re-chartering discussions of the Web Screens Community Group around the idea of interoperable protocols 00:52:27 Chris: I think we would be interested as well. 00:52:46 Anssi: It sounds that there is enough interest for creating a group and making progress on it. 00:53:24 kiyoshi has joined #webscreens 00:53:32 Louay: Will interoperability be considered for the 1-UA case? 00:53:46 Anssi: I don't think there is such a hard requirement for interop in this case. 00:54:55 Mark: I'm concerned that if we scope this work to the 2-UA case, it raises the bar on requirements on the second screen. Same thing if we restrict this to the 1-UA case. 00:55:07 MikkoT has joined #webscreens 00:55:21 Anssi: So are we in agreement to include both the 1-UA and 2-UA cases for the CG discussions? 00:55:41 present+ MikkoT 00:55:43 Mark: I'm not suggesting that we should discuss priorities as part of these discussions. 00:55:53 Anssi: OK. 00:58:35 Francois: For the official response for this issue, I think it should start by mentioning the scope of the WG. It was not an oversight but rather a will to have the API agnostic of the underlying protocols. And then we should of course mention the plan. 00:58:42 Anssi: OK, I'll draft the answer. 00:59:06 ACTION: Anssi to draft a reply to issue #153 based on F2F discussions. 00:59:35 Mark: We may have more concrete feedback after meeting with Mozilla. 00:59:56 Anssi: OK, let's leave it open whether it is the CG or some other group enacting the plan. 01:02:45 ... We'll cover the TAG review with Travis tomorrow. 01:03:02 wonsuk has joined #webscreens 01:03:17 Mark: The 1-UA case with directly attached displays should be supported by all implementations. 01:03:24 Francois: I wonder if the spec should mandate that. 01:03:37 Ed: That use case is the one you would expect everyone to support 01:03:41 Francois: Exactly. 01:04:02 Mark: This does seem like an important implementation guideline at least. Not sure if it raises to the level of requirement. 01:04:45 Mark: The more you mandate, the better interoperability you get, for sure. 01:05:09 Anssi: A device may not have an HDMI, MHL, or whatever connector, so we may leave these devices out. 01:05:28 Mark: Are you concerned that by mandating this, it would make it too hard to implement? 01:05:39 Anssi: No, rather would that make some devices unable to conform? 01:06:04 Ed: I don't think that it's a problem. 01:06:15 ... It can still be useful to one display. 01:06:27 Mark: You could have a virtual display for instance. 01:06:35 ... That should be the absolute minimum. 01:06:40 Anssi: It sounds promising. 01:07:21 hax has joined #webscreens 01:07:28 Mark: My caveat is that we should offer that but it should be an opt-in for the user, because otherwise you end up with displays that are always available. 01:07:39 Anssi: It sounds that we should have some text in the spec along these lines. 01:07:43 yubo_ has joined #webscreens 01:07:45 Mark: I'll take a stab at this. 01:08:03 wonsuk has joined #webscreens 01:09:31 ACTION: Mark to craft a PR to investigate requiring (or strongly recommend) support for attached displays 01:09:45 Anssi: Schih-Chien, fine with this? 01:09:48 SC: I think so. 01:10:18 Anssi: I think we're done with this issue. Thanks. 01:10:38 Topic: Define behavior when sending a message to a PresentationSession fails (#149) 01:11:01 -> https://github.com/w3c/presentation-api/issues/149 Issue #149 01:11:16 Anssi: Issue opened for a couple of months. 01:11:33 Mark: Two questions to answer: 01:11:48 ... 1. How do we notify the sender that this message could not be delivered? 01:12:08 ... Since the communication channel is supposed to be reliable, it's unclear we should keep the channel open. 01:12:32 ... If we keep it open, it kind of implies that the implementation will retry without telling the app. 01:13:46 tomoyuki has joined #webscreens 01:14:16 ... In that scenario, one possibility was to have send return a Promise. Not entirely clear what that gives you. The other possibility is to throw an exception. That's a bit tricky because the send is asynchronous so you cannot really tell beforehand that the send will fail. 01:14:24 Anssi: I agree, throwing an exception does not work. 01:15:05 Mark: With the Promise case, we cannot resolve that promise before the message is delivered. And there will be latency introduced if you have a batch of send to make. 01:15:13 Anssi: Aren't we reinventing TCP here? 01:15:17 Mark: Sort of. 01:15:31 ... The alternative is an error event. 01:16:03 oonishi has joined #webscreens 01:16:41 Francois: It seems important to align with existing standards such as WebSocket, which uses an error event. 01:16:51 Mark: That's my conclusion as well. 01:17:13 Anssi: In the issue, that's 1. and 4. options. 01:18:07 rrsagent, draft minutes 01:18:07 I have made the request to generate http://www.w3.org/2015/10/28-webscreens-minutes.html tomoyuki 01:18:16 Mark: Actually, 1. and 2. (closing the presentation session). 01:18:50 kiyoshi has joined #webscreens 01:19:37 SC: Wen you send in a message, if the user agent finds that there are underlying issues, then it may want to retry under the hoods, and only report the error if that fails. 01:19:49 Francois: That sounds pretty reasonable to me. And implementation specific. 01:20:11 SC: The browser needs to somehow queue the messages anyway. 01:20:18 Mark: Right. 01:21:02 PROPOSED RESOLUTION: For issue #149, adopt options 1. and 2. 01:22:17 Mark: What the RTC data channel does is a bit more complex. Pages that care about knowing that the connection was closed because of that may listen to that event. 01:23:31 ... Option 4. is under the hood. Implementations will likely do that. Not for the spec though. 01:24:52 lsf has joined #webscreens 01:24:56 ... Mounir would like to get the message that failed to be delivered. 01:25:13 Francois: So a specific error construct will need to be specified? 01:25:16 Mark: Right. 01:26:01 PROPOSED RESOLUTION: For issue #149, adopt options 1. and 2. and define an error event that reports the message that could not be sent 01:26:32 [No objection heard] 01:26:32 RESOLUTION: For issue #149, adopt options 1. and 2. and define an error event that reports the message that could not be sent 01:26:56 Topic: Overview of the Presentation API 01:27:31 scribe: cpn 01:27:44 RRSAgent, draft minutes 01:27:44 I have made the request to generate http://www.w3.org/2015/10/28-webscreens-minutes.html tidoust 01:27:47 [ overview of the spec https://w3c.github.io/presentation-api/ ] 01:29:27 Mark: The spec defined two conformance classes: the controller and the receiver 01:29:45 Present+ Kasar_Masood 01:29:46 ... When the receiver creates a presentation it creates a connection 01:30:09 ... To use the API, construct a PresentationRequest with a url to be presented 01:30:28 ... Then call start(), the user chooses a screen, and gets a connection 01:30:56 ... The connection has an ID, enables creating a second connection to that presentaion 01:31:14 ... PresentationAvailability tells you about availability of screens 01:31:59 ... PresentationConnection is how the controller and receiver communicate 01:32:16 ... Can use various mechanisms: could be a cloud server or a Bluetooth channel 01:32:44 ... PresentationReceiver is currently under debate. The presentation can communicate back to the controlling document 01:33:03 ... There's an onconnectionavailable event 01:33:55 ... The Presentation interface has a defaultRequest - allows us to put a UI into the browser to initiate presentations 01:34:05 ACTION: Mark to move the definition of the Presentation interface to the top of the spec (more logical order) 01:34:34 ... In future there could be other mechanisms such as NFC 01:34:47 ... Also transitioning automatically from mirroring to split-screen modes 01:35:22 Walkthrough of example 1 in the spec 01:36:03 s/example 1/code examples/ 01:41:31 Francois: Looking at example 5, can we assume the state is connected at the start? If the connection is created in the connected state, then this stage change event won't be generated. 01:41:52 https://github.com/w3c/presentation-api/issues/198 01:41:54 Mark: We have a bug filed already for this 01:42:37 ... Establishing a connection may require the user to authenticate the screen, eg, using a paring code 01:43:41 Francois: The issue is closed, but it's not clear. Is there a guarantee of the initial state of the connection object? 01:44:27 ... It's the 'theConnection' parameter in example 5 01:44:48 Anssi: Will reopen this issue 01:47:41 ACTION: Mark and Louay to rework example 5 and refine spec prose to clarify the initial connection state when the connection is created 01:48:32 Anssi: And now let's look at the recent spec changes 01:48:58 Mark: After the last F2F we met with Mozilla to look at the browser-initiated presentation use cases 01:49:28 ... We can handle the default request case more simply 01:49:41 ... and we introduced the availability object 01:50:05 ... Devices that don't support background monitoring could reject the availability 01:50:37 ... There was a change to requiring a user gesture. In general we want the user to be aware of presentation requests and the browsing context 01:50:39 kiyoshi_ has joined #webscreens 01:51:01 ... We renamed the join method to reconnect, for joining existing sessions 01:51:56 ... There are two cases for joining: between tabs in the same browser, and joining the browser to another screen, so the name 'join' wasn't clear 01:52:30 ... Previously there was a 'close' method, responsible for closing an individual connection to a presentation, and closing an entire presentation 01:53:17 ... We decided to add a terminate method, and a terminated state, allows the closing and termination cases to be distinguished 01:54:09 ... We renamed some things to clarify 01:54:58 ... As a browser maker, you implement the controlling side, the receiving side, or both, so we added some clarification around this 01:55:24 ... There aren't many new features, aside from terminate and PresentationAvailability 01:55:45 Anssi: That's a good overview 01:56:54 jcdufourd has joined #webscreens 02:01:08 jcdufour_ has joined #webscreens 02:07:34 rrsagent, draft minutes 02:07:34 I have made the request to generate http://www.w3.org/2015/10/28-webscreens-minutes.html tomoyuki 02:10:01 a12u has joined #webscreens 02:12:40 mfoltzgoogle has joined #webscreens 02:14:21 Topic: Define behavior of Window and Fullscreen APIs in the presentation browsing context (#99) 02:14:35 takeshi has joined #webscreens 02:15:22 tomoyuki_ has joined #webscreens 02:17:57 scribe: tidoust 02:18:18 TaejeoungKim has joined #webscreens 02:18:21 -> https://github.com/w3c/presentation-api/issues/99 Issue #99 02:19:18 Mark: We believe that the initial use case is for displaying content on a screen that may not have input capabilities or window systems. There certainly may be cases where that is not true, so we should be careful about restricting too much. 02:19:42 ... But we also do not want developers to believe that they can create presentations that use these features are not a problem. 02:19:57 s/ are not a problem/ 02:20:12 Anssi: What currently happens when these features are used (alert, confirm, etc.)? 02:20:48 Mark: I think it's reasonable to have these features be no-ops. 02:21:04 ... Another feature would be permission-enabling APIs. 02:21:40 ... There might be a way to modify the behavior of the Permission API to have it deny permission per default. 02:21:58 Anssi: Either that or some error code that says that "I'm in a presentation mode" or something similar. 02:22:33 Mark: Then APIs that create new browsing contexts (open, createPopup) are tough to implement, especially in the 1-UA case. 02:22:49 ... Sticking to one viewport makes it much easier. 02:23:31 ... Finally, APIs that try to move the window around (moveTo, moveBy) 02:23:45 Francois: How is that done on mobile devices where this is not possible either? 02:24:12 Mark: Right, I don't know. 02:24:40 Anssi: True, we may not have to do anything for these ones. We should have a look at the spec to see how implementations conform to it. 02:25:16 Mark: I think having the spec function like a mobile-like environment seems a good approach. 02:25:26 Anssi: I don't think there's any special case for mobile. 02:25:43 ... I think we can learn from HTML5 how these things are specified and reuse that. 02:26:00 Mark: OK. Final issue is how does the presentation interact with the Fullscreen API? 02:26:26 ... It's very likely that things will be presented in fullscreen. But it's also possible that presentations may not be fullscreens at all. 02:26:38 ... I don't have a strong opinion on it, but we need to address that. 02:27:40 jun has joined #webscreens 02:28:25 Anssi: Windows 8.1 and 10 have this split window mode 02:28:48 Francois: I don't think MS Edge supports Fullscreen right now, so we won't be able to experiment here. 02:28:59 Mark: Do you know if the content is aware that is runs Fullscreen? 02:29:51 Francois: Fullscreen API is not developed in W3C anymore. Back to WHATWG. I think there are CSS properties defined that let you style the content differently when it runs in fullscreen. Don't know if it's implemented. 02:30:23 Mark: Do we want to require that presented document be set with a media type of TV or projector? 02:30:27 Anssi: That could make sense. 02:33:54 Francois: I think that using a specific CSS Media Type would not be considered to be such a good idea. Media types such as "tv" or "handheld" are no longer fancy or supported, basically. 02:34:06 ... CSS media queries are more indicated. 02:34:44 Anssi: It sounds that we might benefit from the :fullscreen pseudo-class as in the Fullscreen API, or perhaps our own pseudo-class. 02:34:50 karl has joined #webscreens 02:34:56 http://caniuse.com/#feat=fullscreen 02:35:08 [Partial support refers to not supporting ::backdrop, and supporting the old :full-screen syntax rather than the standard :fullscreen.] 02:36:14 Anssi: I also note the pushback we received to reuse allowfullscreen for nested iframes. 02:36:49 ... so perhaps defining our own pseudo-class would be useful. 02:37:03 ... Not an expert though, no strong opinion. 02:37:10 Mark: Not an expert as well. 02:37:26 Anssi: Maybe we should loop in Anne who edits the Fullscreen API. 02:37:40 Louay: In our case, the presentation may not always be fullscreen. 02:38:36 ... Page could become presentation at any time 02:38:42 Francois: That's a good argument not to reuse :fullscreen pseudo-class but rather to define a new one. 02:39:52 Anssi: Good point. Confusing to call this fullscreen when it may not be. 02:40:28 a12u has joined #webscreens 02:40:39 Louay: Also, on the APIs themselves, in our case, the receiving side is a regular window, so APIs could be used. 02:41:52 Mark: Maybe there is a way to amend the spec to say that if the receiver does not support user input, then we specify the behavior, otherwise we leave that up to the user agent. 02:42:28 ... The final point is that for Web signage or private browsing, we may want to specify things more precisely. 02:42:31 ... Maybe longer term. 02:42:50 Anssi: Do you think that this would be its own section? 02:42:56 Mark: I think so, yes. 02:43:06 ... Requirements for the receiving user agent. 02:43:20 Anssi: That sounds good. I can also help with that text. 02:43:29 ... Louay, you probably want to work with Mark on this one. 02:44:34 Louay: Yes. 02:45:52 [side discussion on the Permission API] 02:47:36 PROPOSED RESOLUTION: For issue #99, add a section to the spec that defines the behaviour of these APIs in the presenting context, do not reuse the :fullscreen pseudo-class, and investigate a possible :presentation pseudo-class (discussing with CSS people) 02:48:20 [No objection heard] 02:48:28 RESOLUTION: For issue #99, add a section to the spec that defines the behaviour of these APIs in the presenting context, do not reuse the :fullscreen pseudo-class, and investigate a possible :presentation pseudo-class (discussing with CSS people) 02:48:44 jun has joined #webscreens 02:49:18 Ed: Sorry to be late to the discussion, why aren't we reusing the Fullscreen API? 02:49:45 Anssi: It would be confusing to reuse :fullscreen because you may not always be fullscreen. 02:50:24 Ed: I think the :fullscreen pseudo-class is intended to cover both cases, the fullscreen one and the lightbox one. 02:50:50 Anssi: Can you take an action to investigate that? Any reason why the CSS WG has not picked up on that? 02:50:58 Ed: The reason is not technical. 02:51:12 s/RESOLUTION: For issue #99, add a section to the spec that defines the behaviour of these APIs in the presenting context, do not reuse the :fullscreen pseudo-class, and investigate a possible :presentation pseudo-class (discussing with CSS people)// 02:51:28 Anssi: So we should amend the proposed resolution, then. 02:51:52 Ed: I think what you want to look at, is the top layer definition. 02:52:00 https://fullscreen.spec.whatwg.org/#new-stacking-layer 02:53:16 PROPOSED RESOLUTION: For issue #99, add a section to the spec that defines the behaviour of these APIs in the presenting context, investigate possible reuse of :fullscreen pseudo-class (discussing with CSS people) 02:54:08 RESOLUTION: For issue #99, add a section to the spec that defines the behaviour of these APIs in the presenting context, investigate possible reuse of :fullscreen pseudo-class (discussing with CSS people) 02:55:29 [Lunch break] 02:55:30 RRSAgent, draft minutes 02:55:30 I have made the request to generate http://www.w3.org/2015/10/28-webscreens-minutes.html tidoust 03:08:12 karl has joined #webscreens 03:22:06 tidoust has joined #webscreens 03:34:27 takeshi has joined #webscreens 03:37:09 Zakim has left #webscreens 03:54:48 jun has joined #webscreens 03:55:14 tomoyuki has joined #webscreens 03:59:06 mfoltzgoogle has joined #webscreens 03:59:35 Tomoyuki_ has joined #webscreens 03:59:38 Tomoyuki_ has left #webscreens 04:00:43 tomoyuki has joined #webscreens 04:04:42 TaejeoungKim has joined #webscreens 04:06:38 akitsugu has joined #webscreens 04:07:02 jinwoo_mbp has joined #webscreens 04:07:51 tidoust has joined #webscreens 04:08:42 oonishi has joined #webscreens 04:09:21 Louay_ has joined #webscreens 04:10:29 a12u has joined #webscreens 04:10:48 a12u has joined #webscreens 04:11:18 Topic: Presentations from within nested browsing contexts (#79) 04:11:24 jun has joined #webscreens 04:11:25 jcdufourd has joined #webscreens 04:11:35 Present+ Jean-Claude_Dufourd 04:12:16 cpn has joined #webscreens 04:15:16 fwtnb_ has joined #webscreens 04:18:16 markw has joined #webscreens 04:18:33 present+ markw 04:20:06 mdadas has joined #webscreens 04:20:38 Anssi: Next issue => https://github.com/w3c/presentation-api/issues/79 04:21:05 ...Presentations from nested browsing contexts 04:21:49 Anssi: Presentations within nested contexts are not special cased in the spec. 04:22:15 ...There are attacks where origins you don't like might try to start a presentation. 04:22:25 i/Anssi:/scribe: mfoltzgoogle/ 04:23:07 ...Solutions to mitigate: Fullscreen API defines an attribute, "allowfullscreen", on the ] 04:34:05 Jean-Claude: Main page. In an