[whatwg] Should <video controls> generate click events?
waldron.rick at gmail.com
Tue Aug 20 16:11:53 PDT 2013
I'm wondering how this will effect interaction programming with Popcorn.js.
Sylvia, would you mind clearly defining the implications of this change,
given what you know about the project? Feel free to respond offline if you
feel that discussion would derail the subject.
On Tue, Aug 20, 2013 at 7:05 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:
> On Wed, Aug 21, 2013 at 8:57 AM, Bob Lund <B.Lund at cablelabs.com> wrote:
> > On 8/20/13 4:46 PM, "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com> wrote:
> > >On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr.
> > ><jackalmage at gmail.com>wrote:
> > >
> > >> On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer
> > >> <silviapfeiffer1 at gmail.com> wrote:
> > >> > IMHO, the example that Philip provided in
> > >> > 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
> > >as well as exposes <video controls> is a far-fetched example.
> > What about a Web page that uses JS to control pause/play/etc based on
> > external messages, say from a WebSocket? The sender in this case acts as
> > remote control.
> The patch applies only to the case where the user interacts with
> browser-provided controls on the video element. In your case, the JS dev
> would probably not use the @controls attribute on the video element, since
> the playback controls comes from the remote.
More information about the whatwg