On Wed, Aug 21, 2013 at 8:57 AM, Bob Lund <[email protected]> wrote:
> > > On 8/20/13 4:46 PM, "Silvia Pfeiffer" <[email protected]> wrote: > > >On Wed, Aug 21, 2013 at 8:32 AM, Tab Atkins Jr. > ><[email protected]>wrote: > > > >> On Tue, Aug 20, 2013 at 3:28 PM, Silvia Pfeiffer > >> <[email protected]> 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.
