- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 9 Dec 2010 01:43:24 +0000 (UTC)
(This e-mail only contains responses to the one brief part of the full- screen API feedback that apply to the spec(s) I'm working on; I believe Anne has stated an intent to specify an API for actually supporting fullscreen display of Web content and I have not responded to feedback that would be appropriate for that spec. In case it is helpful to Anne, I've included below the feedback to which I did not include responses.) On Fri, 20 Aug 2010, Mike Wilcox wrote: > On Aug 20, 2010, at 3:24 PM, Ian Hickson wrote: > > By CSSOM, I mean a separate specification, specifically one from the > > family of specifications that Anne is working on ...though my > > understanding is that Anne doesn't have the bandwidth to take this on > > right now (this may be less of a problem if Robert's proposal can just > > be taken wholesale, though). > > RE: Fullscreen - I would be happy if the warning text was removed: User > agents should not provide a public API to cause videos to be shown > full-screen. It appears the warning is no longer present. Did I just miss it? The other feedback was as follows (trimmed to remove non-material feedback, process discussion, and redundant quoting): On Fri, 20 Aug 2010, Adam Barth wrote: > On Fri, Aug 20, 2010 at 7:25 PM, Robert O'Callahan > <robert at ocallahan.org> wrote: > > On Sat, Aug 21, 2010 at 8:24 AM, Ian Hickson <ian at hixie.ch> wrote: > >> One comment: Rather than adding an "allowfullscreen" attribute on > >> <iframe>, I would suggest just assuing that sandboxed content (i.e. > >> content of iframes with the sandbox="" attribute) can't go > >> fullscreen. I can provide a sandbox flag for this state. If we think > >> there are use cases for allowing sandboxed iframes to go fullscreen, > >> then I can also add a keyword that turns off the flag when present > >> (like "allow-scripts" does for scripts). (I'm assuming there are no > >> cases for disabling fullscreen for unsandboxed iframes; are there?) > > > > What about legacy content that doesn't use "sandbox"? It might expect > > cross-origin IFRAMEs to not be able to take over its window, but if > > the IFRAME content goes fullscreen, it effectively can. > > > > I think allowing subframes to go fullscreen should always be opt-in. > > How is going fullscreen different from opening a popup window? On Sat, 21 Aug 2010, Kit Grose wrote: > > It's the same document *in the same state* as it was in when you > triggered "fullscreen". You would expect fullscreen on a video or > animation not to start that video or animation from the beginning or > reload it. On Fri, 20 Aug 2010, Adam Barth wrote: > > I meant from a security model perspective. :) On Sat, 21 Aug 2010, Robert O'Callahan wrote: > > That depends on how the UA chooses to handle it. But this proposed > fullscreen API is based on the idea that the fullscreen content "takes > over" the toplevel browsing context to which it belongs. (The content is > styled to fill the IFRAME, and the IFRAME element is styled to fill the > parent document's viewport.) On Sun, 22 Aug 2010, Adam Barth wrote: > On Sun, Aug 22, 2010 at 8:00 PM, Robert O'Callahan <robert at ocallahan.org> wrote: > > On Sun, Aug 22, 2010 at 4:12 AM, Adam Barth <w3c at adambarth.com> wrote: > >> > >> That does seem dangerous if the location bar still displays the URL > >> of the top-level browsing context because it violates the constraint > >> principle of display delegation. > > > > That's why I want to default to prohibiting subframe content from > > going fullscreen. > > Yeah, I agree that we'd need something like that in this model. It's > unfortunate though. Won't folks package <video> widgets using iframes? > I guess they'll need to include this silly attribute in their > "copy-and-paste this markup" code in order for full screen to work. > > >> This doesn't seem like a good model for full-screen. ?I would think > >> the model of re-parenting the content to a popup window that fills > >> the entire screen would be a better model. > > > > I think that model is a lot harder to spec and a lot harder for Web > > authors to understand. I'd certainly be interested in looking at a > > proposal if someone wants to pursue that approach. > > There's been some work in WebKit around the concept of a "magic iframe" > that keeps it's environment intact even when it's adopted from one > document to another. I'm not sure how much of that has been discussed > for standardization, but you could imagine a model like that working > where a frame is adopted into a "popup" window that fills the screen. On Mon, 23 Aug 2010, Robert O'Callahan wrote: > > That's sorta-ok if your video is a subframe that you treat as a black > box. But if your video element is just an element in your page with > event handlers attached to it, and with various scripts that interact > with it, and you rip that element out (plus maybe some supporting > elements representing your player UI) and drop it in another document, > it seems to me you're going to have to code very carefully to ensure it > keeps working over there (and the original page doesn't get into a bad > state). If there's confirmation UI so that the movement between > documents happens asynchronously, it's even more exciting. Moving the > element back when the user exits fullscreen has similar issues. > > Maybe there are ways to make that model easy and convenient for authors. > I'd like to see a proposal. On Sun, 22 Aug 2010, Adam Barth wrote: > > Oh, I think the iframe-at-a-time is an easier model to work with since > the scripting context will get adopted into the full-screen view > together with the elements. On Mon, 23 Aug 2010, Robert O'Callahan wrote: > > It requires the author to put each part of their page that they want to > go fullscreen into its own subframe. That is cumbersome. With my > proposal, most existing pages and player UIs would work if you just call > "element.requestFullScreen()" in some event handler. On Sun, 22 Aug 2010, Adam Barth wrote: > > But it doesn't go full screen, right? Didn't you say above that the > location bar is still there? On Mon, 23 Aug 2010, Robert O'Callahan wrote: > > That depends on the UA. Assuming we implement this API using our > existing fullscreen functionality, in Firefox the element would be > fullscreen, but if the user moves the mouse to the very top of the > screen some browser chrome will pop down temporarily, including the URL > bar. On Sun, 22 Aug 2010, Adam Barth wrote: > > So... The trade-off is: > > 1) Only browsing contexts can go full-screen (since they have URLs that > we could display). > > 2) Any element can go full-screen, but we'll need to add a nasty > non-semantic attribute. On Mon, 23 Aug 2010, Robert O'Callahan wrote: > > Is "allowfullscreen" really less semantic than "sandbox"? > > Actually one option here is to only allow sandboxed iframes to go > fullscreen, deny fullscreen to sandboxed iframes by default, and provide > a sandbox token (e.g. "allow-fullscreen") that allows fullscreen. So you > could add sandbox="allow-scripts allow-fullscreen" to a video embedding > IFRAME. On Sun, 22 Aug 2010, Adam Barth wrote: > > Another idea is that we could let any element go full-screen, but then > we'd show the URL of its browsing context. There's some subtleties here > about overlays from parent frames, but those seem solvable. On Mon, 23 Aug 2010, Robert O'Callahan wrote: > > Doable, but maybe painful to implement, and there are numerous spec and > UI issues to do with navigation, history, etc. On Tue, 21 Sep 2010, Shiv Kumar wrote: > > Pardon me if I've missed something. The last time I found and read the > spec on this feature it said that UAs should not provide a script > interface to put the video element in full screen. > > Now in order for anyone to be able to provide their own skin/player, > we'll need to provide a scriptable way to switch the video element to > full screen and out including events to support the same. > > I know the Webkit folks have provided, > webkitEnterFullScreen/webkitExitFullScreen methods to allow this. I > don't believe there are any events supporting the change in state. > > I think it's important that the video element provide a scriptable way > to do this. Internally, the UA can determine if the call was made using > a user gesture as I believe Webkit is doing. On Wed, 22 Sep 2010, timeless wrote: > > it is not ok to allow content authors to refuse to deliver content > unless they are "full screen". > > having events which enable providers to hold users hostage is a bad > thing. > > if i have two screens today and try to watch a youtube video "full > screen" (with flash), it tries to unfullscreen when my focus shifts to > the other screen. > > this isn't proper. my system should not be held hostage to the whims of > providers.. On Wed, 22 Sep 2010, Nils Dagsson Moskopp wrote: > > With a platform like The Web, one should expect every feature provided > to be misused. On Wed, 22 Sep 2010, John Harding wrote: > > That's Flash's behavior, not YouTube's choice - we'd love to allow > fullscreen usage on one screen while focus is in another. This is the > right way to do it, though - content can* *request changes to the > fullscreen state, but the User Agent is ultimately responsible for > granting or denying that request, or even changing arbitrarily later on. On Wed, 22 Sep 2010, Alex Bishop wrote: > > There have been previous discussions about allowing scripts to request > that arbitrary content (including video elements) fill the full screen. > > Here's one proposal: > > https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI On Wed, 22 Sep 2010, Gregg Tavares (wrk) wrote: > > Is this proposal not good enough? > https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI > > It handles the case I think you want. I also it's also useful for other > things like HTML5 games. It's also secure or at least as secure as > flash. The browser will not go fullscreen without either a prompt or a > mouse click. On Thu, 23 Sep 2010, Mikko Rantalainen wrote: > > I think that the Gecko Fullscreen API proposal is pretty good. I'd only > change > void requestFullScreen(unsigned short flags) > to > void requestFullScreen(unsigned short flags, function callback) > > where callback function will be asynchronously called with true or false > once the UA has completed the request (true meaning the request was > accepted, false meaning that request was declined). In addition, the > proposal should probably suggest that request should be automatically > declined in case a new identical request is raised immediately after > declining previous request (denial of service attack). On Fri, 24 Sep 2010, Robert O'Callahan wrote: > > In fact, there has been a lot of clear feedback that an API that only > works on video elements is unlikely to get much use, since major video > sites very strongly prefer to use their own player UI in fullscreen > mode. And of course their own player UI consists of non-video > elements... -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 8 December 2010 17:43:24 UTC