W3C home > Mailing lists > Public > public-secondscreen@w3.org > April 2015

Re: [presentation-api] Allow page to designate a default presentation URL

From: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Fri, 10 Apr 2015 22:20:16 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-91707351-1428704416-sysbot+gh@w3.org>
@avayvod  In Chrome have been discussing how browser-initiated 
presentation interacts with multiple <iframe>s embedded in the 
controlling page.  For now, we are only enabling browser-initiated 
presentation from the default presentation URL set in the top level 
document.  However, there is a use case for allowing it from an 
embedded <iframe> for sites using a third party player to show a 
single piece of video (or other) content.

We have discussed possible solutions, including:

1. Having the <iframe> pass a URL to the parent document to set as the
 default presentation URL.  The problem here is that the 
browser-initiated presentation session would go to the parent 
document, not the <iframe> that has the presentation control logic for
 the video player.

2. Picking an <iframe> DPU if none is set at in the parent.  This may 
lead to surprising behavior for the user, since the user is expecting 
to present content related to the parent document, which cannot 
directly control the behavior of the <iframe>.

3. Allowing the user to choose from a list of default presentation 
URLs in the document.  This complicates the UX for starting a 
presentation and it will be difficult for the user to make a 
meaningful choice (who provides the URL is an implementation detail of
 the webapp).

Instead we are considering adding a capability to the <iframe>'s 
sandbox attribute, "allow-default-presentation", that would allow the 
parent page to designate up to one iframe per document as the source 
of the default presentation URL for browser initiated presentation.  
This attribute would be respected only for <iframes> one level deep.

GitHub Notif of comment by mfoltzgoogle
Received on Friday, 10 April 2015 22:20:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:18:52 UTC