- From: Mike Wilcox <mike@mikewilcox.net>
- Date: Fri, 6 Aug 2010 08:57:05 -0500
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
Received on Friday, 6 August 2010 06:57:05 UTC