Open miketaylr opened 9 years ago
@foolip and @upsuper probably need to weigh in here. If we do this we should add it to whatwg/fullscreen directly.
I don't really think the data from Chromium makes a lot of sense, because authors who use webkit-prefixed API likely also try other prefixed API at the same time, and usually also the unprefixed API. However this kind of data cannot be reflected from the Chromium use counter.
Given this reason, I don't think we should bother this a lot unless we do see web compat issue which affects a significant percentage of websites.
Since Edge has shipped unprefixed Fullscreen API as well as webkit prefixed ones in addition to their ms prefixed ones, it may provide more justification if they can share the use counter of the three API sets, if they have.
Until the unprefixed API ships in Blink, the use counter data merely reflects how often fullscreen is used, it's not a predictor of risk for eventually removing the prefixed API.
That being said, I'm not overly optimistic about being able to remove the prefixed API, mostly because of the change in capitalization, which must has resulted in some broken fallback code paths using requestFullScreen()
with a capital S.
Another formidable problem is that the webkitfullscreenchange
event target is the element, not the document. Because the element may have been removed, the logic for this is non-trivial. And the event bubbles.
All of that being said, if any browser vendor judges the case to be hopeless and wants a spec to proceed, then let's just do it.
I agree that it would be cool if Microsoft could share some data with us to help us understand the impact here. Maybe @jacobrossi or @dstorey can help?
(In the meantime, I'll dig through our collection of bugs to see how this affects Gecko. My instinct is that since we had our moz prefixed version, there won't be as many compat bugs compared to another browser that didn't ship a moz or webkit prefixed API.)
That being said, I'm not overly optimistic about being able to remove the prefixed API, mostly because of the change in capitalization, which must has resulted in some broken fallback code paths using requestFullScreen() with a capital S.
Yeah, agreed there. See https://bugzilla.mozilla.org/show_bug.cgi?id=743198#c5
(I wonder if it would be enough to spec the unprefixed capitalization aliases. I need to dig through some corpora to feel better about that.)
I'll check, but I don't know if we have existing use counters for this API. If not, we can do static analysis through our Bing crawler data. But that won't accurately tell you cases where they have both and are correctly using the unprefixed when available.
(not directly related to JS API) Reading http://caniuse.com/#feat=fullscreen
I see that the :fullscreen
seems to not be supported by all. WebKit world seems to support :full-screen
, I haven't tested yet, and I do not remember any compat issues about it, but I might not have been careful about it.
I think (but might be outdated) Chrome supports :-webkit-full-screen (still with prefix), but doesn't support backdrop. Opera used to support :fullscreen, but no longer does (Presto RIP)
That's right, Blink has only :-webkit-full-screen
, but when unprefixing it'll be :fullscreen
. See https://crbug.com/402378
See https://bugzilla.mozilla.org/show_bug.cgi?id=1407604#c2 has some problematic prefixed code on baidu.com.
If Gecko needs to implement this, I'd like to put it in the Fullscreen spec.
A complication for aliasing is that the prefixed APIs fire prefixed event. To make them true aliases would probably require adding these events to the table in https://dom.spec.whatwg.org/#concept-event-listener-invoke, and accepting that it's possible for element.requestFullscreen()
to end up firing the "webkitfullscreenchange" event.
The way this is handled in Chromium is that a fullscreen request is associated with a type (prefixed or not) and that bookkeeping is stored until it's time to fire events.
It doesn't seem that Gecko needs it so far?
Does it make sense to try removing it from Chromium as the next step? It would be great if we don't need to spec that additional complexity.
ok this was moved to Implement the new fullscreen API
- Use the top layer instead of clobbering styles
- Update UA styles
- Unprefix
- Use Promise-based APIs
- Fix minor spec divergences
Or decide if we need to.
According to this doc, Edge supports:
I looked at some of the Chromium use counter data here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1179457#c4
@dstorey wrote up a nice guide for updating here: http://generatedcontent.org/post/70347573294/is-your-fullscreen-api-code-up-to-date-find-out