[whatwg] Fullscreen feedback
Ian Hickson
ian at hixie.ch
Wed Dec 8 17:43:24 PST 2010
(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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list