Good point about the most used APIs being the boolean properties! The APIs are now only aliases for the standard non-prefixed fullscreen APIs (see this code for the current implementation <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/media/html_video_element.cc;l=418;drc=25705537e65f031d28c1a531046b11914055b7e6>), and therefore aren't much of a burden to maintain.
I opened a WebKit standards position here: https://github.com/WebKit/standards-positions/issues/306 I unfortunately do not have access to edit the listed ChromeStatus entry, and the current owner no longer works on Chromium. Should I create a new feature (titled "Deprecation of HTMLVideoElement-specific Prefixed Fullscreen API")? I think the current ChromeStatus entry also covers this API <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/fullscreen/element_fullscreen.idl;l=19;drc=047c7dc4ee1ce908d7fea38ca063fa2f80f92c77> which I am not trying to deprecate in this Intent. What's a reasonable sample size of HTTP Archive sites to audit? Should this be a complement/precursor to the proposed Deprecation Trial, or would this sampling be enough? Thank you, Thomas On Sun, Jan 21, 2024 at 7:56 PM Domenic Denicola <dome...@chromium.org> wrote: > It would be very exciting to clean this up! I have some questions that > might help clarify the cost-benefit analysis. > > On Sat, Jan 20, 2024 at 6:43 AM Thomas Guilbert <tguilb...@chromium.org> > wrote: > >> Contact emails >> >> tguilb...@chromium.org >> >> Explainer >> >> None >> >> Specification >> >> https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled >> >> Summary >> There was an attempt in 2014 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Bxe7DnDVRZ0/m/5K61HQPrNK4J> >> to deprecate and remove the HTMLVideoElement-specific Prefixed Fullscreen >> APIs. This meant removing the following APIs from HTMLVideoElement: >> >> readonly attribute boolean webkitSupportsFullscreen; >> readonly attribute boolean webkitDisplayingFullscreen; >> void webkitEnterFullscreen(); >> void webkitExitFullscreen(); >> // Note the different capitalization of the "S" in FullScreen. >> void webkitEnterFullScreen(); >> void webkitExitFullScreen(); >> >> > How "expensive" is it to support these APIs? For example, if some of them > are just straight-up aliases of standard APIs, then the benefit of removal > might be low. Whereas if, for example, these prefixed "enter fullscreen" > APIs have different behavior than the standardized requestFullscreen() API, > then supporting the prefixed variants feels expensive, and getting rid of > them is more worthwhile. > > >> The overall usage of these APIs is low, and has trended downwards over >> time. Here are the latest usage numbers, as a % of total page loads: >> >> PrefixedVideoSupportsFullscreen: 0.025% >> PrefixedVideoDisplayingFullscreen: 0.082% >> PrefixedVideoEnterFullscreen: 0.001% >> PrefixedVideoExitFullscreen: 0.010% >> PrefixedVideoEnterFullScreen: 0.001% >> PrefixedVideoExitFullScreen: 0.000% >> >> >> > It's notable that the highest counters are for the boolean properties. > That makes this slightly less risky, because removing them will cause them > to return `undefined`, so code like `if (videoEl.webkitSupportsFullscreen) > { ... }` will just return false, instead of throwing an exception or > similar. > > >> There has been an unfortunate uptick in the past 2 years for the two >> following APIs, which means that it's best to remove them now, before they >> see a wider adoption. These numbers might be going up because the prefixed >> APIs are also present on iOS. >> >> https://chromestatus.com/metrics/feature/timeline/popularity/166 >> https://chromestatus.com/metrics/feature/timeline/popularity/167 >> > > I was going to ask about if there are popular sites or libraries using > these, but I found some discussion of that in the bug > <https://bugs.chromium.org/p/chromium/issues/detail?id=346236#c74>. It > seems like there's a hope that some sites already have fallbacks in place > to the standardized APIs, but it's not quite clear. Maybe you could try > running a build of Chromium with the prefixed APIs disabled on a random > sampling of the HTTP Archive sites, and reporting back on if the user > experience changes or new errors show up in the JS console? That could give > us more confidence in the removal. > > >> >> There is an alternative set of APIs supported by all browsers that web >> authors can use. >> >> The full history of the removal attempt is here: crbug.com/346236 >> >> >> Goals for experimentation >> >> The primary goal of the deprecation trial is to reduce the amount of >> broken user-visible experiences as the prefixed fullscreen APIs are >> removed, and to give time to web authors to transition to the modern API >> (which has been available for 5 years). >> >> >> The un-prefixed fullscreen APIs have been available since Chrome M71. >> >> Experiment timeline >> >> TBD, with a proposed 3 months duration >> >> Blink component >> >> Blink>Fullscreen >> Blink>Media>Video >> >> TAG review >> >> None >> >> TAG review status >> >> Not applicable >> >> Risks >> Interoperability and Compatibility >> >> Web Compatibility: >> >> Removing non-standard APIs should overall help web compatibility, and >> encourage web authors to use the unprefixed APIs. Some experiences might be >> broken by this change, thus justifying this deprecation trial. The API has >> been deprecated for a significant amount of time however, and usage has >> gone down. >> >> This would only be an issue for websites that *only* support the prefixed >> APIs. >> >> >> Interoperability: >> >> >> All browsers have shipped the new APIs, most of them using an unprefixed >> version (Safari on iOS being the only remaining prefixed-only API). See >> also >> https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen#browser_compatibility >> > > Based on the WPT results > <https://wpt.fyi/results/fullscreen/api/historical.html?label=master&label=experimental&aligned&q=%2Ffullscreen%2Fapi%2Fhistorical.html>, > Gecko supports none of the prefixed APIs, and WebKit supports all of them. > I think this is worth noting in the ChromeStatus entry. (Although it's not > an official signal, so leave the dropdown at "No signals".) > > Given this, filing a standards-positions issue on WebKit to get their take > on the deprecation might be a good idea. Sometimes those discussions end up > going in surprising directions; see e.g. this request for a position on > the deprecation of mutation events > <https://github.com/WebKit/standards-positions/issues/192>. > > (Gecko also has their own, smaller set of prefixed APIs. But it's not as > relevant to this intent about the webkit-prefixed ones.) > > >> >> Gecko: >> >> >> WebKit: >> >> Web developers: >> >> Other signals: >> >> Activation >> >> Impact on the Ads ecosystem: >> >> N/A >> >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> Potentially. The deprecation trial should give a heads up and appropriate >> time for apps to switch over to the unprefixed APIs. >> >> >> >> Ongoing technical constraints >> >> None >> >> >> Debuggability >> >> N/A >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)? >> >> Yes - the prefixed API will be removed across all platforms. >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> Yes >> >> WPTs testing the prefixes are removed: >> https://github.com/web-platform-tests/wpt/blob/master/fullscreen/api/historical.html >> >> WPTs testing the new API: >> https://github.com/web-platform-tests/wpt/tree/master/fullscreen/api >> >> >> Flag name on chrome://flags >> >> None >> >> Finch feature name >> >> PrefixedVideoFullscreen >> >> Non-finch justification >> >> None >> >> Requires code in //chrome? >> >> False >> >> Launch bug >> >> None >> >> Estimated milestones >> >> DevTrial on desktop >> >> 123 >> >> DevTrial on Android >> >> 123 >> >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5259513871466496 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoa373%3Dnxuc%2BTe_h9e0WdS53_oAyUEa%2B4j0v2xWgJ2MFcw%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoa373%3Dnxuc%2BTe_h9e0WdS53_oAyUEa%2B4j0v2xWgJ2MFcw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoYaoWL2N6sfjawE-X7DE46BbuDqRK0DFzgO1ayS5Di8Vw%40mail.gmail.com.
