[whatwg] Feedback on the Mozilla FullScreen API proposal

[Mike Wilcox]

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