- From: liberato-at-chromium <notifications@github.com>
- Date: Wed, 28 Jul 2021 19:35:17 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Thursday, 29 July 2021 02:35:30 UTC
Hello, all. First post, please point out but forgive any rough edges in my etiquette. :) Also, for full disclosure (and in case my username isn't clear!), I work on chrome as my day job. Anyway, this option seems, to me, like a way to allow sites to continue to use native controls rather than custom controls. That seems like a win for the user. In particular, if a site wants to prevent download / fullscreen / mute / whatever, it can always do so simply by not requesting the native controls. Then the user is more or less stuck with whatever the site provides via js. Even providing the user with the option to enable the default controls isn't guaranteed to work; it's easy for the site to block them. On the other hand, if the site is willing to use the native controls, but prefers turning some of the features off by default, then it seems like a solid win for the user over the alternative. The UA has enough information to let the user override the site's preference, and the controls should continue to work the way they always do. Whether the site's goal is pseudo-DRM or just space management on a tight layout, I'm not sure it matters. "native" vs "custom" seems like the key difference to my (admittedly) untrained eye. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/643#issuecomment-888752788
Received on Thursday, 29 July 2021 02:35:30 UTC