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

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.

My suggestion was therefore to limit the patch to only apply when something
that the JS developer did not prepare for happens: namely the user
activates the browser-provided video controls (through the context menu).

Hope that clarifies my position.

Cheers,
Silvia.

Received on Tuesday, 20 August 2013 23:56:29 UTC