W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

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

From: Brian Chirls <brian.chirls@gmail.com>
Date: Tue, 20 Aug 2013 23:37:46 -0400
Message-ID: <CAEWr9F_pUJq6Cc+cUNqnwrZ3o1nCNXLbAtDO0PgWo=Mkdyj4Qw@mail.gmail.com>
To: whatwg@lists.whatwg.org
> 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"
> <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

Please consider reverting this change.

Received on Wednesday, 21 August 2013 03:38:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC