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/CAM0wra-wf-V3dqc%2BXkVvX8HuuCCbNcLVBQ-6QGcgSQPerA6HgA%40mail.gmail.com.

Reply via email to