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

On Tue, Aug 20, 2013 at 7:11 PM, 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.
>

Firefox actually implements click-to-play <video> by default. It's
unfortunate and all <video> interaction projects that I've worked on
directly or consulted for have been forced to include video surface click
-> event.preventDefault() calls to stop the behaviour. This may be
irrelevant to the current discussion, but I'm trying to get a better
understanding for the behavioural changes implied by this spec update, so
correction is highly desirable.

Rick

Received on Tuesday, 20 August 2013 23:19:06 UTC