- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Jul 2015 15:32:09 +0000
- To: public-secondscreen@w3.org
Hi @avayvod > There's no information for the tab to provide to the user agent and nothing to control except for stopping the mirroring. So this could already be implemented by the user agent without any API. The communication channel would not mean anything in that case, indeed. > Do you think there's a use case for the tab to initiate mirroring rather than a presentation? Hmm. I think my reaction was more triggered by the lack of symmetry in your proposal than by a specific use case: when the user presses the "present" button in the UA chrome, it will mirror the tab by default, or present a URL, whereas when the user presses a "present" button in the page, it can only present a URL. While preparing the charter of the group, I remember a few exchanges with people who were surprised that content mirroring was not in scope. It seems that many people think about content mirroring first when they think about projecting content onto a second screen (and are also sure that it is way easier to achieve than presenting different content but that's another story). That is all very subjective and does not really create a use case that would require that feature to be exposed at the API level (well, and it's out of scope for the group as just alluded to). -- GitHub Notif of comment by tidoust See https://github.com/w3c/presentation-api/issues/26#issuecomment-118069612
Received on Thursday, 2 July 2015 15:32:10 UTC