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 13437 - Editorial changes to The Video element (5 of 5)
Summary: Editorial changes to The Video element (5 of 5)
Status: RESOLVED MOVED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Léonie Watson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.w3.org/TR/2011/WD-html5-20...
Whiteboard:
Keywords: a11y, a11ytf, media
Depends on:
Blocks:
 
Reported: 2011-07-28 21:53 UTC by John Foliot
Modified: 2016-04-07 15:39 UTC (History)
13 users (show)

See Also:


Attachments

Description John Foliot 2011-07-28 21:53:41 UTC
current text:

"User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window). As for the other user interface features, controls to enable this should not interfere with the page's normal rendering unless the user agent is exposing a user interface. In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent."

recommended change:

"User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window).  Captions, subtitles or other additional visual tracks must remain available and visible at all times.  As for the other user interface features, controls to enable this should not interfere with the page's normal rendering unless the user agent is exposing a user interface. In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent."

Filed on behalf of the a11yTF
Comment 1 Philip Jägenstedt 2011-07-29 09:59:41 UTC
Given that the layout of additional video tracks is controlled by the page author, any suggestion of how to actually fulfill this requirement?
Comment 2 Michael[tm] Smith 2011-08-04 05:16:19 UTC
mass-move component to LC1
Comment 3 Anne 2011-08-15 15:57:05 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: Please address comment 1 and in addition if you were to reopen please clearly state the issue rather than a text substitution.
Comment 4 Charles McCathieNevile 2014-02-13 16:54:19 UTC
Considered at HTML Accessibility Task Force Meeting today. The sense of the meeting was that we may want to keep the non-editorial requirement that is part of this bug, ensuring that controls to activate accessibility features such as extra tracks are always available. There was little support for the explicit requirement that they remain *visible*, but there is an issue of dicsoverability - something available that the user cannot find is of very limited value in solving the problem it is meant to address...

http://www.w3.org/2014/02/13-html-a11y-minutes.html#item07
Comment 5 Silvia Pfeiffer 2014-02-14 00:14:51 UTC
Is your point that: if the video is displayed in a different manner (e.g. full-screen or independent window), any active captions need to continue to be displayed?
Comment 6 Silvia Pfeiffer 2014-02-14 00:16:19 UTC
Or is it about the controls? (It seems to me that the original bug was for the display of the text, not the controls.)
Comment 7 Charles McCathieNevile 2014-02-14 11:06:12 UTC
The original bug as I read it (I don't have the history that produced it, unfortunately), was about the controls.

Which need to be available.

But I see your point about captions etc actually being visible, and yes I think if they are being rendered they need to remain visible in a transition.

Where they are being rendered over the top of the video, this seems only mildly complicated. But where they are being rendered in a separate region, e.g. alongside, I think this is tricky. Is there a way to identify where such things are being rendered? (It must be possible in principle, since they are actually being rendered into *some* space. What I don't know is how difficult it is in practice…)
Comment 8 Silvia Pfeiffer 2014-02-15 02:33:05 UTC
John's proposed change was explicitly: "Captions, subtitles or other additional visual tracks must remain available and visible at all times."

That doesn't indicate "controls" to me, so I assume you want to extend the bug to both: the display of captions as well as the availability of controls. Fair enough.

Charles wrote:
> Where they are being rendered over the top of the video, this seems only
> mildly complicated. But where they are being rendered in a separate region,
> e.g. alongside, I think this is tricky. Is there a way to identify where such
> things are being rendered? (It must be possible in principle, since they are
> actually being rendered into *some* space. What I don't know is how difficult
> it is in practice…)

The browser never renders captions anywhere but over the top of the video. So we're already covered.


So, addressing the issues:


1. Availability of captions when rendered "in manners more suitable to the user"

The section in question is about the video element and how the video is rendered within the width and height of the video element. The relevant paragraph merely states that "User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window)." Neither this paragraph, nor this section say or change anything about the rendering of captions. This is simply not the right place to talk about caption rendering.

In particular, any caption rendering is already included earlier through the statement:

"The video element also represents any text track cues whose text track cue active flag is set and whose text track is in the showing mode, and any audio from the media resource, at the current playback position."

How that happens is specified in the "time marches on" algorithm of "4.7.10.8 Playing the media resource". There is no exclusion specified there for where the video is rendered, so all cases are included.



2. Availability of controls

I could imagine extending this sentence:
"In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent."

to include mention of "change the display of closed captions or embedded sign-language tracks" in the e.g. list.

Even so: all this is covered much better and in much more detail at
http://www.w3.org/TR/html5/embedded-content-0.html#attr-media-controls
and it seems strange to repeat this all again.


Have you got any examples where this has been an issue? All UAs that I have experienced do the right thing with video in full screen displaying captions and controls.
Comment 9 Silvia Pfeiffer 2015-07-11 01:48:03 UTC
Closing this again - there has been insufficient information what problem this bug is trying to get solved.
Comment 10 Charles McCathieNevile 2016-03-03 15:20:41 UTC
Léonie to figure this out and move to github
Comment 11 Léonie Watson 2016-04-07 15:39:22 UTC
Migrated to HTML:
https://github.com/w3c/html/issues/173