Re: [whatwg] Fullscreen Update
On Sat, 29 Oct 2011, Robert O'Callahan wrote: On Wed, Oct 19, 2011 at 11:57 PM, James Graham jgra...@opera.com wrote: On 10/19/2011 06:40 AM, Anne van Kesteren wrote: Is that an acceptable limitation? Alternatively we could postpone the nested fullscreen scenario for now (i.e. make requestFullscreen fail if already fullscreen). I think punting on this makes sense. Pages can detect the failure and do something sane (make the element take the whole viewport size). If the feature becomes necessary we can add it in v2. I don't think punting on nested fullscreen is a good idea. It's not some edge case that most applications can't hit. For example, it will come up with any content that can go full-screen and can contain an embedded Youtube video. (It'll come up even more often if browser fullscreen UI is integrated with DOM fullscreen, which we definitely plan to do in Firefox.) If we don't support nested fullscreen well, then the user experience will be either -- making the video fullscreen while the containing content is already fullscreen simply doesn't work, or -- the video can go fullscreen, but when you exit fullscreen on the video, the containing content also loses fullscreen Both of these are clearly broken IMHO. Presumably the embeded video could detect that it was already in a fullscreen environment and deal with it accordingly. So in theory we could wait and see if people just do that before deciding that we have to implement the more complex thing. But that might be unnecessarily difficult and easy to get wrong. So maybe we should just deal with this now.
Re: [whatwg] Fullscreen Update
On Mon, Oct 31, 2011 at 2:52 PM, James Graham jgra...@opera.com wrote: Presumably the embeded video could detect that it was already in a fullscreen environment and deal with it accordingly. If you exit fullscreen so you can fullscreen the video, you won't be able to restore the original fullscreen element when you're done if the original element is in a different origin, right? This doesn't seem like something that you can deal with manually. -- Glenn Maynard
Re: [whatwg] Fullscreen Update
On Tue, Nov 1, 2011 at 7:52 AM, James Graham jgra...@opera.com wrote: On Sat, 29 Oct 2011, Robert O'Callahan wrote: I don't think punting on nested fullscreen is a good idea. It's not some edge case that most applications can't hit. For example, it will come up with any content that can go full-screen and can contain an embedded Youtube video. (It'll come up even more often if browser fullscreen UI is integrated with DOM fullscreen, which we definitely plan to do in Firefox.) If we don't support nested fullscreen well, then the user experience will be either -- making the video fullscreen while the containing content is already fullscreen simply doesn't work, or -- the video can go fullscreen, but when you exit fullscreen on the video, the containing content also loses fullscreen Both of these are clearly broken IMHO. Presumably the embeded video could detect that it was already in a fullscreen environment and deal with it accordingly. So in theory we could wait and see if people just do that before deciding that we have to implement the more complex thing. But that might be unnecessarily difficult and easy to get wrong. So maybe we should just deal with this now. As Glenn said, if you're in a cross-origin IFRAME I don't think you can deal with it (unless you establish a postMessage protocol to work with your container to deal with it). Even if you could, I think telling authors to use a pile of boilerplate code to make fullscreen work reliably would indicate a deficiency in the API if there's a reasonable alternative API that avoids the problem. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Fullscreen Update
On Sat, Oct 29, 2011 at 10:47 PM, Robert O'Callahan rob...@ocallahan.orgwrote: I don't think punting on nested fullscreen is a good idea. It's not some edge case that most applications can't hit. For example, it will come up with any content that can go full-screen and can contain an embedded Youtube video. (It'll come up even more often if browser fullscreen UI is integrated with DOM fullscreen, which we definitely plan to do in Firefox.) If we don't support nested fullscreen well, then the user experience will be either -- making the video fullscreen while the containing content is already fullscreen simply doesn't work, or -- the video can go fullscreen, but when you exit fullscreen on the video, the containing content also loses fullscreen Let me just clarify one thing. A browser's built-in get out of full-screen user gesture will probably need to break out of all nested fullscreen requests for security reasons. However, in-page UI to exit full-screen (such as a button in pop-up video controls) should still be able to return to the previous full-screen presentation. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Fullscreen Update
On Wed, Oct 19, 2011 at 11:57 PM, James Graham jgra...@opera.com wrote: On 10/19/2011 06:40 AM, Anne van Kesteren wrote: Is that an acceptable limitation? Alternatively we could postpone the nested fullscreen scenario for now (i.e. make requestFullscreen fail if already fullscreen). I think punting on this makes sense. Pages can detect the failure and do something sane (make the element take the whole viewport size). If the feature becomes necessary we can add it in v2. I don't think punting on nested fullscreen is a good idea. It's not some edge case that most applications can't hit. For example, it will come up with any content that can go full-screen and can contain an embedded Youtube video. (It'll come up even more often if browser fullscreen UI is integrated with DOM fullscreen, which we definitely plan to do in Firefox.) If we don't support nested fullscreen well, then the user experience will be either -- making the video fullscreen while the containing content is already fullscreen simply doesn't work, or -- the video can go fullscreen, but when you exit fullscreen on the video, the containing content also loses fullscreen Both of these are clearly broken IMHO. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Fullscreen Update
2011-10-19 17:45 EEST: Glenn Maynard: b.onclick = function(e) { if(document.fullscreen) document.exitFullscreen(); else gameDiv.enterFullScreen(); } In fact, the most obvious code should be b.onclick = function(e) { if(gameDiv.fullscreen) gameDiv.exitFullscreen(); else gameDiv.enterFullScreen(); } If F11-fullscreen sets document.fullscreen, this breaks; enterFullScreen would never be called. Yes. If the web developer is going to fullscreen a single element, he should test if that element is fullscreen instead of testing if the whole document is fullscreen, IMHO. -- Mikko
Re: [whatwg] Fullscreen Update
On Tue, Oct 18, 2011 at 9:40 PM, Anne van Kesteren ann...@opera.com wrote: 1) How much should UI-based and API-based fullscreen interact? To me it seems nice if pressing F11 would also give you fullscreenchange events and that Document.fullscreen would yield true. Why would you not want to give the same presentation via native activation and API-based activation? Of course when you activate it UI-wise, navigation should not exit it. For native video controls the case seems clearer that they should work using this API. Agreed. What should the target be for the fullscreenchange events in the native activation case? Should it be the documentElement or perhaps the window? Since the fullscreen attribute exists on Document instead of Window, it seems like it might be odd to dispatch the fullscreenchange event to the window. However, in the native activation case, you could really argue that it is the window that is being presented fullscreen and not the document since fullscreen survives navigation. 2) Chris brought forward the case of nesting. You have a fullscreen presentation (lets assume API-based activated for now) and in that presentation there's some video that the presenter wants to display fullscreen (lets assume the video player is a custom widget with API-based fullscreen activation for now). Once the presenter exits displaying the video fullscreen, the presentation should still be fullscreen. Initially this was brought up with the video being hosted in a separate descendant document, but the video could be in the same document as well. roc suggested a model that works when you have separate documents and it could be made to work for the single document case too, as long as the level of nesting remains is no larger than required for the presentation scenario mentioned above. Is that an acceptable limitation? Alternatively we could postpone the nested fullscreen scenario for now (i.e. make requestFullscreen fail if already fullscreen). +1 for punting on the nested case. -Darin
Re: [whatwg] Fullscreen Update
2) Chris brought forward the case of nesting. You have a fullscreen presentation (lets assume API-based activated for now) and in that presentation there's some video that the presenter wants to display fullscreen (lets assume the video player is a custom widget with API-based fullscreen activation for now). Once the presenter exits displaying the video fullscreen, the presentation should still be fullscreen. Initially this was brought up with the video being hosted in a separate descendant document, but the video could be in the same document as well. roc suggested a model that works when you have separate documents and it could be made to work for the single document case too, as long as the level of nesting remains is no larger than required for the presentation scenario mentioned above. Is that an acceptable limitation? Alternatively we could postpone the nested fullscreen scenario for now (i.e. make requestFullscreen fail if already fullscreen). +1 for punting on the nested case. I think you'd ever only want to have one thing fullscreen at a time. Thus, if you go from a fullscreen to another, the previous one should naturally leave fullscreen. I think that's how presentation functionality works on ppt and similar tools, too. Silvia. I can see the use case when Document is fullscreen, and then an element is fullscreened. So if another element goes fullscreen it replaces the previous, if any, but the document keeps its state. Another alternative would be to have a stack, but I think that's overkill.
Re: [whatwg] Fullscreen Update
On 10/19/2011 06:40 AM, Anne van Kesteren wrote: Is that an acceptable limitation? Alternatively we could postpone the nested fullscreen scenario for now (i.e. make requestFullscreen fail if already fullscreen). I think punting on this makes sense. Pages can detect the failure and do something sane (make the element take the whole viewport size). If the feature becomes necessary we can add it in v2.
Re: [whatwg] Fullscreen Update
On Wed, Oct 19, 2011 at 12:40 AM, Anne van Kesteren ann...@opera.comwrote: 1) How much should UI-based and API-based fullscreen interact? To me it seems nice if pressing F11 would also give you fullscreenchange events and that Document.fullscreen would yield true. Why would you not want to give the same presentation via native activation and API-based activation? Of course when you activate it UI-wise, navigation should not exit it. The most obvious way to write a fullscreen button is: b.onclick = function(e) { if(document.fullscreen) document.exitFullscreen(); else gameDiv.enterFullScreen(); } If F11-fullscreen sets document.fullscreen, this breaks; enterFullScreen would never be called. This could be dealt with, of course (check document.fullscreenElement == gameDiv instead), but it's a corner case that people aren't going to test. For native video controls the case seems clearer that they should work using this API. Definitely agree with native video controls. Is that an acceptable limitation? Alternatively we could postpone the nested fullscreen scenario for now (i.e. make requestFullscreen fail if already fullscreen). Pages could still implement nesting themselves. It'd take more work and cooperation between elements, and wouldn't work with native video controls, but for a site complex enough to need it that seems acceptable. However, enterFullscreen shouldn't fail when already in fullscreen. You should be able to change the fullscreenElement without having to exit and reenter fullscreen. -- Glenn Maynard
Re: [whatwg] Fullscreen Update
On Wed, 19 Oct 2011 16:45:34 +0200, Glenn Maynard gl...@zewt.org wrote: On Wed, Oct 19, 2011 at 12:40 AM, Anne van Kesteren ann...@opera.comwrote: 1) How much should UI-based and API-based fullscreen interact? To me it seems nice if pressing F11 would also give you fullscreenchange events and that Document.fullscreen would yield true. Why would you not want to give the same presentation via native activation and API-based activation? Of course when you activate it UI-wise, navigation should not exit it. The most obvious way to write a fullscreen button is: b.onclick = function(e) { if(document.fullscreen) document.exitFullscreen(); else gameDiv.enterFullScreen(); } If F11-fullscreen sets document.fullscreen, this breaks; enterFullScreen would never be called. This could be dealt with, of course (check document.fullscreenElement == gameDiv instead), but it's a corner case that people aren't going to test. I think you just solved your own issue :) Your if check is wrong given your use case. Besides, if the developer failed to test, it would just require an extra click.
Re: [whatwg] Fullscreen Update
On Wed, Oct 19, 2011 at 11:00 AM, João Eiras jo...@opera.com wrote: I think you just solved your own issue :) Your if check is wrong given your use case. No, that's missing the point. These obscure corner cases should be minimized (in any API, and especially web APIs). People won't know to test them, and everyone's browsing experience will be buggier when in F11-fullscreen. Can anyone suggest a use case for having fullscreen be true when in browser (F11) fullscreen? I can't think of any. Besides, if the developer failed to test, it would just require an extra click. It wouldn't work at all. The exitFullscreen call would fail or no-op (you can't exit F11 fullscreen with this API, of course; it's not yours to exit), so the next click would just call exitFullscreen again. -- Glenn Maynard
Re: [whatwg] Fullscreen Update
On Wed, 19 Oct 2011 17:31:40 +0200, Glenn Maynard gl...@zewt.org wrote: On Wed, Oct 19, 2011 at 11:00 AM, João Eiras jo...@opera.com wrote: I think you just solved your own issue :) Your if check is wrong given your use case. No, that's missing the point. These obscure corner cases should be minimized (in any API, and especially web APIs). People won't know to test them, and everyone's browsing experience will be buggier when in F11-fullscreen. Can anyone suggest a use case for having fullscreen be true when in browser (F11) fullscreen? I can't think of any. Besides, if the developer failed to test, it would just require an extra click. It wouldn't work at all. The exitFullscreen call would fail or no-op (you can't exit F11 fullscreen with this API, of course; it's not yours to exit), so the next click would just call exitFullscreen again. F11 and document.requestFullscreen() should produce exactly the same results, so, document.fullscreen would be enabled. And there's no reason not to (and otherwise would make the spec needlessly more complex).
Re: [whatwg] Fullscreen Update
On Wed, Oct 19, 2011 at 11:49 AM, João Eiras jo...@opera.com wrote: F11 and document.requestFullscreen() should produce exactly the same results, so, document.fullscreen would be enabled. And there's no reason not to (and otherwise would make the spec needlessly more complex). There's no such thing as document.requestFullscreen() in the current draft. (It was suggested in passing on IRC, but it hasn't been discussed here.) There's definitely a reason that the fullscreen API can't act like F11-fullscreen. F11 causes the whole browser window to be fullscreened, affecting all tabs in the window. If you change tabs or create a new tab, the browser window stays fullscreened. It isn't exited on navigation. Pages should no more be able to affect F11-fullscreen than they can resize the browser window. It's a completely separate fullscreen model from this API. This spec doesn't need to talk about it at all. -- Glenn Maynard
Re: [whatwg] Fullscreen Update
On Wed, 19 Oct 2011 17:15:11 +0100, Glenn Maynard gl...@zewt.org wrote: On Wed, Oct 19, 2011 at 11:49 AM, João Eiras jo...@opera.com wrote: F11 and document.requestFullscreen() should produce exactly the same results, so, document.fullscreen would be enabled. And there's no reason not to (and otherwise would make the spec needlessly more complex). There's no such thing as document.requestFullscreen() in the current draft. (It was suggested in passing on IRC, but it hasn't been discussed here.) There's definitely a reason that the fullscreen API can't act like F11-fullscreen. F11 causes the whole browser window to be fullscreened, affecting all tabs in the window. If you change tabs or create a new tab, the browser window stays fullscreened. It isn't exited on navigation. Pages should no more be able to affect F11-fullscreen than they can resize the browser window. I don't understand how that is an issue. It has been mentioned that navigating a document which has a fullscreen element would exit fullscreen, but not a document. Indeed the spec lacks document.requestFullscreen. It should be there for the traditional fullscreen without browser chrome, just like F11. Or instead, mention that calling requestFullscreen on the root would have the same effect. I'd rather have it directly on Document though.
Re: [whatwg] Fullscreen Update
On Wed, Oct 19, 2011 at 5:21 PM, João Eiras jo...@opera.com wrote: I don't understand how that is an issue. It has been mentioned that navigating a document which has a fullscreen element would exit fullscreen, but not a document. If you're saying that fullscreen won't be exited on navigation when document.fullscreenElement == document.documentElement, then that sounds wrong to me. Script-initiated fullscreen should always exit on navigation, and it should never affect tabs other than itself. (Otherwise, I don't understand what you mean.) Indeed the spec lacks document.requestFullscreen. It should be there for the traditional fullscreen without browser chrome, just like F11. Or instead, mention that calling requestFullscreen on the root would have the same effect. I'd rather have it directly on Document though. Requesting fullscreen on the root would do something very different than what F11 does. Having a convenience wrapper that's simply a shortcut for document.documentElement.requestFullscreen(); is harmless (though unnecessary API bloat, in my opinion), but it's not an interface to F11 fullscreen at all. F11 fullscreen is a window-level property, not a tab property, similar to maximizing or resizing the window. Scripts shouldn't have control over that, and I can't think of any reason they'd want to. On Wed, Oct 19, 2011 at 7:26 PM, Jeremy Apthorp jere...@chromium.orgwrote: No browser UI should be shown except the permission dialog. Other than UI that normally appears on top of the page, of course (alerts, context menus, file pickers). -- Glenn Maynard
Re: [whatwg] Fullscreen Update
On 19/10/2011 5:40 p.m., Anne van Kesteren wrote: 1) How much should UI-based and API-based fullscreen interact? To me it seems nice if pressing F11 would also give you fullscreenchange events and that Document.fullscreen would yield true. These modes cover different cases. F11 fullscreen mode is when the user wants to hide their browser user interface, but otherwise doesn't want to affect presentation. Whereas the fullscreen API is to allow sites to make a specific element the fullscreen element. 2) Chris brought forward the case of nesting. You have a fullscreen presentation (lets assume API-based activated for now) and in that presentation there's some video that the presenter wants to display fullscreen (lets assume the video player is a custom widget with API-based fullscreen activation for now). Once the presenter exits displaying the video fullscreen, the presentation should still be fullscreen. Initially this was brought up with the video being hosted in a separate descendant document, but the video could be in the same document as well. In this presentation-video case, if the video is in the same document or in a same-origin subdocument, the page can script switching full-screen between the main full-screen element and the video element and vice versa (provided Element.requestFullScreen() while in fullscreen switches the fullscreen element). So custom controls on the video element could be implemented to solve this problem in the single document and in the non-cross origin multi-document case. In the cross origin multi-document case, if document.exitFullScreen() causes all documents to exit full-screen (not just the target document and its descendents) it would also be pretty easy for the parent document to listen for the fullscreenchange event when the video exited, the and show its button for the main document to re-enter fullscreen. It would be a 2-click process to fullscreen change from the video back to the main document, but no big drama really. roc suggested a model that works when you have separate documents and it could be made to work for the single document case too, as long as the level of nesting remains is no larger than required for the presentation scenario mentioned above. We could go with Roc's suggestion and provided requestFullScreen() switches fullscreen mode we'd be ok, but I think that would complicate the API a bit much. Seems better to keep it simple. Is that an acceptable limitation? Alternatively we could postpone the nested fullscreen scenario for now (i.e. make requestFullscreen fail if already fullscreen). I think we should: 1. Make Element.requestFullScreen() switch the fullscreen element (so we can handle the single document and same-origin documents cases) when called while any document is in fullscreen mode, and 2. make document.exitFullScreen() exit all documents from fullscreen. It keeps the API simple, and provided we fire fullscreenchange events whenever a documents fullscreen attribute changes, pages can detect this and provide buttons to restore the user to their desired fullscreen state. Chris Pearce.
Re: [whatwg] Fullscreen Update
On Thu, 20 Oct 2011 10:20:57 +0900, Chris Pearce cpea...@mozilla.com wrote: On 19/10/2011 5:40 p.m., Anne van Kesteren wrote: 1) How much should UI-based and API-based fullscreen interact? To me it seems nice if pressing F11 would also give you fullscreenchange events and that Document.fullscreen would yield true. These modes cover different cases. F11 fullscreen mode is when the user wants to hide their browser user interface, but otherwise doesn't want to affect presentation. Whereas the fullscreen API is to allow sites to make a specific element the fullscreen element. Except that the root element is special cased and will — as far as the end user is concerned — give the exact same visual effect as F11 fullscreen. So what you are saying is not true, unless we remove the special case for the root element, which might be a good idea. In this presentation-video case, if the video is in the same document or in a same-origin subdocument, the page can script switching full-screen between the main full-screen element and the video element and vice versa (provided Element.requestFullScreen() while in fullscreen switches the fullscreen element). So custom controls on the video element could be implemented to solve this problem in the single document and in the non-cross origin multi-document case. That sounds like a pretty bad solution to me. It also fails for encapsulated cross-origin bindings (which are somewhat likely to arrive to the platform in due course). In the cross origin multi-document case, if document.exitFullScreen() causes all documents to exit full-screen (not just the target document and its descendents) it would also be pretty easy for the parent document to listen for the fullscreenchange event when the video exited, the and show its button for the main document to re-enter fullscreen. It would be a 2-click process to fullscreen change from the video back to the main document, but no big drama really. It does not sound that great to me. Maybe the presentation case would instead be solved by just letting the page enlarge the video itself. roc suggested a model that works when you have separate documents and it could be made to work for the single document case too, as long as the level of nesting remains is no larger than required for the presentation scenario mentioned above. We could go with Roc's suggestion and provided requestFullScreen() switches fullscreen mode we'd be ok, but I think that would complicate the API a bit much. Seems better to keep it simple. I think keeping it simple argues for the following: * Only allow a single element to go fullscreen * If an element is already fullscreen dispatch fullscreenerror * Not special case the root element Is that an acceptable limitation? Alternatively we could postpone the nested fullscreen scenario for now (i.e. make requestFullscreen fail if already fullscreen). I think we should: 1. Make Element.requestFullScreen() switch the fullscreen element (so we can handle the single document and same-origin documents cases) when called while any document is in fullscreen mode, and 2. make document.exitFullScreen() exit all documents from fullscreen. It keeps the API simple, and provided we fire fullscreenchange events whenever a documents fullscreen attribute changes, pages can detect this and provide buttons to restore the user to their desired fullscreen state. I think I agree more with Darin Fisher and James Graham. -- Anne van Kesteren http://annevankesteren.nl/