On Aug 5, 2010, at 9:24 PM, Robert O'Callahan wrote:
>
> It's probably worth having such an event, but there will be times when
> neither fullscreendenied or fullscreenchanged are fired. I hope authors don't
> write apps that break in such cases.
We definitely need some sort of event to indicate if fullscreen was successful
or not – not so that our apps don't break, but so we can notify the user of
failed functionality. Even a status property is insufficient as it will force
us to use a setInterval which seems hacky. And preferably, it would be good to
know the reason for the denial:
onFullscreenDenied = function(status){
if(status=="blocked by browser"){
alert("You need to change your browser's settings to use
fullscreen mode.");
}else if(status=="blocked by page"){
disableMyFullScreenButton();
alert("Sorry, fullscreen is not available.");
}
}
Regarding fullscreen elements: I appreciate the initiative, but I wonder if
it's necessary to allow fullscreen at the element level? I think Simon is
already pointing out potential gotchas. What exactly is the difference between
a fullscreen-element and a fullscreen-page that has an element in absolutely
position, top z-index, at 100% width and height? As a developer, after entering
fullscreen I could possibly do a fancy transition of the element to take up
100%. I have to assume this is what the UA would be doing in the background
anyway in order to keep the proper x/y coordinates.
Mike Wilcox
