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

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

>> 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()"  
src=foobar></video>

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

Received on Wednesday, 21 August 2013 10:54:16 UTC