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

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

           Summary: Not allowing author or developer to have absolute
                    control over media playback
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: shelleyp@burningbird.net
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


Currently as the specification is written, there is no way for a web page
author or developer to have absolute control over audio or video playback with
the audio or video elements. 

There may be a good reason why the author or developer wants to be able to
control, absolutely, when an audio or video file is played. They playback may
be part of a presentation or a game or for some other reason. 

Regardless of whether they have a "good" reason or not, they should be able to
have absolute control of the playback of the media.

Currently if you don't add the controls attribute to the video or audio
element, the control UI is not displayed. However, the ability to control the
media playback still exists as functions exposed in the element's context menu. 

I understand that there's reluctance to give authors and developers this level
of control. However, not providing the author and developer finer control over
playback can't be stopped completely, anyway. All that will happen is the
authors and developers will have to use hacks to work around this limitation.

The author and developer can control audio playback by removing the audio
element from display for audio files. This isn't a problem, but the video
element playback is.

Authors and developers who want to have total control over a video file will
create canvas elements and draw the video into these elements while hiding the
video element. 

This may seem like an acceptable alternative, but it requires extra machine
resources, and playback may not be as smooth, depending on machine resources.
It's an ugly kludge but it is the only way for an author or editor to have
complete control over the playback of the video. 

Either there needs to be an additional refinement to the controls attribute, so
that a developer or author can also choose to remove playback functionality
from the context menu in addition to the UI. Or the addition of the playback
functionality to the context menu should be disabled when the controls
attribute is not present on the element.

-- 
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 Friday, 15 July 2011 21:08:20 UTC