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 12405 - <video> There's a problem with overlaying a sign-language video and using native controls, because the overlaid video overlaps the native controls
Summary: <video> There's a problem with overlaying a sign-language video and using nat...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords: a11y, media
Depends on:
Blocks:
 
Reported: 2011-03-31 07:23 UTC by contributor
Modified: 2011-09-04 17:49 UTC (History)
10 users (show)

See Also:


Attachments

Description contributor 2011-03-31 07:23:54 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/video.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#assigning-a-media-controller-declaratively

Comment:
There's a problem with overlaying a sign-language video and using native
controls, because the overlaid video overlaps the native controls

Posted from: 85.227.157.81 by simonp@opera.com
User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.8.119 Version/11.10
Comment 1 Martin Kliehm 2011-05-10 15:27:17 UTC
The bug-triage sub-team doesn't believe it is already possible to have a sign language video as alternate track for video, therefore this is not TF priority at the moment.
Comment 2 Silvia Pfeiffer 2011-05-10 22:55:15 UTC
Actually, the example at http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#assigning-a-media-controller-declaratively shows how to do this.

As long as you only give a @controls attribute to the "main" video element and not to the video element that holds the sign language, you are set. Those controls control all elements in the media group.
Comment 3 Silvia Pfeiffer 2011-05-11 01:50:29 UTC
(In reply to comment #2)
> Actually, the example at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#assigning-a-media-controller-declaratively
> shows how to do this.
> 
> As long as you only give a @controls attribute to the "main" video element and
> not to the video element that holds the sign language, you are set. Those
> controls control all elements in the media group.

Correction: I think I only just understood your problem. :-)

You probably shouldn't position the sign language video at bottom:0, but something a little higher to avoid the controls. Maybe bottom:10% or the maximum height of all browsers' controls.
Comment 4 Simon Pieters 2011-05-11 07:32:34 UTC
You can't know what the height of the controls are. It could vary based on browser skin. The controls might not be at the bottom in the first place. You can't know for sure that you haven't overlapped the native controls.

What would be better is either a way to make the controls render on top of other elements. (A few years ago I thought maybe this should be the default behavior even.)

I can also see a case for pages wanting to reposition things when the controls are visible. I recall a mozilla demo with custom captions that repositioned them on :hover. Maybe a way to ask for position and size for the custom controls, and maybe events controlsshow and controlshide.
Comment 5 Ian 'Hixie' Hickson 2011-06-16 21:30:02 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: This isn't a problem specific to sign language tracks — it applies to everything that might be overlaid on the video, if the UA renders the controls at the z-index of the video element.

So the UA shouldn't do that. :-)
Comment 6 Simon Pieters 2011-06-17 13:49:25 UTC
The rendering section doesn't say to use a different z-index for the native controls.
Comment 7 Michael[tm] Smith 2011-08-04 05:03:54 UTC
mass-moved component to LC1
Comment 8 Ian 'Hixie' Hickson 2011-08-11 02:40:59 UTC
It doesn't say _what_ to do with the native controls. That's up to the UA. It could be an entirely separate window, for instance.

Anyway, if the author is positioning the sign-language tracks, then he's almost certainly also going to want to do his own controls. Who's going to have time to do sign-language tracks but not custom UI? If he's not positioning the sign-language tracks (e.g. just putting them side-by-side) then it's not an issue.

I suppose I could mention the issue in the rendering section, so that implementors who read that section are aware of it, would that be satisfactory?
Comment 9 Simon Pieters 2011-08-11 08:37:04 UTC
(In reply to comment #8)
> It doesn't say _what_ to do with the native controls. That's up to the UA. It
> could be an entirely separate window, for instance.

It says

"Whether a video element is exposing a user interface is not expected to affect the size of the rendering; controls are expected to be overlaid with the page content without causing any layout changes, and are expected to disappear when the user does not need them."

What "overlaid with the page content" means is a bit unclear.

> Anyway, if the author is positioning the sign-language tracks, then he's almost
> certainly also going to want to do his own controls.

I don't see how that follows.

> Who's going to have time
> to do sign-language tracks but not custom UI?

Maybe somebody who prioritizes accessibility over custom UI? The native controls give accessibility for free (assuming the browser got it right). Getting accessibility right with custom controls is not for free.

> If he's not positioning the
> sign-language tracks (e.g. just putting them side-by-side) then it's not an
> issue.

Right. But it's common to overlay the sign-language track.

> I suppose I could mention the issue in the rendering section, so that
> implementors who read that section are aware of it, would that be satisfactory?

Mentioning a problem without solving it doesn't help much. We need to agree on what the right solution is, and specify that.
Comment 10 Ian 'Hixie' Hickson 2011-08-15 04:59:39 UTC
Would it be satisfactory if I changed "to be overlaid with the page content" to "to be overlaid over the page content"? That seems like it would fix any problems here, if UAs are willing to do it.
Comment 11 Ian 'Hixie' Hickson 2011-09-04 17:47:58 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: Partially Accepted
Change Description: see diff given below
Rationale: see comment 10
Comment 12 contributor 2011-09-04 17:49:17 UTC
Checked in as WHATWG revision r6535.
Check-in comment: Try to clarify that controls aren't supposed to be overlapped by content, since that would be pointless.
http://html5.org/tools/web-apps-tracker?from=6534&to=6535