- From: Xidorn Quan <notifications@github.com>
- Date: Thu, 18 May 2017 04:48:16 -0700
- To: whatwg/fullscreen <fullscreen@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fullscreen/issues/89/302381330@github.com>
I would never want to make prefixed and unprefixed events have different behavior. That sounds terribly complicated and I don't want to think about it unless it is proven to be necessary. > compatibility: likely, some websites that try to assume a non-prefix API will exist add the event listener to the element and simply change the event name. I definitively tried to do that once until @foolip told me I'm wrong; I don't think compat risk is high for this, because Gecko always uses this model, for quite long, and I don't recall we received compat issue due to this difference. Also as far as I can see, people usually do polyfill for fullscreen so they handle them together, rather than listening different prefixed event on different target. So I don't think this may be a real compat risk. @miketaylr, Blink and WebKit fires their prefixed fullscreen events (`webkitfullscreenchange`) on element, but Gecko fires that (`mozfullscreenchange`) on document. Have you seen compat issue due to this difference? > simplicity/less error prone: it will increase the chances of developers to trigger behaviour change when a specific element goes fullscreen instead of anything inside the document (ie. it is easy to not check which element is fullscreen when the document becomes fullscreen). This is probably reasonable. One question, though, where should the `fullscreenchange` event be fired for a change exiting fullscreen? Maybe the element which is exiting fullscreen? What if there are multiple elements all exiting fullscreen, because, for example, user preses esc, or an fullscreen iframe is kicked out from fullscreen by its parent? Currently, firing `fullscreenchange` for exiting fullscreen on element may make sense because there is hierarchy restriction in all current implementations that an element can enter fullscreen only if the current fullscreen element is its ancestor or null. It means you only need to fire the event on the current fullscreen element even if you are exiting multiple. But the latest spec has removed that restriction, which indicates that you may need to fire the event for every element, I mean every element in the old fullscreen stack, and all those events would bubble themselves up to the window. This would also be a behavior change for you. Maybe entering `fullscreenchange` to element but exiting `fullscreenchange` to document? I guess this behavior may be confusing, though... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fullscreen/issues/89#issuecomment-302381330
Received on Thursday, 18 May 2017 11:48:51 UTC