[whatwg] Should <video controls> generate click events?

[Brian Chirls]

> Thank you, this is the clarification I was looking for in my previous
> inquiries. Given this explanation, I absolutely object to any change (such
> as this) that will effectively cripple the interaction "programmability"
of
> <video> elements. There are commercial products that have been developed
> and are being developed that rely on the ability to add listeners for
> events that occur on the <video controls> as part of reach and engagement
> data collection, eg. Did the user click the Play button on the video and
> watch it all the way through? Did they click Pause? Did they drag to seek?
>
> Rick

Rick makes some good points. It seems there is a clear cost to this change,
but I'm afraid that there is little benefit, since it won't prevent the
proposed control-breaking scenario anyway.

It seems to me that danger of Mr. Jägenstedt's proposed scenario is that
the user is annoyed by being forced to watch and/or listen to a piece of
media against his/her will. (As for preventing them from playing something
they want to play, if the creator of a web page didn't want you to watch
something, they wouldn't put it on a web page.) But even if click events
are blocked, there are many similarly annoying workarounds. For example...

- Play video or audio with no controls at all, or even unattached to the
DOM tree
- Show the controls but block them with an absolute-positioned, transparent
div or image
- Play a video (with element in memory only, not on document) and draw it
to a canvas. The user will have no way to make controls show up at all.
- Render fake media controls using images or a canvas on top of the video

I think a more effective and useful approach, which does not require
removing existing API features, would be for browsers to indicate which
tabs are currently playing media and provide a UI for tab-wide mute that is
outside of the actual web content. Or you can just close the offending
tab/window.

Please consider reverting this change.

Brian