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

Re: [presentation-api] Presentations from within nested browsing contexts

From: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Wed, 03 Jun 2015 18:45:35 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-108570968-1433357134-sysbot+gh@w3.org>
Unfortunately I have to object to this resolution as stated after 
further internal discussions within Google.   Whitelisting the 
Presentation API to `<iframe>` elements with a new attribute will 
effectively make the API inaccessible to a large portion of 
presentable content embedded within existing Web content.  In many 
cases the existing markup won't be upgraded by the author, because the
 embedding is done on her behalf by authoring tools, or they have lost
 access, or don't want to bother.

As a concrete example, consider the millions of YouTube videos 
embedded in blog posts.  They use markup like the following:

<iframe title="YouTube video player" class="youtube-player" 
type="text/html" width="700"
    height="427" src="//www.youtube.com/embed/LzTM-iGs71U?..."
    frameborder="0" allowfullscreen=""></iframe>

(I've shortened the `src` for readability).  These can be remoted 
today using Cast, and would not be able to remoted via Presentation 
API unless the blog template is modified, or the author manually edits
 the markup to add `allowpresentation` alongside `allowfullscreen`.

I checked two other popular video sharing sites - dailymotion.com and 
vimeo.com - and they will have the same issue as they provide 
`<iframe>` embedding code that is copy-pasted by the Web author.

I propose keeping this open and soliciting further proposals that 
allow existing embedded content to be presented, but perhaps limit 
access to some functionality, like receiving browser initiated 
presentation events.

GitHub Notif of comment by mfoltzgoogle
Received on Wednesday, 3 June 2015 18:45:37 UTC

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