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

Simon Pieters simonp at opera.com
Wed Aug 21 03:59:27 PDT 2013

On Wed, 21 Aug 2013 05:37:46 +0200, Brian Chirls <brian.chirls at gmail.com>  

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

Just listen for the 'play', 'paused', 'seeked', 'ended' etc events for  
this. The change doesn't cripple the <video> API at all. Listening for  
'click' doesn't tell you whether the user clicked play or pause or seeked  
or none of those, so it's quite useless for that purpose.

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

That's not what the change is solving.

> (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.

It appears to me that you and Rick don't understand what the change does  
or what problem it was solving.

The problem was this: if you want to do something when a user clicks on a  
video but not when the user interacts with the native controls, you're  
basically out of luck.

<video controls onclick="if (paused) play(); else pause()"  

If the user clicks on the video's rendering area (i.e. outside the  
controls), this works as intended. However, if the user clicks on the  
native play/pause button, the video plays and then immediately pauses  
again. The change fixes this.

You are still notified by a 'play' event when the user clicks play on the  
native controls, so you can do something when the user clicks play on the  
native controls.

Simon Pieters
Opera Software

More information about the whatwg mailing list