- From: Brian Chirls <brian.chirls@gmail.com>
- Date: Tue, 20 Aug 2013 23:37:46 -0400
- To: whatwg@lists.whatwg.org
> 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? > > 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. (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. Brian
Received on Wednesday, 21 August 2013 03:38:11 UTC