- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 21 Aug 2013 09:05:07 +1000
- To: Bob Lund <B.Lund@cablelabs.com>
- Cc: WHAT Working Group Mailing List <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Edward O'Connor <eoconnor@apple.com>
On Wed, Aug 21, 2013 at 8:57 AM, Bob Lund <B.Lund@cablelabs.com> wrote: > > > On 8/20/13 4: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. > > 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 a > 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. Silvia.
Received on Tuesday, 20 August 2013 23:05:58 UTC