On Tue, Jan 23, 2024 at 2:31 AM Domenic Denicola <dome...@chromium.org>
wrote:

>
>
> On Tue, Jan 23, 2024 at 7:55 AM Thomas Guilbert <tguilb...@chromium.org>
> wrote:
>
>> 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.
>>
>
> Yeah, I think a new feature is a good idea. The old feature seems to be
> for the *addition* of the prefixed fullscreen API properties back in
> Chrome 15, whereas a *deprecation/removal* has a different set of fields,
> if I understand correctly.
>
>
>>
>> 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?
>>
>
> I recall +Philip Jägenstedt <foo...@chromium.org> having done some
> computations in the past based on what would actually be statistically
> significant. But, I couldn't find them in this documentation
> <https://www.chromium.org/blink/platform-predictability/compat-tools/> (or
> the linked document
> <https://docs.google.com/document/d/1cpjWFoXBiuFYI4zb9I7wHs7uYZ0ntbOgLwH-mgqXdEM/edit#heading=h.1m1gg72jnnrt>).
> So, I'll just state that I would be happy with 20 sites.
>

You're probably thinking of these threads:
https://groups.google.com/a/chromium.org/g/blink-dev/c/gIyvMw0n2qw/m/CC7RlhguAgAJ
https://groups.google.com/a/chromium.org/g/blink-dev/c/V7q43bgutbo/m/GpJogpw4AgAJ

Checking 20 sites at random and finding no breakage gives us 95% confidence
that the true occurence of broken sites is no more than ~17%. Checking 40
reduces that to ~9%. (Based on
https://sample-size.net/confidence-interval-proportion/.) If the set we're
sampling from is sites that hit a use counter, then it says something about
the real risk of breaking that code path.

Checking 20 like Thomas did seems enough to me, we're starting from a low
risk and just want to know if breakage is common or not. It seems to not be
common even on sites that use the APIs.

-- 
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/CAARdPYd7X6deDxQPywsiGJ3W%3DQPhTuPL8jQaB860SXZB0hxYVQ%40mail.gmail.com.

Reply via email to