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