[whatwg] Should <video controls> generate click events?
waldron.rick at gmail.com
Wed Aug 21 06:19:51 PDT 2013
On Wednesday, August 21, 2013, Simon Pieters wrote:
> 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
>>> 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
> 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 makes some good points. It seems there is a clear cost to this
>> 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,
>> 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
>> outside of the actual web content. Or you can just close the offending
>> 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()"
> 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?
> Simon Pieters
> Opera Software
More information about the whatwg