[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>
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
More information about the whatwg
mailing list