On Tue, 18 Oct 2011 07:55:33 +0900, Darin Fisher <da...@chromium.org>
wrote:
Thanks for working on this spec! I have more questions, but I'll just
start with one. If enterFullscreen() is called when the browsing
context is
already being displayed fullscreen, what should happen? (It looks like
Safari 5.1 ignores the second call to webkitRequestFullScreen.)
Chris is suggesting this should move the "current fullscreen element"
around. A use case I can think of is where you have YouTube fullscreen
while browsing through videos and then want to highlight a particular
video. It does however generate quite a bit of complexity in edge cases
where you have a tree of Documents. In that case you need to find the
common ancestor of the current fullscreen element and the new fullscreen
element, make changes to the Documents on that path from current to new,
and dispatch events.
I also find it curious that there is a bit of a dead-time between the
request to enter fullscreen and the fullscreenchange event (nit:
"fullscreenchange" instead of "fullscreenchanged" to be consistent,
right?).
Agreed that it should be ending in "change".
It appears that JS cannot request to cancel out of fullscreen mode until
the fullscreenchange event is generated (i.e., until the fullscreen flag
is set). It could cause pain for developers if there is no guaranteed
response to enterFullscreen(). Did my request succeed, did it fail?
What happened?
The idea is to have an event, also asynchronous, that is dispatched when
the invocation did not succeed. Naming ideas so far: "fullscreendeny" and
"fullscreenerror".
--
Anne van Kesteren
http://annevankesteren.nl/
