Re: [w3ctag/design-reviews] HTMLMediaElement controlsList (#643)

Hello TAG! The TL;DR of my feedback is that the primary use case for this feature (`"nodownload"`) is Chromium-specific, and that ancillary use cases (`"nofullscreen"`, hypothetical future controls) are both user-hostile and unnecessary.

* `"nodownload"`: The explicit use case is to remove only button from the default media controls provided by Chromium and only by Chromium.  If this were its own attribute, it could be safely ignored by other UAs–much like the `playsinline` attribute–but as the current proposal requires a new, separate attribute, the primary, Chromium-only use case does not itself justify the addition of `controlsList`.
* `"nofullscreen"`: This use case is, IMO, both user hostile and unnecessary. The justifications provided for blocking the ability for users to take a video (with controls) into a fullscreen mode are all user-hostile. Sites that really, really want to block fullscreen can rely on UAs adhering to the existing `"fullscreen"` Feature Policy.
* hypothetical future additions: This is the opposite of a use case, IMO, and "making it easier to standardize new tokens in the future" begs the question that those additions would be useful, desirable, and not user hostile in the first place. On the contrary, for each of the existing controls in WebKit's native controls, selectively removing those controls would be user hostile: we do not want sites to easily, e.g., prevent users from muting audible content, prevent users from pausing content, prevent users from skipping ahead or backwards, or prevent users from entering picture-in-picture mode.

Since the existing use cases are either UA-specific, user hostile, and/or unnecessary, and hypothetical future use cases are both hypothetical and hypothetically user hostile, we do not support the `controlsList` proposal.

-- 
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-884387426

Received on Wednesday, 21 July 2021 18:09:28 UTC