W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2011

[whatwg] Fullscreen and event dispatch

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 25 Oct 2011 12:57:34 +0900
Message-ID: <op.v3v2l8gb64w2qv@annevk-macbookpro.local>
On Mon, 24 Oct 2011 20:42:18 +0900, Jo?o Eiras <joaoe at 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/
Received on Monday, 24 October 2011 20:57:34 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:37 UTC