Richard Bushell

Logically I have implemented this locally using:- ``` addEventListener: (element, type, handler, options) => element.addEventListener(vendor[key[type]], handler, options) ``` BUT I presume introducing a new initial ELEMENT parameter would represent a...

I agree that it makes sense too, and your solution seems the best way of implementing this. Are you OK to make your suggested revisions directly?

Apologies, I don't know if you are taking comments from third-parties, but +1 for: element.requestFullscreen({ replace: true }) document.exitFullscreen({ fully: true }) or similar functionality. And maybe a readable array...

@foolip No problem signing the agreement if any ideas or solutions are implemented into the spec. The fundamantal problem is that, to my understanding, the Browser UA has information about...

@foolip our use case is as of web developers, but in working with current implementation briefs for websites that perform as single-page web apps (often designed to be viewed in...

@upsuper - Thanks for your thoughts. I genuinely hadn't considered good old CSS as a way of accessing the fullscreen stack elements via JavaScript. Yes, knowledge of the ORDER of...

@upsuper - I have tested your proposed CSS selector workaround, but unfortunately the :fullscreen pseudo-class seems to only ever match ONE element (the current fullscreenElement at the top of the...

@upsuper - You are right! Apologies, I didn't re-run my own initial test on Firefox after I made a final tweak earlier to the code to handle all prefixed and...

@upsuper Thanks very much, crystal clear.

I have filed bugs with Chromium and Webkit for the Fullscreen API spec non-compliance issues mentioned above. I have one more question too in regard to document.exitFullscreen({ fully: true })....