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.
[whatwg] Fullscreen events
Hi. The spec tells that fullscreenchanged is dispatched for API initiated fullscreen. It should too specify that fullscreenchanged should be dispatched for fullscreen toggled by the user like pressing F11 ou double clicking a video element. Thanks.
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.
[whatwg] Remove reference to DOM Range
DOM Range has been folded into DOM4 so it should be removed as reference from HTML. At one place it is referenced as defining text selections. That is now done by the Editing specification. -- Anne van Kesteren http://annevankesteren.nl/
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/
