- From: Rick Waldron <waldron.rick@gmail.com>
- Date: Wed, 21 Aug 2013 09:19:51 -0400
- To: Simon Pieters <simonp@opera.com>
- Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Brian Chirls <brian.chirls@gmail.com>
On Wednesday, August 21, 2013, Simon Pieters wrote: > 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. 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 >
Received on Wednesday, 21 August 2013 13:20:22 UTC