whatwg / compat

Compatibility Standard
https://compat.spec.whatwg.org/
Other
116 stars 41 forks source link

Spec webkit fullscreen API properties #11

Open miketaylr opened 9 years ago

miketaylr commented 9 years ago

Or decide if we need to.

According to this doc, Edge supports:

onwebkitfullscreenchange
onwebkitfullscreenerror
webkitCancelFullScreen
webkitCurrentFullScreenElement
webkitDisplayingFullscreen
webkitEnterFullScreen
webkitExitFullScreen
webkitFullscreenElement
webkitFullscreenEnabled
webkitIsFullScreen
webkitRequestFullScreen
webkitSupportsFullscreen

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

annevk commented 9 years ago

@foolip and @upsuper probably need to weigh in here. If we do this we should add it to whatwg/fullscreen directly.

upsuper commented 9 years ago

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.

foolip commented 9 years ago

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.

miketaylr commented 9 years ago

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

miketaylr commented 9 years ago

(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.)

jacobrossi commented 9 years ago

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.

karlcow commented 9 years ago

(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.

dstorey commented 9 years ago

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)

foolip commented 9 years ago

That's right, Blink has only :-webkit-full-screen, but when unprefixing it'll be :fullscreen. See https://crbug.com/402378

miketaylr commented 7 years ago

See https://bugzilla.mozilla.org/show_bug.cgi?id=1407604#c2 has some problematic prefixed code on baidu.com.

foolip commented 7 years ago

If Gecko needs to implement this, I'd like to put it in the Fullscreen spec.

karlcow commented 2 years ago

See https://bugs.webkit.org/show_bug.cgi?id=242930

foolip commented 2 years ago

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.

foolip commented 2 years ago

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.

upsuper commented 2 years ago

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.

karlcow commented 2 years ago

See https://bugs.webkit.org/show_bug.cgi?id=242930

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