- From: Chris Pearce <cpearce@mozilla.com>
- Date: Tue, 18 Oct 2011 14:00:51 +1300
On 18/10/2011 12:52 p.m., Darin Fisher wrote: > On Mon, Oct 17, 2011 at 4:17 PM, Anne van Kesteren<annevk at opera.com> wrote: > >> On Tue, 18 Oct 2011 07:55:33 +0900, Darin Fisher<darin at chromium.org> >> wrote: >> >>> Thanks for working on this spec! I have more questions, but I'll just >>> start with one. If enterFullscreen() is called when the browsing context is >>> already being displayed fullscreen, what should happen? (It looks like >>> Safari 5.1 ignores the second call to webkitRequestFullScreen.) >>> >> Chris is suggesting this should move the "current fullscreen element" >> around. A use case I can think of is where you have YouTube fullscreen while >> browsing through videos and then want to highlight a particular video. It >> does however generate quite a bit of complexity in edge cases where you have >> a tree of Documents. In that case you need to find the common ancestor of >> the current fullscreen element and the new fullscreen element, make changes >> to the Documents on that path from current to new, and dispatch events. > > This seems like it might be overly complicated. I could be mistaken, but I > don't think YouTube needs this. > Yeah, I suggest that if requestFullScreen() is called when another element is already the fullscreen element, the new requestee should become the fullscreen element. A use case for this is: a fullscreen page with a cross-domain <video> and the <video> wants to go fullscreen. For example if a slide-deck/PowerPoint clone webapp goes fullscreen and wants to make an embedded YouTube video fullscreen. The easiest way to do this is load the YouTube video in an embedded iframe and (assuming you're using their HTML5 player and that uses the fullscreen API) click on the fullscreen button in its controls UI. Regards, Chris Pearce.
Received on Monday, 17 October 2011 18:00:51 UTC