[Bug 13276] Not allowing author or developer to have absolute control over media playback

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13276

--- Comment #14 from Shelley Powers <shelleyp@burningbird.net> 2011-07-18 13:35:34 UTC ---
(In reply to comment #13)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > Is the problem that a user can seek in the video or pause it? If so, what ill
> > > effects can come of that? When seeking, to the page it will just take a
> > > longer/shorter time before the ended event is fired, which should not typically
> > > be a problem. For playing/pausing, if the page assumed that it was in control,
> > > it wouldn't listen to the play/pause events at all, so it would presumably be
> > > just as if the network came to a halt.
> > > 
> > > Some details on "there may be a good reason" might help.
> > 
> > Seems comments 2 and 4 above.
> 
> So, "to allow playback options in the context menu when controls is not present
> also adds additional complexity to applications that provide custom controls.
> They not only have to listen for events triggered by their own custom controls,
> but also to handle events triggered by the menu."
> 
> As per above, it doesn't seem like this would actually be a problem. If a
> script assumes that it is the only thing in control of the video, then it won't
> be listening to seek events and the change in currentTime will most likely go
> unnoticed. Playing/pausing will appear mostly as if the browser had to stop for
> buffering.

Let's see if I can make this more clear:

This is about play and pause. If the play and pause options are in the context
menu, then when the user begins play or pause may now be happening in two
different places: in the web developer's custom control and in the context
menu. 

If the developer wants to do other activity based on a request to play the
resource, they now have to capture the play event on the video as well as
whatever events they need to capture in order to facilitate playing on their
custom controls. 

More importantly, if the web developer or author wants to control if and when
the user can start or pause playback, they have no way of doing so other than a
hack, such as a transparent div over the video element in order to "disable"
the context menu. 

If the web page author incorporates the video as part of the page presentation
and playback is integral to the page's purpose, they have no way to absolutely
control the playback because of the context menu option. 

> 
> Can you provide some real-world example of pages/scripts that don't intend the
> user to the play/pause/seek and that therefore makes assumptions that will
> break the page/script if the user actually does?
>

Consider a video with three buttons underneath: play, pause, and stop. Playback
is controlled by the buttons. The code for the button's click event handler not
only plays or pauses the video, but also enables and disables the buttons based
on what action the user can take next. When the user clicks the play button,
the stop and pause buttons are enabled, the play is disabled, and so on.

Instead of clicking the buttons, the user clicks the context menu play option.

Now, the developer not only has to listen for the button click events, but also
the video play and pause events. They can code around the issue, except for one
thing: they can't control the options that show in the context menu.

The custom control doesn't have a fullscreen option. The web page developer
doesn't want the video to play fullscreen. Agree or not, the web page developer
doesn't want the video to play fullscreen. 

The user agent provides fullscreen as an option in the context menu. There is
no way for the developer to "code around" this problem, other than using a
kludge such as a transparent div overlay over the video element.

The specification states that the controls attribute means that the web page
author/developer is not providing a custom control. This is a bad way of
defining this attribute. There may be more than one reason why a person would
deliberately not add the controls attribute to the page--it's not up to the
HTML5 specification to determine intent, only to describe consistent functional
behavior. 

It could be that when the author or developer leaves off the controls
attribute, they mean leave off the controls, period. For whatever reason. 


> If more pages start to use audio/video and try hard to not make the user be
> able to interrupt it, then we're just going to add page-wide UI to pause or
> mute all media elements on a page. Why would we ever want a page to be able to
> override a user in these decisions?
> 

Why would the HTML5 specification override the web page author and developer's
wishes? They don't matter? Are web developers an encumbrance to be worked
around?

We're forcing developers into using kludges because we're not giving developers
options to completely control the media elements. 

> (In reply to comment #10)
> > And I'll ask in return: what was the technical reason for removing playback
> > control for the media elements from the web page author/developer?
> 
> Do you mean why the controls attribute was omitted? Usually, because they look
> different in all UIs and don't match the design of the embedding page. If some
> page author thought it would also guarantee that the user couldn't pause their
> video, they were wrong.

No, why was it decided that web developers cannot have complete control over
the media element's playback? What was the technical reason to remove such
control from the web developer?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 18 July 2011 13:35:43 UTC