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

[Rick Waldron]

On Wednesday, August 21, 2013, Simon Pieters wrote:

> On Wed, 21 Aug 2013 05:37:46 +0200, Brian Chirls <brian.chirls at 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.



Are you suggesting that Silvia's earlier description of the
implications was wrong?


> 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.
>
>
Ok, I appreciate this correction, but this is still a poor solution. How do
get notified of clicks on the controls?

Rick




> --
> Simon Pieters
> Opera Software
>