Re: [whatwg] Fullscreen API and out-of-process iframe
On Mon, Jul 28, 2014 at 8:16 PM, Adam Barth w...@adambarth.com wrote: I meant a black-box experiment (i.e., no access to browser internal state). Put another way, can you describe a sequence of events in which the author or the user could observe the difference? If not, then the question is moot. Well if both A and B invoke requestFullscreen() that's obviously for different elements. The observable difference would be which element ends up being fullscreen of course and which call would either fail or end up overwriting the other depending on how we decide to deal with this. -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
Either: 1) The frames attempt no synchronization and both just call requestFullscreen(). In that case, the observable difference is largely moot. It shouldn't be surprising that racing operations like this cross origin returns a non-deterministic result. This is the position the Chrome out-of-process team is taking for other sorts of actions that have effects visible outside the frame (for example, navigating the top level frame, multiple frames sending a postMessage to the same frame, etc). 2) One frame calls requestFullscreen() and then sends a postMessage() to another frame, which calls requestFullscreen() upon receiving the message. Going fullscreen requires coordination with the browser process, so ordering is preserved by browser IPC message handling. Daniel On Mon, Jul 28, 2014 at 11:56 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 28, 2014 at 8:16 PM, Adam Barth w...@adambarth.com wrote: I meant a black-box experiment (i.e., no access to browser internal state). Put another way, can you describe a sequence of events in which the author or the user could observe the difference? If not, then the question is moot. Well if both A and B invoke requestFullscreen() that's obviously for different elements. The observable difference would be which element ends up being fullscreen of course and which call would either fail or end up overwriting the other depending on how we decide to deal with this. -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng dch...@google.com wrote: 1) The frames attempt no synchronization and both just call requestFullscreen(). In that case, the observable difference is largely moot. It shouldn't be surprising that racing operations like this cross origin returns a non-deterministic result. This is the position the Chrome out-of-process team is taking for other sorts of actions that have effects visible outside the frame (for example, navigating the top level frame, multiple frames sending a postMessage to the same frame, etc). 2) One frame calls requestFullscreen() and then sends a postMessage() to another frame, which calls requestFullscreen() upon receiving the message. Going fullscreen requires coordination with the browser process, so ordering is preserved by browser IPC message handling. So I tried to figure out how one would implement this in JavaScript as an exercise. You'd have a privileged asynchronous API that resizes the top-level browsing context's document's viewport. It calls a callback once that's done, presumably synchronized with animation frames. Now at that point you need to get hold of all your ancestor documents and start changing state outward-in. Some of these ancestor documents you can get a hold of synchronously, but not all. What if there's a cross-origin document inbetween? Now what I'm afraid of is that one of these ancestors or perhaps a descendant is also playing with requestFullscreen() and since the changing of state does not happen globally you end up with inconsistent state. -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
On Tue, Jul 29, 2014 at 5:14 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng dch...@google.com wrote: 1) The frames attempt no synchronization and both just call requestFullscreen(). In that case, the observable difference is largely moot. It shouldn't be surprising that racing operations like this cross origin returns a non-deterministic result. This is the position the Chrome out-of-process team is taking for other sorts of actions that have effects visible outside the frame (for example, navigating the top level frame, multiple frames sending a postMessage to the same frame, etc). 2) One frame calls requestFullscreen() and then sends a postMessage() to another frame, which calls requestFullscreen() upon receiving the message. Going fullscreen requires coordination with the browser process, so ordering is preserved by browser IPC message handling. So I tried to figure out how one would implement this in JavaScript as an exercise. You'd have a privileged asynchronous API that resizes the top-level browsing context's document's viewport. It calls a callback once that's done, presumably synchronized with animation frames. Now at that point you need to get hold of all your ancestor documents and start changing state outward-in. Some of these ancestor documents you can get a hold of synchronously, but not all. What if there's a cross-origin document inbetween? Now what I'm afraid of is that one of these ancestors or perhaps a descendant is also playing with requestFullscreen() and since the changing of state does not happen globally you end up with inconsistent state. Given that you haven't produced a black-box experiment that distinguishes the two approaches, different implementations can use different approaches and be interoperable. Adam
Re: [whatwg] Fullscreen API and out-of-process iframe
On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote: Given that you haven't produced a black-box experiment that distinguishes the two approaches, different implementations can use different approaches and be interoperable. I guess. That still doesn't help us much defining it. However, I'm not convinced that just because I can't come up with an example, there is none. B is nested through A. A invokes requestFullscreen() and then does synchronous XMLHttpRequest, locking its event loop. B also invokes requestFullscreen(), posts a message to A about updating its state. A's synchronous XMLHttpRequest stops, it updates its state per B, and then gets to the point of putting its own element fullscreen. The end result is something that the current specification deems impossible which seems bad. I guess what needs to happen is that when requestFullscreen() is invoked it needs to do synchronous checks and those need to be done again just before the document changes state. And the only check that involves out-of-process iframe (nested browsing contexts) will block I guess, but that only needs to be made at the initial invocation I think. -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote: Given that you haven't produced a black-box experiment that distinguishes the two approaches, different implementations can use different approaches and be interoperable. I guess. That still doesn't help us much defining it. However, I'm not convinced that just because I can't come up with an example, there is none. B is nested through A. A invokes requestFullscreen() and then does synchronous XMLHttpRequest, locking its event loop. B also invokes requestFullscreen(), posts a message to A about updating its state. A's synchronous XMLHttpRequest stops, it updates its state per B, and then gets to the point of putting its own element fullscreen. The end result is something that the current specification deems impossible which seems bad. I'm not sure I understand the significance of the synchronous XHR. I don't see what would change about your example if it were removed. There doesn't appear to be any known ordering between the two requestFullscreen calls and A only learns about what happens to B asynchronously. I guess what needs to happen is that when requestFullscreen() is invoked it needs to do synchronous checks and those need to be done again just before the document changes state. And the only check that involves out-of-process iframe (nested browsing contexts) will block I guess, but that only needs to be made at the initial invocation I think. I don't think that's the case. Have you started your implementation of out-of-process iframes? Some of these issues are easier to grapple with once you're deeper into the implementation. Adam
Re: [whatwg] Fullscreen API and out-of-process iframe
On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote: Given that you haven't produced a black-box experiment that distinguishes the two approaches, different implementations can use different approaches and be interoperable. I guess. That still doesn't help us much defining it. However, I'm not convinced that just because I can't come up with an example, there is none. B is nested through A. A invokes requestFullscreen() and then does synchronous XMLHttpRequest, locking its event loop. B also invokes requestFullscreen(), posts a message to A about updating its state. A's synchronous XMLHttpRequest stops, it updates its state per B, and then gets to the point of putting its own element fullscreen. The end result is something that the current specification deems impossible which seems bad. The race you describe is possible today if you assume A and B are collaborating by communicating with servers that can talk to each other. It's even true if A and B are loaded into different tabs or different browsers completely. A invokes requestFullscreen() or requestPointerLock() or anything else that touches a machine-global resorce and then sends a message over the network to A's server which forwards to B's server which forwards to B. B then invokes requestWhatever() with the 'knowledge' that its invocation has a happens-after relationship with A's, even though in practice A's requestWhatever() may not have propagated through the browser sufficient to touch the shared resource (i.e. ask the OS for fullscreen support / pointer lock / whatnot). This isn't new, but it's so rare and convoluted that I really doubt it ever happens in practice. A more practical sort of race of this nature can happen with NPAPI plugins which in multi-process browsers are a shared, global resource. Chrome (and I believe other multi-process browsers as well) do not run the event loops for different tabs referencing the same plugin in lockstep, so it's very easy for otherwise unrelated tabs to communicate information to each other through a plugin. This can include cross-origin pages if the plugin's same-origin policy is relaxed or relax-able as it is in some cases. It is theoretically possible to construct all sorts of cases where the behavior is black-box distinguishable from running all such tabs in lockstep with each other, but in practice nobody cares. I strongly suspect the situation with cross-origin iframes is similar. While you can construct scenarios where different frames communicate with each other through various channels and come up with answers that seem to contradict knowledge about shared global state, in practice it won't matter. In practice one frame will 'win' and one will 'lose', both will run the appropriate promise handler, and both will continue executing normally. I guess what needs to happen is that when requestFullscreen() is invoked it needs to do synchronous checks and those need to be done again just before the document changes state. And the only check that involves out-of-process iframe (nested browsing contexts) will block I guess, but that only needs to be made at the initial invocation I think. You could, of course, come up with a synchronous checking scheme similar to the storage mutex but barring somebody discovering a significant web compat issue I suspect that, as with the storage mutex, it would be completely ignored by all vendors. - James -- http://annevankesteren.nl/
[whatwg] Fullscreen API and out-of-process iframe
There's two things the Fullscreen API does: 1. Resize the top-level browsing context's document's viewport. (I.e. resizing the window of the browser.) 2. Change state of that document and its descendant documents. 1 needs to happen asynchronously. 2 needs to happen from a task per-document. Potentially 2 could happen from a task per unit of related browsing contexts, but I'm not sure if that's better. 2 also needs to be synchronized with animation frames, once we figure out how to define that. (How are animation frames synchronized across iframe boundaries?) I don't really see a way to avoid having a global flag across process boundaries. E.g. if B is nested through A (assume allowfullscreen is set), A and B are cross-origin, and both invoke requestFullscreen(), what happens? (YouTube embedded in some other app.) Anyone with a good idea how we could make this work? There's some background on some of this available here: * https://www.w3.org/Bugs/Public/show_bug.cgi?id=26366 (It's possible to go fullscreen with an element not in the document) * https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 (Allow fullscreenchange events to be synchronized with animation frames) -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
Can you explain what experiment you could run to determine whether (2) happens synchronously or asynchronously? Adam On Jul 28, 2014 9:03 AM, Anne van Kesteren ann...@annevk.nl wrote: There's two things the Fullscreen API does: 1. Resize the top-level browsing context's document's viewport. (I.e. resizing the window of the browser.) 2. Change state of that document and its descendant documents. 1 needs to happen asynchronously. 2 needs to happen from a task per-document. Potentially 2 could happen from a task per unit of related browsing contexts, but I'm not sure if that's better. 2 also needs to be synchronized with animation frames, once we figure out how to define that. (How are animation frames synchronized across iframe boundaries?) I don't really see a way to avoid having a global flag across process boundaries. E.g. if B is nested through A (assume allowfullscreen is set), A and B are cross-origin, and both invoke requestFullscreen(), what happens? (YouTube embedded in some other app.) Anyone with a good idea how we could make this work? There's some background on some of this available here: * https://www.w3.org/Bugs/Public/show_bug.cgi?id=26366 (It's possible to go fullscreen with an element not in the document) * https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 (Allow fullscreenchange events to be synchronized with animation frames) -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
On Jul 28, 2014 10:58 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 28, 2014 at 7:42 PM, Adam Barth w...@adambarth.com wrote: Can you explain what experiment you could run to determine whether (2) happens synchronously or asynchronously? I'm not sure I understand the question. Do you mean if you can observe that the tasks in different documents might run at the same time? I don't think you could observe that. The problem I have is addressing the racing issues with this API. I meant a black-box experiment (i.e., no access to browser internal state). Put another way, can you describe a sequence of events in which the author or the user could observe the difference? If not, then the question is moot. Adam
Re: [whatwg] Fullscreen API and out-of-process iframe
On Mon, Jul 28, 2014 at 9:03 AM, Anne van Kesteren ann...@annevk.nl wrote: (How are animation frames synchronized across iframe boundaries?) requestAnimationFrame specifies that the callback fires for all iframes within the same task, but it's not black-box observable between cross-origin iframes so it doesn't matter. - James
Re: [whatwg] Fullscreen events dispatched to elements
What do you do when element A goes fullscreen and then element B in the same document goes fullscreen on top of it? Do you fire a single fullscreenchange event at B? Or do you fire a fullscreenchange event at A and then at B? Or something else? Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] Fullscreen events dispatched to elements
On Tue, Jun 5, 2012 at 5:57 PM, Jer Noble jer.no...@apple.com wrote: Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Did you inform the spec editor(s) when you decided to make this change? What did they say? As it is a holdover from when we implemented the Mozilla Full Screen API proposal[1], which required that behavior, no. -Jer [1] https://wiki.mozilla.org/Gecko:FullScreenAPI#fullscreenchange_event If you implemented that proposal as-is then authors would usually need a listener on the document as well as the element, and as Chris pointed out, it's simpler to just always listen on the document. Is that true for the Webkit implementation or did you implement something slightly different? Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] Fullscreen events dispatched to elements
On Jun 4, 2012, at 11:23 PM, Robert O'Callahan rob...@ocallahan.org wrote: If you implemented that proposal as-is then authors would usually need a listener on the document as well as the element, and as Chris pointed out, it's simpler to just always listen on the document. Is that true for the Webkit implementation or did you implement something slightly different? Sorry, you're right; we did implement something slightly different. We always dispatch a message to the element, and additionally one the document if the element has been removed from the document. So authors only have to add event listeners to one or the other. -Jer
Re: [whatwg] Fullscreen events dispatched to elements
On 06/05/2012 09:31 AM, Jer Noble wrote: On Jun 4, 2012, at 11:23 PM, Robert O'Callahan rob...@ocallahan.org wrote: If you implemented that proposal as-is then authors would usually need a listener on the document as well as the element, and as Chris pointed out, it's simpler to just always listen on the document. Is that true for the Webkit implementation or did you implement something slightly different? Sorry, you're right; we did implement something slightly different. We always dispatch a message to the element, and additionally one the document if the element has been removed from the document. So authors only have to add event listeners to one or the other. That is rather unusual behavior. I don't recall any other cases when such additional event is dispatched if node is removed from document. -Olli -Jer
Re: [whatwg] Fullscreen events dispatched to elements
On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble jer.no...@apple.com wrote: Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Why should we standardize this if we always notify the document? Is there a benefit to notifying both the element and the document? For better or worse, existing implementations are still prefixed as far as I know and incompatible with each other. So that in itself is not really an argument for changing the standard. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Fullscreen events dispatched to elements
On Tue, Jun 5, 2012 at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble jer.no...@apple.com wrote: Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Why should we standardize this if we always notify the document? Is there a benefit to notifying both the element and the document? Many applications will consider they are the only users of an interface. If so, it doesn't matter much where the notifications come in. Next, developers are likely to include more than one bit of functionality on a page. E.g. a game portal with a few games that could be clicked on to go Fullscreen and or enter Pointer Lock. It's more straight forward to place listeners on each game's relevant elements, and not expect to receive cross communication from some other portion of the page. If listeners must all live on the document than application developers must write more code to track what's going on. Oh, you received an error event? Has this component recently attempted fullscreen/lock? What if you did request and you will succeed, but another component also requested on the same user gesture and that generated an error event? Application developers all must go through some additional checks to figure out if the messages were intended for them. Finally, some pages may have applications that expect to be removed from the DOM. I don't think we'd expect this very often, but developers should be able to handle it. Even if the specs didn't dispatch change events to the document the developers could detect that the element was removed and stop whatever they were doing with them.
Re: [whatwg] Fullscreen events dispatched to elements
On Jun 5, 2012, at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote: Why should we standardize this if we always notify the document? Is there a benefit to notifying both the element and the document? I think Vincent put forward a reasonable argument. The document is a finite, shared resource. Requiring authors to share that resource will inevitably lead to conflicts. Those (hypothetical) conflicts may be manageable, but including the fullscreen element in the event dispatch gives developers a means to avoid them entirely. For better or worse, existing implementations are still prefixed as far as I know and incompatible with each other. So that in itself is not really an argument for changing the standard. Of course. I was just pointing out an alternate solution. -Jer
Re: [whatwg] Fullscreen events dispatched to elements
On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote: Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. -Jer
Re: [whatwg] Fullscreen events dispatched to elements
On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble jer.no...@apple.com wrote: On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote: Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Did you inform the spec editor(s) when you decided to make this change? What did they say? Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] Fullscreen events dispatched to elements
On Jun 4, 2012, at 10:43 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble jer.no...@apple.com wrote: On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote: Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Did you inform the spec editor(s) when you decided to make this change? What did they say? As it is a holdover from when we implemented the Mozilla Full Screen API proposal[1], which required that behavior, no. -Jer [1] https://wiki.mozilla.org/Gecko:FullScreenAPI#fullscreenchange_event
[whatwg] Fullscreen events dispatched to elements
I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted recently to mimic Fullscreen [2]. The Fullscreen specification calls for events to be dispatched to the document, but the WebKit implementation dispatches fullscreenchange and fullscreenerror events to the context element (and they bubble to the document). IMHO Pointer Lock would be more convenient to use if events are sent to the target element as well, and not just the document. Is there a reason the Fullscreen specification doesn't dispatch events to the most relevant element? There is a related thread started on May 11th 2011 by Jer Noble where he proposes dispatching to the elements, but the thread moves onto other topics. I don't see a resolution regarding dispatching to elements other than early general approval by Robert O'Callahan. [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: [whatwg] Fullscreen events dispatched to elements
On 2/06/2012 11:19 a.m., Vincent Scheib wrote: IMHO Pointer Lock would be more convenient to use if events are sent to the target element as well, and not just the document. Is there a reason the Fullscreen specification doesn't dispatch events to the most relevant element? Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Because of this, the spec was then changed to dispatch fullscreenchange to the context element on entering fullscreen, and to the document on exit, but we found this inconsistent, since a listener has to listen to multiple nodes to receive both exit and enter events, so the spec was changed again to always dispatch fullscreenchange to the document. Regards, Chris P.
Re: [whatwg] Fullscreen and non-HTML elements
On Fri, 06 Apr 2012 16:51:30 +0200, Anne van Kesteren ann...@opera.com wrote: On Fri, 06 Apr 2012 16:25:20 +0200, Doug Schepers schep...@w3.org wrote: What's the rationale for restricting what authors (or users) can make fullscreen? You cannot render arbitrary SVG elements without a root svg element as far as I know. Sure you can - that's what zoom and pan does... Applying some preserveAspectRatio to determine *how* they fit into the fullscreen might be a handy feature creep... cheers -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Fullscreen and non-HTML elements
On Mon, Apr 9, 2012 at 4:58 AM, Charles McCathieNevile cha...@opera.comwrote: On Fri, 06 Apr 2012 16:51:30 +0200, Anne van Kesteren ann...@opera.com wrote: On Fri, 06 Apr 2012 16:25:20 +0200, Doug Schepers schep...@w3.org wrote: What's the rationale for restricting what authors (or users) can make fullscreen? You cannot render arbitrary SVG elements without a root svg element as far as I know. Sure you can - that's what zoom and pan does... Applying some preserveAspectRatio to determine *how* they fit into the fullscreen might be a handy feature creep... Pan and zoom pans, and zooms, a rectangular area inside an svg element. It does not individually render a specific SVG subtree. The SVG specifications do not define rendering for subtrees that are not rooted at svg elements (and rightly so; the svg element is needed to define things like the coordinate space). -- Ian Hickson
Re: [whatwg] Fullscreen changes to support dialog
Ojan wrote: Escape usually calls cancel on dialogs, no? Seems to me that if you have a dialog open, esc should cancel the dialog, otherwise it should yank all fullscreened elements. Doesn't this suffer from the same sort of security attack that requires us to leave all fullscreened elements on ESC? Attacker opens fullscreen element, displays dialog, styles the dialog to cover the entire viewport, then makes the fullscreen element into an emulated desktop. User hits ESC, dialog goes away, and the user is left in the emulated desktop. Ted
Re: [whatwg] Fullscreen changes to support dialog
On Tue, Apr 3, 2012 at 4:14 PM, Ian Hickson i...@hixie.ch wrote: Fullscreen then defines that when you make an element fullscreen, it's pushed onto the top layer, and when an element is unfullscreened, it's yanked from the top layer. The user emergency escape UI yanks all fullscreened elements from the top layer (but leaves any other elements in it; we wouldn't want dialogs to disappear when exiting full screen mode). Escape usually calls cancel on dialogs, no? Seems to me that if you have a dialog open, esc should cancel the dialog, otherwise it should yank all fullscreened elements.
[whatwg] Fullscreen and non-HTML elements
Hey, The other day I was wondering whether I should change Fullscreen to not be applicable to all elements. I was thinking HTMLElement and SVGSvgElement (svg:svg) would probably be best. My reasoning was that it will not work for svg:rect and such. Just now I noticed https://bugzilla.mozilla.org/show_bug.cgi?id=735031 so maybe I am missing something? Cheers, -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen and non-HTML elements
On Fri, 06 Apr 2012 16:25:20 +0200, Doug Schepers schep...@w3.org wrote: What's the rationale for restricting what authors (or users) can make fullscreen? You cannot render arbitrary SVG elements without a root svg element as far as I know. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen and non-HTML elements
On Fri, 6 Apr 2012, Anne van Kesteren wrote: The other day I was wondering whether I should change Fullscreen to not be applicable to all elements. I was thinking HTMLElement and SVGSvgElement (svg:svg) would probably be best. My reasoning was that it will not work for svg:rect and such. There's plenty of HTML elements that it doesn't make sense to fullscreen either -- e.g. source, any of the ones in head, any with a hidden= attribute, any marked display:none, etc. So we have to handle that anyway. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen changes to support dialog
On Thu, 05 Apr 2012 06:53:08 +0200, Ian Hickson i...@hixie.ch wrote: Those sound like non-modal dialogs. Do you have any examples of modal dialogs on the Web that have these behaviours? As above, screenshots and URLs to such examples would be really helpful. I can see how it makes sense in the abstract. Browsers moved away from application-global modal dialogs to tab modal dialogs. I could see Twitter still wanting to you let you switch to @Connect or #Discover or search, while a modal dialog with user information is open. However, we could do that in a future version by allowing the size of ::backdrop to be adjusted by setting the top/left/bottom/right properties. Does that make sense? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen changes to support dialog
On 5/04/12 2:53 PM, Ian Hickson wrote: On Thu, 5 Apr 2012, Sean Hogan wrote: So the ::backdrop could be styled to not cover the whole page? Could it default to a top layer, but optionally be given a z-index? The ::backdrop specifically would just be immediately below its element in the top layer stack, at least as proposed. Could you elaborate on what your use case is for moving it to other layers? (Ideally with examples of dialogs that do this in the wild -- see the wiki page on which we designed thedialog feature -- http://wiki.whatwg.org/wiki/Dialogs -- for the examples that have primarily driven the design so far.) On Thu, 5 Apr 2012, Sean Hogan wrote: So this top layer prevents all user-interaction with the rest of the page? No, that would be inherent in thedialog showModal() behaviour. If that's the case, it seems a bit inflexible. I would imagine that some UI designers would like parts of the page to still be clickable - a couple of examples: - a toggle button to show / hide the dialog (probably part of a menu-bar). - a menu bar with buttons that, when activated, first dismiss the dialog Those sound like non-modal dialogs. Do you have any examples of modal dialogs on the Web that have these behaviours? As above, screenshots and URLs to such examples would be really helpful. Look at my blog: http://meekostuff.net/blog/ At the bottom is a simple site menu. If you click on the contact link it pops up a dialog with a backdrop that covers the whole page... except for the site menu. The dialog can be hidden by a close link in the dialog OR by clicking the contact link again. The page itself is non-interactive. It's just the bottom menu that doesn't lose interactivity, because it has a higher z-index than the backdrop. I suppose another way of achieving this with dialogs would be to make the site menu a dialog that has no backdrop but is always on top. I don't know if that's something worth considering for the spec. Sean
Re: [whatwg] Fullscreen changes to support dialog
On Thu, Apr 5, 2012 at 3:58 AM, Anne van Kesteren ann...@opera.com wrote: I can see how it makes sense in the abstract. Browsers moved away from application-global modal dialogs to tab modal dialogs. I could see Twitter still wanting to you let you switch to @Connect or #Discover or search, while a modal dialog with user information is open. However, we could do that in a future version by allowing the size of ::backdrop to be adjusted by setting the top/left/bottom/right properties. Does that make sense? I think in general, users will want to constrain to a specific element's dimensions. In the vast majority of cases where I see anything constrained, the dimensions are calculated based on the position and/or dimensions of another element. However, there are definitely cases where users want to constrain based on specific locations which may not be related to an element. I would also say that a large percentage of users struggle with position/offset math, so defining top/left/bottom/right properties may be tough for the average user. This is complicated by the fact that the content on a page is likely dynamic and therefore so is the size of what needs to be covered. I expect this would be further complicated by responsive designs where the dimensions may change at any point, are are likely not defined in pixel values in the first place. Perhaps the partial page covering scenarios are uncommon enough that users who want this functionality will have the knowledge required to implement it properly.
Re: [whatwg] Fullscreen changes to support dialog
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson i...@hixie.ch wrote: If this works, then I'll use this for dialog. Thanks for figuring this out. I was kind of hoping this would end up in a CSS draft, but Fullscreen works for now I guess. http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html Looking forward to dialog! -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen changes to support dialog
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson i...@hixie.ch wrote: If this works, then I'll use this for dialog. How does this work for nested browsing contexts? Currently using iframe allowfullscreen (not in HTML yet) you can fullscreen elements embedded via an iframe. Would we then have to push the iframe element on the stack and make its height and width cover the viewport, and then push the element in question inside the iframe on the stack, or do we want to deal with this in another way? Which pseudo-classes are we keeping? :fullscreen still seems useful, :fullscreen-ancestor probably not. What are the new default styles going to be? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen changes to support dialog
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson i...@hixie.ch wrote:
If this works, then I'll use this for dialog.
How does this work for nested browsing contexts? Currently using iframe
allowfullscreen (not in HTML yet) you can fullscreen elements embedded via
an iframe. Would we then have to push the iframe element on the stack
and make its height and width cover the viewport, and then push the element
in question inside the iframe on the stack, or do we want to deal with
this in another way?
The thinking so far is that we don't do anything special for dialogs.
They don't escape their iframe, and the iframe doesn't have any
special response to a dialog spawning within it, unlike for
fullscreen.
Which pseudo-classes are we keeping? :fullscreen still seems useful,
:fullscreen-ancestor probably not. What are the new default styles going to
be?
In the www-style thread I gave a proposal for the new styling. I'll
reproduce it here:
:fullscreen {
position: fixed;
top: 0; left: 0; right: 0; bottom: 0;
}
:fullscreen::backdrop {
position: fixed;
top: 0; left: 0; right: 0; bottom: 0;
background: black;
}
dialog[modal] {
position: center;
}
dialog[modal]::backdrop {
position: fixed;
top: 0; left: 0; right: 0; bottom: 0;
}
I'm not 100% certain these are correct (in particular, Hixie says that
using position:center for the dialog[modal] is bad, and that we
instead want abspos with a specialized static position), but it's a
start.
As far as I can tell, you're right that we no longer need the
:fullscreen-ancestor pseudo.
~TJ
Re: [whatwg] Fullscreen changes to support dialog
On Wed, 04 Apr 2012 19:31:22 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesteren ann...@opera.com
wrote:
How does this work for nested browsing contexts? Currently using iframe
allowfullscreen (not in HTML yet) you can fullscreen elements embedded
via an iframe. Would we then have to push the iframe element on the
stack and make its height and width cover the viewport, and then push
the element in question inside the iframe on the stack, or do we want
to deal with
this in another way?
The thinking so far is that we don't do anything special for dialogs.
They don't escape their iframe, and the iframe doesn't have any
special response to a dialog spawning within it, unlike for
fullscreen.
That's why I was asking for what I should do with fullscreen :-)
:fullscreen::backdrop {
position: fixed;
top: 0; left: 0; right: 0; bottom: 0;
background: black;
}
Hixie's proposal mentioned you could only style background related
properties for this pseudo-element. But okay, all seems easy enough.
As far as I can tell, you're right that we no longer need the
:fullscreen-ancestor pseudo.
Yay, it was ugly.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Fullscreen changes to support dialog
On Wed, Apr 4, 2012 at 10:39 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 04 Apr 2012 19:31:22 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: The thinking so far is that we don't do anything special for dialogs. They don't escape their iframe, and the iframe doesn't have any special response to a dialog spawning within it, unlike for fullscreen. That's why I was asking for what I should do with fullscreen :-) Ah, kk. We should keep the current behavior that walks up the browsing context chain and fullscreens everything it can, since you want to be able to fullscreen, say, a Youtube video embedded via iframe. ~TJ
Re: [whatwg] Fullscreen changes to support dialog
On 5/04/12 3:31 AM, Tab Atkins Jr. wrote:
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesterenann...@opera.com wrote:
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hicksoni...@hixie.ch wrote:
If this works, then I'll use this fordialog.
How does this work for nested browsing contexts? Currently usingiframe
allowfullscreen (not in HTML yet) you can fullscreen elements embedded via
aniframe. Would we then have to push theiframe element on the stack
and make its height and width cover the viewport, and then push the element
in question inside theiframe on the stack, or do we want to deal with
this in another way?
The thinking so far is that we don't do anything special for dialogs.
They don't escape theiriframe, and theiframe doesn't have any
special response to a dialog spawning within it, unlike for
fullscreen.
Which pseudo-classes are we keeping? :fullscreen still seems useful,
:fullscreen-ancestor probably not. What are the new default styles going to
be?
In the www-style thread I gave a proposal for the new styling. I'll
reproduce it here:
:fullscreen {
position: fixed;
top: 0; left: 0; right: 0; bottom: 0;
}
:fullscreen::backdrop {
position: fixed;
top: 0; left: 0; right: 0; bottom: 0;
background: black;
}
dialog[modal] {
position: center;
}
dialog[modal]::backdrop {
position: fixed;
top: 0; left: 0; right: 0; bottom: 0;
}
So the ::backdrop could be styled to not cover the whole page?
Could it default to a top layer, but optionally be given a z-index?
Sean
Re: [whatwg] Fullscreen changes to support dialog
On 4/04/12 9:14 AM, Ian Hickson wrote: So based on our discussions on IRC and in person earlier today, I think the following additions to the Fullscreen specification would provide the necessary infrastructure to supportdialog: - Add a new stacking layer to the CSS 2.1 Appendix E layering model, after the current layer 10. Let's call this new layer the top layer. This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. An element in this layer is rendered in the CSS model as an atomic unit that is a sibling to the root element; overflow, opacity, masks, clips, etc, of ancestor elements do not affect it. Outlines must be rendered in their non-layer-10 position if they are specified on an element with an ancestor-or-self that is in such a stack. An element in this layer that has an ancestor-or-self that is display:none does not get rendered. The 'position' property for elements in one of these stacks computes to 'absolute', 'fixed', or 'center' if that is its specifed value, and to 'absolute' if the specified value is anything else. The containing block for such an element is the initial containing block, same as for the root element. The static position for left, right, and top are zero, unless overridden by another specification. (Thedialog spec will override the static position for top.) - Define an algorithm to push an element onto the top layer, which adds a given element to this element's browsing context's viewport's stack, if the element is in a document. - Define an algorithm to yank an element from the top layer, which removes the given element from the stack it is in. When an element is removed from a document, it must be yanked from the top layer. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) Fullscreen then defines that when you make an element fullscreen, it's pushed onto the top layer, and when an element is unfullscreened, it's yanked from the top layer. The user emergency escape UI yanks all fullscreened elements from the top layer (but leaves any other elements in it; we wouldn't want dialogs to disappear when exiting full screen mode). If this works, then I'll use this fordialog. Cheers, So this top layer prevents all user-interaction with the rest of the page? If that's the case, it seems a bit inflexible. I would imagine that some UI designers would like parts of the page to still be clickable - a couple of examples: - a toggle button to show / hide the dialog (probably part of a menu-bar). - a menu bar with buttons that, when activated, first dismiss the dialog Sean
Re: [whatwg] Fullscreen changes to support dialog
On Wed, Apr 4, 2012 at 9:50 PM, Sean Hogan shogu...@westnet.com.au wrote: Will non-modal `dialog` have a backdrop? Dunno! We've just been thinking about modal dialogs, since they're the hard ones. ~TJ
Re: [whatwg] Fullscreen changes to support dialog
On Wed, Apr 4, 2012 at 8:51 PM, Sean Hogan shogu...@westnet.com.au wrote: So the ::backdrop could be styled to not cover the whole page? Yes. It's there for convenience only, since people often want an element that does exactly this. If we didn't provide it explicitly, they'd just awkwardly wrap their dialogs in a background element anyway. Could it default to a top layer, but optionally be given a z-index? Can you describe a use-case for putting the ::backdrop somewhere other than directly underneath the dialog/fullscreen element? On Wed, Apr 4, 2012 at 8:58 PM, Sean Hogan shogu...@westnet.com.au wrote: So this top layer prevents all user-interaction with the rest of the page? If that's the case, it seems a bit inflexible. I would imagine that some UI designers would like parts of the page to still be clickable - a couple of examples: - a toggle button to show / hide the dialog (probably part of a menu-bar). - a menu bar with buttons that, when activated, first dismiss the dialog Both of your examples would be done by using elements that are children of the dialog, and perhaps just positioned explicitly somewhere. ~TJ
Re: [whatwg] Fullscreen changes to support dialog
On Wed, Apr 4, 2012 at 9:33 PM, Sean Hogan shogu...@westnet.com.au wrote: On 5/04/12 2:15 PM, Tab Atkins Jr. wrote: Both of your examples would be done by using elements that are children of thedialog, and perhaps just positioned explicitly somewhere. That doesn't sound like a good solution, but maybe I'm misunderstanding. Look at my blog: http://meekostuff.net/blog/ At the bottom is a simple site menu. If you click on the contact link it pops up a dialog with a backdrop that covers the whole page... except for the site menu. The dialog can be hidden by a close link in the dialog, OR by clicking the contact link again. I'm not 100% certain, but I suspect this isn't doable with dialog modal, because that's not a modal dialog. It's a normal dialog; you just happen to be using a similar visual effect (darkening the rest of the page) as what modal dialogs typically do, presumably so as to focus attention on the dialog. ~TJ
Re: [whatwg] Fullscreen changes to support dialog
On Thu, 5 Apr 2012, Sean Hogan wrote: So the ::backdrop could be styled to not cover the whole page? Could it default to a top layer, but optionally be given a z-index? The ::backdrop specifically would just be immediately below its element in the top layer stack, at least as proposed. Could you elaborate on what your use case is for moving it to other layers? (Ideally with examples of dialogs that do this in the wild -- see the wiki page on which we designed the dialog feature -- http://wiki.whatwg.org/wiki/Dialogs -- for the examples that have primarily driven the design so far.) On Thu, 5 Apr 2012, Sean Hogan wrote: So this top layer prevents all user-interaction with the rest of the page? No, that would be inherent in the dialog showModal() behaviour. If that's the case, it seems a bit inflexible. I would imagine that some UI designers would like parts of the page to still be clickable - a couple of examples: - a toggle button to show / hide the dialog (probably part of a menu-bar). - a menu bar with buttons that, when activated, first dismiss the dialog Those sound like non-modal dialogs. Do you have any examples of modal dialogs on the Web that have these behaviours? As above, screenshots and URLs to such examples would be really helpful. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen changes to support dialog
On 5/04/12 2:15 PM, Tab Atkins Jr. wrote: On Wed, Apr 4, 2012 at 8:51 PM, Sean Hoganshogu...@westnet.com.au wrote: So the ::backdrop could be styled to not cover the whole page? Yes. It's there for convenience only, since people often want an element that does exactly this. If we didn't provide it explicitly, they'd just awkwardly wrap theirdialogs in a background element anyway. Could it default to a top layer, but optionally be given a z-index? Can you describe a use-case for putting the ::backdrop somewhere other than directly underneath the dialog/fullscreen element? So that a menu-bar in the page can still be interacted with. An optional z-index would be easier than calculating backdrop dimensions to not overlap. On Wed, Apr 4, 2012 at 8:58 PM, Sean Hoganshogu...@westnet.com.au wrote: So this top layer prevents all user-interaction with the rest of the page? If that's the case, it seems a bit inflexible. I would imagine that some UI designers would like parts of the page to still be clickable - a couple of examples: - a toggle button to show / hide the dialog (probably part of a menu-bar). - a menu bar with buttons that, when activated, first dismiss the dialog Both of your examples would be done by using elements that are children of thedialog, and perhaps just positioned explicitly somewhere. That doesn't sound like a good solution, but maybe I'm misunderstanding. Look at my blog: http://meekostuff.net/blog/ At the bottom is a simple site menu. If you click on the contact link it pops up a dialog with a backdrop that covers the whole page... except for the site menu. The dialog can be hidden by a close link in the dialog, OR by clicking the contact link again.
Re: [whatwg] Fullscreen changes to support dialog
On 5/04/12 2:39 PM, Tab Atkins Jr. wrote: On Wed, Apr 4, 2012 at 9:33 PM, Sean Hoganshogu...@westnet.com.au wrote: On 5/04/12 2:15 PM, Tab Atkins Jr. wrote: Both of your examples would be done by using elements that are children of thedialog, and perhaps just positioned explicitly somewhere. That doesn't sound like a good solution, but maybe I'm misunderstanding. Look at my blog: http://meekostuff.net/blog/ At the bottom is a simple site menu. If you click on the contact link it pops up a dialog with a backdrop that covers the whole page... except for the site menu. The dialog can be hidden by a close link in the dialog, OR by clicking the contact link again. I'm not 100% certain, but I suspect this isn't doable withdialog modal, because that's not a modal dialog. It's a normal dialog; you just happen to be using a similar visual effect (darkening the rest of the page) as what modal dialogs typically do, presumably so as to focus attention on the dialog. No, it uses a backdrop to cover the content of the page so that it becomes non-interactive. It's just the bottom menu that doesn't lose interactivity, because it has a higher z-index. Will non-modal `dialog` have a backdrop? Sean
[whatwg] Fullscreen changes to support dialog
So based on our discussions on IRC and in person earlier today, I think the following additions to the Fullscreen specification would provide the necessary infrastructure to support dialog: - Add a new stacking layer to the CSS 2.1 Appendix E layering model, after the current layer 10. Let's call this new layer the top layer. This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. An element in this layer is rendered in the CSS model as an atomic unit that is a sibling to the root element; overflow, opacity, masks, clips, etc, of ancestor elements do not affect it. Outlines must be rendered in their non-layer-10 position if they are specified on an element with an ancestor-or-self that is in such a stack. An element in this layer that has an ancestor-or-self that is display:none does not get rendered. The 'position' property for elements in one of these stacks computes to 'absolute', 'fixed', or 'center' if that is its specifed value, and to 'absolute' if the specified value is anything else. The containing block for such an element is the initial containing block, same as for the root element. The static position for left, right, and top are zero, unless overridden by another specification. (The dialog spec will override the static position for top.) - Define an algorithm to push an element onto the top layer, which adds a given element to this element's browsing context's viewport's stack, if the element is in a document. - Define an algorithm to yank an element from the top layer, which removes the given element from the stack it is in. When an element is removed from a document, it must be yanked from the top layer. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) Fullscreen then defines that when you make an element fullscreen, it's pushed onto the top layer, and when an element is unfullscreened, it's yanked from the top layer. The user emergency escape UI yanks all fullscreened elements from the top layer (but leaves any other elements in it; we wouldn't want dialogs to disappear when exiting full screen mode). If this works, then I'll use this for dialog. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen changes to support dialog
This seems reasonable to me. On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson i...@hixie.ch wrote: This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. Is each element in this stack treated as having its own stacking context? I assume so, but you'd better say so. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) It's probably more work to make all non-background properties inapplicable than it would be to simply treat it like ::before/::after generated content. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] Fullscreen changes to support dialog
On Tue, Apr 3, 2012 at 5:29 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson i...@hixie.ch wrote: This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. Is each element in this stack treated as having its own stacking context? I assume so, but you'd better say so. Yes, definitely. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) It's probably more work to make all non-background properties inapplicable than it would be to simply treat it like ::before/::after generated content. Strongly agreed. For one, it's annoying to restrict things. For two, it's badly-defined what background properties are - it's possible for properties that aren't prefixed with background- to affect backgrounds (for example, image-resolution). For three, this assumes that we have thought of all possible things that can be applied by non-background properties, including properties not yet dreamed up, and decided that they're all useless. Unless there's a good reason to restrict something, keep it unrestricted. ~TJ
Re: [whatwg] Fullscreen changes to support dialog
On Tue, 3 Apr 2012, Ojan Vafai wrote: On Tue, Apr 3, 2012 at 4:14 PM, Ian Hickson i...@hixie.ch wrote: Fullscreen then defines that when you make an element fullscreen, it's pushed onto the top layer, and when an element is unfullscreened, it's yanked from the top layer. The user emergency escape UI yanks all fullscreened elements from the top layer (but leaves any other elements in it; we wouldn't want dialogs to disappear when exiting full screen mode). Escape usually calls cancel on dialogs, no? Seems to me that if you have a dialog open, esc should cancel the dialog, otherwise it should yank all fullscreened elements. Yes, indeed. I didn't mean to specifically refer to the escape key, so much as the generic escape me out of fullscreen mode because I might be being spoofed emergency escape UI. That could just be a button that appears when you hover over the top-right of the screen, for instance. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen changes to support dialog
On Wed, 4 Apr 2012, Robert O'Callahan wrote: On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson i...@hixie.ch wrote: This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. Is each element in this stack treated as having its own stacking context? I assume so, but you'd better say so. Right, each one would be its own atomic stacking context much like a 'position:absolute' box normally is today. I agree this should be explicit in the Fullscreen spec. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) It's probably more work to make all non-background properties inapplicable than it would be to simply treat it like ::before/::after generated content. Either is fine by me. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen CSS
Robert O'Callahan wrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes[…] Also, it doesn't address situations where[…] (and maybe other things I've forgotten). Yeah, I'm sure I missed lots of potential issues in the initial ::cover proposal. Please follow up on the www-style thread linked to below! :) I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it Exaclty. I've made a proposal for a backdrop feature, for the Fullscreen API and dialog, here: http://lists.w3.org/Archives/Public/www-style/2011Nov/0705.html Ted
Re: [whatwg] Fullscreen CSS
On Tue, 15 Nov 2011 00:10:09 +0100, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes --- specially, at least one new rule for CSS stacking contexts in the infamous appendix E. Also, it doesn't address situations where an ancestor of the dialog or fullscreen element has 'opacity', 'transform', 'filter', 'mask' or 'clip-path' (and maybe other things I've forgotten). I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it we need. And figure out what happens if you make part of a page fullscreen and that uses dialog. Or if you have nested dialogs mixed with fullscreen... Hmm. This proposal seems like will make fullscreen styling non-transparent and non-trivial. Currently the elements are just resized and that very easy to implement, understand and workaround with CSS. How would that affect, for instance, a canvas element that is resized to fit the whole screen ?
[whatwg] Fullscreen and keyboard focus.
Hi. Perhaps keyboard focus should be limited only to the fullscreen element or its descendants. If you have a canvas or video fullscreen, alt-tabbing can move the focus outside the fullscreen element, say into form elements. But then this would require giving focus, and dispatching focus events, if the focused element is not inside the fullscreen element subtree.
Re: [whatwg] Fullscreen and keyboard focus.
On Tue, Nov 29, 2011 at 6:25 AM, João Eiras jo...@opera.com wrote: Hi. Perhaps keyboard focus should be limited only to the fullscreen element or its descendants. If you have a canvas or video fullscreen, alt-tabbing can move the focus outside the fullscreen element, say into form elements. But then this would require giving focus, and dispatching focus events, if the focused element is not inside the fullscreen element subtree. I agree. (There's a WebKit bug for this: https://bugs.webkit.org/show_bug.cgi?id=69698)
Re: [whatwg] Fullscreen revision I
Another thing: I've heard from developers that it would be useful to allow popup windows to open in fullscreen mode. For example, in Google Docs presentations, the 'start presentation' button should open a new window in fullscreen, so that users can use the editor in the main Chrome window and see the presentation in a separate (fullscreen) window. I propose that window.open(url, name, fullscreen=yes) should present the given url as fullscreen in a new window. Exiting fullscreen in that window (via cancelFullScreen or user action) should restore the window (if the author wants it to close, they can call window.close() on the fullscreenchange event). Of course, the request should only succeed if the UA is processing a user gesture.
Re: [whatwg] Fullscreen CSS
Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. The CP says The dialog and its cover, taken together, are siblings within a new stacking context which is placed above all other stacking contexts. This seems like something new in CSS. Oh, whoops, indeed. Sorry about that, I forgot the CP worked like that. Yeah, I guess we *would* need some changes to the stacking algorithm. :/ Some thought needs to go into how much of this should be expressed in author-usable CSS and how much should be magic. It seems like we shouldn't assume that these are the only two features that will ever need this sort of rendering support. I'll get a www-style thread going. Ted
Re: [whatwg] Fullscreen CSS
On Thu, Nov 17, 2011 at 8:20 AM, Edward O'Connor eocon...@apple.com wrote: It seems like we shouldn't assume that these are the only two features that will ever need this sort of rendering support. I'll get a www-style thread going. Thanks. If multiple specs (or even multiple running instances of the same spec) try to define a stacking context that is above all other stacking contexts, we'll have a 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 revision I
Sorry for the late reply. Getting to and from TPAC and TPAC itself is basically the reason. I hope you understand. On Wed, 26 Oct 2011 04:06:28 +0200, Robert O'Callahan rob...@ocallahan.org wrote: When you say No longer any attempts at integrating with F11 fullscreen, do you mean to rule out the possibility that UAs do that? E.g., would you allow UAs to have UI that makes the current document fullscreen and sets the fullscreen element to the root element? If UAs want to implement such UI I think that should be fine. However today F11 allows for navigation and such, which this mode does not. About your nested-fullscreen proposal, I do not see how To fix the nested cases, I suggest having a per-document stack of fullscreen elements instead of a single fullscreen element. [...] combines with 2.2 Pop the top element off D's fullscreen element stack until the stack is empty or the element at the top of stack is in D as supposedly everything on D's stack would be in D. Should D.exitFullscreen not just pop one of D's stack and if that stack is empty at that point also clear any descendant document stacks? The only tricky thing there might be order (of events). E.g. if you have a descendant B which has two descendants each with a fullscreen element. I guess you can do them based on the stack order of B. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Fullscreen CSS
I have removed background:black as the way the rendering is defined at the moment is that it cannot be overridden unless !important is used. That's not ideal for backgrounds. Since no color was defined that did not help either. I added margin:0; box-sizing:border-box so the height/width declarations make sense. I also added transition:none to :fullscreen-ancestor per the comment that was present in the draft. Latest draft: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#rendering -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen CSS
On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
Having the rest of the page visible under the fullscreen element is not
expected and I think we should default to avoiding it. background:black
seemed like the right thing for video and a reasonable default for other
kinds of element. Maybe the background:black rule could be at the UA
not-important level?
Glenn Maynard wrote:
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense, but it
doesn't seem right in general.
That's a reasonable point but I'm not sure how to solve it. Making other
page content visible behind divhello/div (which would happen if we just
remove the background rule) is just as unexpected, maybe more so.
Brainstorming:
-- Maybe we could create a new CSS color meaning the document background
color (including the fallback color used when the viewport background is
nominally 'transparent') and use that here?
-- Try a rule :fullscreen-ancestor
:not(:fullscreen-ancestor):not(:fullscreen) { display:none; }? Or
opacity:0?
I really want to avoid solutions that require magical new CSS behaviors.
I think video:fullscreen { background:black; } seems like a good idea in
any case.
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 revision I
On Tue, Nov 15, 2011 at 1:27 AM, Anne van Kesteren ann...@opera.com wrote: Sorry for the late reply. Getting to and from TPAC and TPAC itself is basically the reason. I hope you understand. Yeah no worries mate. About your nested-fullscreen proposal, I do not see how To fix the nested cases, I suggest having a per-document stack of fullscreen elements instead of a single fullscreen element. [...] combines with 2.2 Pop the top element off D's fullscreen element stack until the stack is empty or the element at the top of stack is in D as supposedly everything on D's stack would be in D. The element could have been removed from the document while on the stack. (Apart from ensuring that the fullscreen element is always in the document, this clause ensures that adding elements to a fullscreen stack can't cause elements to be leaked. If the fullscreen stack is the only reference to the element, it must not be in the document, in which case an implementation can remove it from the stack early since step 2.2 would skip over it anyway.) Should D.exitFullscreen not just pop one of D's stack and if that stack is empty at that point also clear any descendant document stacks? That's what I suggested, if elements aren't removed from the document while on the stack. (Of course, if the stack is empty you may also need to pop the stack in the containing document as described in step 2.4.) 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 CSS
On Mon, Nov 14, 2011 at 12:54 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
Having the rest of the page visible under the fullscreen element is not
expected and I think we should default to avoiding it. background:black
seemed like the right thing for video and a reasonable default for other
kinds of element. Maybe the background:black rule could be at the UA
not-important level?
Glenn Maynard wrote:
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense, but it
doesn't seem right in general.
That's a reasonable point but I'm not sure how to solve it. Making other
page content visible behind divhello/div (which would happen if we just
remove the background rule) is just as unexpected, maybe more so.
Brainstorming:
-- Maybe we could create a new CSS color meaning the document background
color (including the fallback color used when the viewport background is
nominally 'transparent') and use that here?
-- Try a rule :fullscreen-ancestor
:not(:fullscreen-ancestor):not(:fullscreen) { display:none; }? Or
opacity:0?
I really want to avoid solutions that require magical new CSS behaviors.
I think video:fullscreen { background:black; } seems like a good idea in
any case.
I think we should go the route that the dialog element did in Ted's
change proposal and have a pseudo-element that gets created when an
element is fullscreened. Simple and easy, and trivial for the author
to manipulate to get most effects they could want.
~TJ
Re: [whatwg] Fullscreen revision I
One problem with the existing implementation in WebKit of fullscreen is that it is possible to focus with Tab elements that are not contained within the fullscreened element. This is a problem for assistive devices in particular. Perhaps we should specify that elements outside the fullscreened subtree should be unfocusable?
Re: [whatwg] Fullscreen CSS
On Mon, 14 Nov 2011 21:25:38 +0100, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 1:38 AM, Anne van Kesteren ann...@opera.com wrote: I have removed background:black as the way the rendering is defined at the moment is that it cannot be overridden unless !important is used. That's not ideal for backgrounds. Can you elaborate on this? Currently we define a specific place in the cascading order for the style rules that currently does not exist. Just before author important basically. I suppose we could put background:black accompanied by color:white in the normal cascading order for user agent style sheets so people could override it easily (and would not make us remove existing backgrounds). Having the rest of the page visible under the fullscreen element is not expected and I think we should default to avoiding it. That seems fair. background:black seemed like the right thing for video and a reasonable default for other kinds of element. Maybe the background:black rule could be at the UA not-important level? UA does not have an important level. But yes, we could do that. But we should include a rule for the color property too. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen CSS
On 11/15/11 11:25 AM, Anne van Kesteren wrote: UA does not have an important level. In Gecko it actually does: it's a level that overrides the user important level. Such a level is sort of needed in some cases, no matter what you actually choose to call it. -Boris
Re: [whatwg] Fullscreen revision I
On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp jere...@chromium.orgwrote: One problem with the existing implementation in WebKit of fullscreen is that it is possible to focus with Tab elements that are not contained within the fullscreened element. This is a problem for assistive devices in particular. Perhaps we should specify that elements outside the fullscreened subtree should be unfocusable? The display:none rule would achieve that. 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 revision I
On Tue, Nov 15, 2011 at 9:59 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp jere...@chromium.orgwrote: One problem with the existing implementation in WebKit of fullscreen is that it is possible to focus with Tab elements that are not contained within the fullscreened element. This is a problem for assistive devices in particular. Perhaps we should specify that elements outside the fullscreened subtree should be unfocusable? The display:none rule would achieve that. I can't find any references to display:none on http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html. Is that not the most recent revision of the spec?
Re: [whatwg] Fullscreen CSS
On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes --- specially, at least one new rule for CSS stacking contexts in the infamous appendix E. Also, it doesn't address situations where an ancestor of the dialog or fullscreen element has 'opacity', 'transform', 'filter', 'mask' or 'clip-path' (and maybe other things I've forgotten). I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it we need. And figure out what happens if you make part of a page fullscreen and that uses dialog. Or if you have nested dialogs mixed with fullscreen... Hmm. 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 CSS
On Mon, Nov 14, 2011 at 3:10 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes --- specially, at least one new rule for CSS stacking contexts in the infamous appendix E. Also, it doesn't address situations where an ancestor of the dialog or fullscreen element has 'opacity', 'transform', 'filter', 'mask' or 'clip-path' (and maybe other things I've forgotten). Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it we need. And figure out what happens if you make part of a page fullscreen and that uses dialog. Or if you have nested dialogs mixed with fullscreen... Hmm. Yes, we should give some thought to how these combine. ~TJ
Re: [whatwg] Fullscreen CSS
On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. The CP says The dialog and its cover, taken together, are siblings within a new stacking context which is placed above all other stacking contexts. This seems like something new in CSS. 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 CSS
On Mon, Nov 14, 2011 at 3:46 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. The CP says The dialog and its cover, taken together, are siblings within a new stacking context which is placed above all other stacking contexts. This seems like something new in CSS. Oh, whoops, indeed. Sorry about that, I forgot the CP worked like that. Yeah, I guess we *would* need some changes to the stacking algorithm. :/ Some thought needs to go into how much of this should be expressed in author-usable CSS and how much should be magic. ~TJ
Re: [whatwg] Fullscreen revision I
On Tue, Nov 15, 2011 at 12:06 PM, Jeremy Apthorp jere...@chromium.orgwrote: On Tue, Nov 15, 2011 at 9:59 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp jere...@chromium.orgwrote: One problem with the existing implementation in WebKit of fullscreen is that it is possible to focus with Tab elements that are not contained within the fullscreened element. This is a problem for assistive devices in particular. Perhaps we should specify that elements outside the fullscreened subtree should be unfocusable? The display:none rule would achieve that. I can't find any references to display:none on http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html. Is that not the most recent revision of the spec? It's something I just made up in the other WHATWG thread :-) 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, 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 revision I
On Tue, Oct 25, 2011 at 12:04 AM, Anne van Kesteren ann...@opera.comwrote: On Tue, 25 Oct 2011 00:32:43 +0900, Glenn Maynard gl...@zewt.org wrote: Doing this synchronously means nobody can ever implement ask-first. Don't permanently lock everyone into a permission scheme with known problems. Since the events are not dispatched synchronously I think we should always be able to change. The fullscreen element is changed synchronously. For ask-first, you want it to change only after permission is granted. It also seems odd that fullscreenElement is set synchronously, but fullscreenchange events are fired asynchronously. It would make more sense to do them together, from the same task (set all fullscreenElements first, then fire all fullscreenchange events). 1) You want them to be set so when the UA does its transition it knows what to transition to. 2) You cannot set them all from the same task because that would not work for non same-origin documents. 4. Return, and perform the following step asynchronously. 5. Optionally, ask the user for permission to enter fullscreen. If permission is denied, terminate these steps. If permission is granted, or if permission is assumed, queue a task to run the following steps: 1. For each document in docs, run these substeps: 1. Let following document be the documenthttp://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-documentafter document in docs, or null if there is no such document. 2. If following document is null, set document's fullscreen elementhttp://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#fullscreen-elementto the context objecthttp://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#context-object, queue a taskhttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#queue-a-taskto fire an eventhttp://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-event-firenamed fullscreenchange with its bubbles attribute set to true on the context objecthttp://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#context-object. 3. Otherwise, set document's fullscreen elementhttp://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#fullscreen-elementto following document's browsing context containerhttp://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context-containerand queue a taskhttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#queue-a-taskto fire an eventhttp://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-event-firenamed fullscreenchange with its bubbles attribute set to true on document. 2. Return, and run the remaining steps asynchronously. 3. Optionally, perform some animation. 4. Optionally, display a message indicating how the user can exit displaying the context objecthttp://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#context-objectfullscreen. This is much more complicated for developers. If fullscreenEnabled can change, you have to monitor it to change UI (eg. show/hide fullscreen buttons). How is this simpler than just making requestFullscreen switch the fullscreen element? If you allow changing the fullscreen element you need to track what documents changed, dispatch events as appropriate, and you keep the problem that exiting exits everything which is quite odd. Exiting everything is odd, but only the rare people who are nesting fullscreening would need to care about it. Allowing fullscreenEnabled to change on the fly complicates code for everyone. I'm not sure how the exits-everything problem relates to the changing the fullscreen element case, though. You should be able to switch fullscreen elements without having to flicker out and back into fullscreen to do so, and without having to move things around in your document. For example, a page with four videos could have next and previous buttons in fullscreen, which shift to the other videos while remaining in full screen. -- Glenn Maynard
Re: [whatwg] Fullscreen revision I
Thanks for working on this. When you say No longer any attempts at integrating with F11 fullscreen, do you mean to rule out the possibility that UAs do that? E.g., would you allow UAs to have UI that makes the current document fullscreen and sets the fullscreen element to the root element? I'm not comfortable with punting the nested-fullscreen cases. It means that if you have a document with an embedded video with fullscreen controls, fullscreening the video works fine when the document is not fullscreen, but if you make the document fullscreen, fullscreening the video just doesn't work anymore. That seems broken (especially if native media fullscreen controls are implemented this way). Authors can work around it, when everything's same-origin, but the workarounds are tricky and require all scripts to cooperate. To fix the nested cases, I suggest having a per-document stack of fullscreen elements instead of a single fullscreen element. In step 1 of requestFullScreen, remove the check for fullscreen elements in the document tree. In step 4.2 instead of setting the fullscreen element, push the context object onto the fullscreen element stack if it's different from the current top of stack. Replace exitFullScreen steps 2 and 3 with: 2.1 Let D be the context object's document 2.2 Pop the top element off D's fullscreen element stack until the stack is empty or the element at the top of stack is in D 2.3 For every child document of D whose browsing context container is not the top of D's fullscreen element stack, clear the fullscreen element stacks of the child document and all its descendant documents. 2.4 If D's fullscreen element stack is empty, and D's browsing context has a browsing context container, then let D be that browsing context container's document, andr return to step 2.2. Places in the spec that currently refer to the fullscreen element would be redefined to be the top of fullscreen element stack, or null if the stack is empty. Browser UI to for a browser window to exit fullscreen would clear the fullscreen element stacks for the entire tree of browsing contexts in the browser window. Thanks, 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 revision I
On Fri, 21 Oct 2011 06:44:05 +0900, Chris Pearce cpea...@mozilla.com wrote: On 21/10/2011 4:10 a.m., Glenn Maynard wrote: The current spec doesn't seem to allow asking permission to fullscreen in advance, since the fullscreen element is set synchronously. This should be supported; there are a lot of potential problems with the ask-after model and it shouldn't be the only model supported. I agree, the spec should definitely allow this. We could make requestFullScreen()'s entire body run in a synchronous section, after any permission has been granted? Why should we allow this if nobody intents on implementing it? However, if we do end up not having requestFullscreen() while fullscreen swap the fullscreen element, then we need to ensure document.fullscreenEnabled returns false while any document is fullscreen. Otherwise video controls won't know to hide their (non-functioning) fullscreen buttons while their document/parent/ancestor documents are fullscreen. I made this change for now to keep the initial version simple. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Fullscreen and event dispatch
Hi. The requestFullscreen steps tells to dispatch a fullscreenchange event on the context object, and all containing objects (frames). First, there should be a better clarification of 'context object'. While is remarked that it is the object used for the last requestFullScreen call which was allowed, it should also refer that for ancestor browsing contexts, it should be the containing frame. This way, fullscreening a contained document will work just as fine as any other kind of element reusing the same css, while for the containing document, it's transparent. Second, the requestFullscreen steps do not cope well if there is already a previous fullscreen element, either in the same document, or in a descendant, ancestor or sibling document. The steps tell to loop all the way up to the top level document and dispatch fullscreenchange events. I would suggest dispatching it *only* for elements and documents where there was a fullscreen change, so if we have a top level document A and a child B, B has two elements, a' and b'. Changing fullscreen from a' to b' would result in two fullscreenchange events, one for each element, inside B, while A should not get a event. I have some doubts if the spec allows this use case though, because the steps for requestFullscreen also mention that if an ancestor browsing context has a non-null fullscreen element, then it should not be allowed to proceed, but this restriction does not apply, again, to sibling elements, or sibling/descendant documents. Third, perhaps fullscreenchange should be split into fullscreenon and fullscreenoff events ?
Re: [whatwg] Fullscreen revision I
On Mon, Oct 24, 2011 at 6:38 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 21 Oct 2011 06:44:05 +0900, Chris Pearce cpea...@mozilla.com wrote: On 21/10/2011 4:10 a.m., Glenn Maynard wrote: The current spec doesn't seem to allow asking permission to fullscreen in advance, since the fullscreen element is set synchronously. This should be supported; there are a lot of potential problems with the ask-after model and it shouldn't be the only model supported. I agree, the spec should definitely allow this. We could make requestFullScreen()'s entire body run in a synchronous section, after any permission has been granted? Why should we allow this if nobody intents on implementing it? Doing this synchronously means nobody can ever implement ask-first. Don't permanently lock everyone into a permission scheme with known problems. It also seems odd that fullscreenElement is set synchronously, but fullscreenchange events are fired asynchronously. It would make more sense to do them together, from the same task (set all fullscreenElements first, then fire all fullscreenchange events). However, if we do end up not having requestFullscreen() while fullscreen swap the fullscreen element, then we need to ensure document.fullscreenEnabled returns false while any document is fullscreen. Otherwise video controls won't know to hide their (non-functioning) fullscreen buttons while their document/parent/ancestor documents are fullscreen. I made this change for now to keep the initial version simple. This is much more complicated for developers. If fullscreenEnabled can change, you have to monitor it to change UI (eg. show/hide fullscreen buttons). How is this simpler than just making requestFullscreen switch the fullscreen element? -- Glenn Maynard
Re: [whatwg] Fullscreen and event dispatch
On Mon, 24 Oct 2011 20:42:18 +0900, João Eiras jo...@opera.com wrote: The requestFullscreen steps tells to dispatch a fullscreenchange event on the context object, and all containing objects (frames). Actually, it says on the context object and all ancestor browsing context's documents. We could change it to always dispatch on the fullscreen element, I guess that might be better. First, there should be a better clarification of 'context object'. While is remarked that it is the object used for the last requestFullScreen call which was allowed, it should also refer that for ancestor browsing contexts, it should be the containing frame. This way, fullscreening a contained document will work just as fine as any other kind of element reusing the same css, while for the containing document, it's transparent. No, context object is the object on which the method is called. The others objects are defined separately. Second, the requestFullscreen steps do not cope well if there is already a previous fullscreen element, either in the same document, or in a descendant, ancestor or sibling document. The steps tell to loop all the way up to the top level document and dispatch fullscreenchange events. Actually, if there a fullscreen element already you will get a fullscreenerror event. I would suggest dispatching it *only* for elements and documents where there was a fullscreen change, so if we have a top level document A and a child B, B has two elements, a' and b'. Changing fullscreen from a' to b' would result in two fullscreenchange events, one for each element, inside B, while A should not get a event. I have some doubts if the spec allows this use case though, because the steps for requestFullscreen also mention that if an ancestor browsing context has a non-null fullscreen element, then it should not be allowed to proceed, but this restriction does not apply, again, to sibling elements, or sibling/descendant documents. Why would it not? The top-level browsing context will always have a non-null fullscreen element if something is fullscreen. Third, perhaps fullscreenchange should be split into fullscreenon and fullscreenoff events? What are the use cases to distinguish them? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen revision I
On Tue, 25 Oct 2011 00:32:43 +0900, Glenn Maynard gl...@zewt.org wrote: Doing this synchronously means nobody can ever implement ask-first. Don't permanently lock everyone into a permission scheme with known problems. Since the events are not dispatched synchronously I think we should always be able to change. It also seems odd that fullscreenElement is set synchronously, but fullscreenchange events are fired asynchronously. It would make more sense to do them together, from the same task (set all fullscreenElements first, then fire all fullscreenchange events). 1) You want them to be set so when the UA does its transition it knows what to transition to. 2) You cannot set them all from the same task because that would not work for non same-origin documents. This is much more complicated for developers. If fullscreenEnabled can change, you have to monitor it to change UI (eg. show/hide fullscreen buttons). How is this simpler than just making requestFullscreen switch the fullscreen element? If you allow changing the fullscreen element you need to track what documents changed, dispatch events as appropriate, and you keep the problem that exiting exits everything which is quite odd. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Fullscreen revision I
I revised the specification based on the comments thus far: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html I made the following changes: * The root element is no longer a special case * No longer any attempts at integrating with F11 fullscreen * requestFullscreen() can no longer be invoked when already in element fullscreen * Queued a task to fire an event on a per-document basis (because of cross-origin documents) * Introduced event for requestFullscreen() failure (fullscreenerror) * Improved the wording around requestFullscreen() failure * Removed Document.fullscreen as it's a subset of Document.fullscreenElement I realize this is not what everyone wants. But this seemed the simplest subset of what everyone desired and a pretty good start from where we can enhance going forward. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/
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 revision I
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense, but it
doesn't seem right in general.
Should margin: 0; padding: 0; be set by :fullscreen?
The current spec doesn't seem to allow asking permission to fullscreen in
advance, since the fullscreen element is set synchronously. This should be
supported; there are a lot of potential problems with the ask-after model
and it shouldn't be the only model supported.
:fullscreen { width: 100%; height: 100%; } will stretch videos and images to
fit the screen, instead of doing something more sensible (letterboxing,
pillarboxing or cropping, depending on aspect ratios and the user or site's
preference). I'm not sure how that should work in general, but
fullscreening a video wouldn't be as simple as video.requestFullScreen().
(I don't recall if video can handle cropping and letterboxing directly;
for example, you don't want to blindly crop a video without the video
knowing about it, or WebVTT subtitles and native controls would get cropped
too.)
On Thu, Oct 20, 2011 at 6:59 AM, Anne van Kesteren ann...@opera.com wrote:
* requestFullscreen() can no longer be invoked when already in element
fullscreen
How do you change the fullscreenElement from one element to another without
exiting fullscreen first? That seems important.
--
Glenn Maynard
Re: [whatwg] Fullscreen revision I
On Thu, 20 Oct 2011 17:10:03 +0200, Glenn Maynard gl...@zewt.org wrote:
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense,
but it
doesn't seem right in general.
Should margin: 0; padding: 0; be set by :fullscreen?
The current spec doesn't seem to allow asking permission to fullscreen in
advance, since the fullscreen element is set synchronously. This should
be
supported; there are a lot of potential problems with the ask-after model
and it shouldn't be the only model supported.
:fullscreen { width: 100%; height: 100%; } will stretch videos and
images to
fit the screen, instead of doing something more sensible (letterboxing,
pillarboxing or cropping, depending on aspect ratios and the user or
site's
preference). I'm not sure how that should work in general, but
fullscreening a video wouldn't be as simple as video.requestFullScreen().
(I don't recall if video can handle cropping and letterboxing directly;
for example, you don't want to blindly crop a video without the video
knowing about it, or WebVTT subtitles and native controls would get
cropped
too.)
video already shows the video with correct aspect ratio; it has default
style object-fit:contain. img would be stretched, though. We could make
it object-fit:contain when it's the fullscreen element.
--
Simon Pieters
Opera Software
Re: [whatwg] Fullscreen revision I
On 21/10/2011 4:10 a.m., Glenn Maynard wrote: The current spec doesn't seem to allow asking permission to fullscreen in advance, since the fullscreen element is set synchronously. This should be supported; there are a lot of potential problems with the ask-after model and it shouldn't be the only model supported. I agree, the spec should definitely allow this. We could make requestFullScreen()'s entire body run in a synchronous section, after any permission has been granted? On Thu, Oct 20, 2011 at 6:59 AM, Anne van Kesterenann...@opera.com wrote: * requestFullscreen() can no longer be invoked when already in element fullscreen How do you change the fullscreenElement from one element to another without exiting fullscreen first? That seems important. If you have the fullscreen element as a generic container (div), you can insert your desired fullscreen element as the only child of the actual fullscreen element to get the swap effect. This won't work cross origin, so would prevent (for example) embedded YouTube videos from going fullscreen. I'd prefer for requestFullscreen() while fullscreen to just swap the fullscreen element. However, if we do end up not having requestFullscreen() while fullscreen swap the fullscreen element, then we need to ensure document.fullscreenEnabled returns false while any document is fullscreen. Otherwise video controls won't know to hide their (non-functioning) fullscreen buttons while their document/parent/ancestor documents are fullscreen. Chris Pearce.
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.
