This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13624 - <video> The pause-on-exit flag should lead to the paused for user interaction state
Summary: <video> The pause-on-exit flag should lead to the paused for user interaction...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-03 19:37 UTC by Masatomo Kobayashi
Modified: 2013-01-31 16:37 UTC (History)
11 users (show)

See Also:


Attachments

Description Masatomo Kobayashi 2011-08-03 19:37:02 UTC
Section affected:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#playing-the-media-resource

In the current cue processing algorithm, a cue whose pause-on-exit flag is set causes the normal paused state when the cue stops being relevant. However, since the pause-on-exit flag can be used only by the system for a certain special purpose, this flag should cause the "paused for user interaction" state rather than the normal paused state, so that the state can be controlled only through a special interface, not thorough the normal pause/resume interface.

For example, for extended video descriptions which is a promising use case of the pause-on-exit flag as discussed in the a11y task force ( http://lists.w3.org/Archives/Public/public-html-a11y/2011Jun/0065.html ), the paused state needs to be controlled through accessibility APIs while it should not be affected by the user's pause/resume operations.
Comment 1 Frank Olivier 2011-08-03 20:28:28 UTC
I don't see the need for this - What is the use case that requires adding another (secondary?) pause state? It looks like the current spec text at http://dev.w3.org/html5/spec/Overview.html#playing-the-media-resource will allow the user and the author to control the content with the (single) pause mechanism.

The author can infer "paused for user interaction" when the cue exit event fires.
Comment 2 Ian 'Hixie' Hickson 2011-08-19 19:52:17 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The paused-for-user-interaction state is for states where the video is still technically playing (i.e. hitting "play" will not change anything). When you hit a pause-on-exit cue, on the other hand, it does a real pause as if the user hit the pause button (so hitting play would resume).
Comment 3 Silvia Pfeiffer 2011-08-20 03:19:47 UTC
(In reply to comment #2)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: The paused-for-user-interaction state is for states where the video
> is still technically playing (i.e. hitting "play" will not change anything).
> When you hit a pause-on-exit cue, on the other hand, it does a real pause as if
> the user hit the pause button (so hitting play would resume).

So, the paused-for-user-interaction state is only used when, e.g. the video goes into network buffering mode because it has no further data to play?

I am wondering whether, when the screen reader asks the browser to pause with the playback of a video and wait until a text cues has finished reading a description, the UA should really continue to be in playing state and not throw the onpause event and onplay event, because the pausing has been created by the UA internally. OTOH, I guess the pause-on-exit cue does not have to be used for extended text descriptions to enforce the "pausing" behaviour.