Re: [whatwg] Should <video controls> generate click events?

On Tue, Aug 20, 2013 at 7:55 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> On Wed, Aug 21, 2013 at 9:11 AM, Tab Atkins Jr. <jackalmage@gmail.com
> >wrote:
>
> > On Tue, Aug 20, 2013 at 3:46 PM, Silvia Pfeiffer
> > <silviapfeiffer1@gmail.com> wrote:
> > > On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> > > wrote:
> > >>
> > >> On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
> > >> <silviapfeiffer1@gmail.com> wrote:
> > >> > IMHO, the example that Philip provided in
> http://people.opera.com/~**
> > >> > philipj/click.html <http://people.opera.com/~philipj/click.html> is
> > not
> > >> > a
> > >> > realistic example of something a JS dev would do.
> > >>
> > >> Um, why not?  Clicking on the video to play/pause is a useful
> > >> behavior, which things like the Youtube player do.  Since <video>
> > >> elements don't generally do this, it seems reasonable that an author
> > >> could do pretty much exactly what Philip shows in his demo.
> > >
> > >
> > > YouTube has their own controls for this, so Philip's example does not
> > apply.
> > >
> > > What I'm saying is that the idea that the JS developer controls
> > pause/play
> > > as well as exposes <video controls> is a far-fetched example.
> >
> > Yes, Youtube has their own controls.  They have long-standing branding
> > that makes it worthwhile for them to roll their own.
> >
> > Why would I want to roll my own, though, when all I want is to add
> > click-to-play/pause?  That seems like a lot of difficult make-work.
> >
>
> Indeed. As a JS dev you make a choice: either you roll your own, or you
> don't.
>
> If you roll your own, you write the JS to handle the clicks from the
> controls and do video.pause() and video.play() yourself.
>
> If you don't roll your own, you write <video controls> and you expect the
> browser to handle pausing/playing. You don't do what Philip's demo (
> http://people.opera.com/~philipj/click.html) does: handle pause and play
> toggling in JS. Because the browser already does that for you.
>
> This is why I am saying: Philip's example is not a typical use case. It
> only happens when the developer made the choice to roll their own, but the
> user activates the default controls (e.g. through the context menu) as
> well. This can't happen on YouTube, because YouTube hide away the context
> menu on the video element. It may happen elsewhere (though I've just tried
> videoplayer.js and sublime video player and jwplayer and all of them have
> their video controls on top of the browser-provided ones, so you can't even
> get to them). It's this far-fetched use case that the patch is addressing.
>
> However, the patch has a wider implication: namely that the User agent will
> suppress all user interaction events from the browser-provided video
> controls. I.e. if the user clicks on the play button, no click event is
> raised on the video element and the elements that the video element is in.
> That's what Edward is objecting to - and I agree.
>
>

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

Received on Wednesday, 21 August 2013 00:45:24 UTC