On Sun, Aug 22, 2010 at 10:11 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Mon, Aug 23, 2010 at 5:03 PM, Adam Barth <w...@adambarth.com> wrote: >> On Sun, Aug 22, 2010 at 9:56 PM, Robert O'Callahan <rob...@ocallahan.org> >> wrote: >> > On Mon, Aug 23, 2010 at 4:42 PM, Adam Barth <w...@adambarth.com> 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. >> > >> > 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. >> >> But it doesn't go full screen, right? Didn't you say above that the >> location bar is still there? > > 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.
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. 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. Adam
