This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the section at[1] the text states the following: "If the attribute is present, or if scripting is disabled for the media element, then the user agent should expose a user interface to the user." Does this mean if I'm creating a custom media element control, I can safely leave the controls attribute off the media element? That if the user has disabled JavaScript (which would disable my custom control), the user agent is supposed to automatically expose this user interface? Right now, I'm assuming if I want to do a custom control for a video element, I add the controls attribute to the element, and then in code, remove the attribute. If I understand this section correctly, though, the browsers should automatically detect if JavaScript is disabled and provide this user interface by default. Please clarify in this section exactly what is supposed to happen. [1] http://dev.w3.org/html5/spec/the-iframe-element.html#user-interface
I don't see any need for clarification - that's exactly what the sentence says, clearly and directly.
(In reply to comment #1) > I don't see any need for clarification - that's exactly what the sentence says, > clearly and directly. It is not a behavior web application developers have come to expect: an attribute is added to an element when scripting is disabled. This is not according to previous expectation or experience. Only Opera actually turns on the UI if scripting is disabled. This would seem to further support my concern that this behavior just isn't expected. I also think the use of "should" is ambiguous. I believe to be effective, it should be changed to "must", perhaps with a more emphatic sentence structure to ensure that developers don't have to try the code out in every browser in order to verify that yes, they did read this sentence correctly.
Odd, not sure why I ended up with a double comment.
Then there's the issue of a person not wanting the controls, regardless. Let's say they have a video they want to autoplay when the page loads. Doesn't matter if you agree with this or not, that's what they want. So they remove the controls attribute, but if the user's scripting is disabled, the control is added back. They literally have no way of keeping the control turned off, because if scripting is disabled, they can't disable the attribute _with_ scripting. Frankly, the more I think on it, the more this is not a good idea. Once I know for sure that this is the expected behavior, will probably have to file a bug to remove it. It's just not something that should be taken out of the hands of the page author/developer.
(In reply to comment #5) > Then there's the issue of a person not wanting the controls, regardless. > > Let's say they have a video they want to autoplay when the page loads. Doesn't > matter if you agree with this or not, that's what they want. > > So they remove the controls attribute, but if the user's scripting is disabled, > the control is added back. They literally have no way of keeping the control > turned off, because if scripting is disabled, they can't disable the attribute > _with_ scripting. Weight that scenario against the scenario the clause is intended to address, where an author omits @controls because they're planning to use script to define custom controls. I think the latter scenario is more likely, and more importantly, more annoying for the user. It's also annoying for the user if a video autoplays without controls to stop it. So, both scenarios end up being better for the user if the controls are automatically shown. The minor benefit to authors doesn't seem to outweigh this, in my opinion.
(In reply to comment #6) > (In reply to comment #5) > > Then there's the issue of a person not wanting the controls, regardless. > > > > Let's say they have a video they want to autoplay when the page loads. Doesn't > > matter if you agree with this or not, that's what they want. > > > > So they remove the controls attribute, but if the user's scripting is disabled, > > the control is added back. They literally have no way of keeping the control > > turned off, because if scripting is disabled, they can't disable the attribute > > _with_ scripting. > > Weight that scenario against the scenario the clause is intended to address, > where an author omits @controls because they're planning to use script to > define custom controls. > > I think the latter scenario is more likely, and more importantly, more annoying > for the user. > > It's also annoying for the user if a video autoplays without controls to stop > it. So, both scenarios end up being better for the user if the controls are > automatically shown. The minor benefit to authors doesn't seem to outweigh > this, in my opinion. But you're removing the options for the web page author or developer. You're making a value judgment for everyone. Right now, if I do a custom control, it's a piece of cake to remove the controls attribute and it's gone. In fact, I have to in every browser but Opera. This isn't unusual for web developers--we're used to having to hide and show things based on scripting being disabled or not. However, now we don't know if the controls will display or not because of browser differences. Frankly, we have to code the removeAttribute anyway because of these differences--the functionality buys us absolutely nothing. The fallback functionality does, however, override the wishes of those people who, for whatever reason, want a video or audio element to play when a page is loaded. For whatever reason. But that's really a separate bug. Right now, though, I see different behaviors with different browsers. Is the different behavior because of bugs? Or because of misunderstanding about what's expected of the browsers?
And further in the same text is the following: "Even when the attribute is absent, however, user agents may provide controls to affect playback of the media resource (e.g. play, pause, seeking, and volume controls), but such features should not interfere with the page's normal rendering. For example, such features could be exposed in the media element's context menu." So does this mean that if the controls attribute is missing and scripting is disabled that providing this functionality in the context menu is sufficient? But the context menu isn't necessarily what I would think of when reading "expose a user interface". Is that why other browsers don't provide the control UI? Because they expose this functionality (always) in the Context menu?
(In reply to comment #0) > Does this mean if I'm creating a custom media element control, I can safely > leave the controls attribute off the media element? That if the user has > disabled JavaScript (which would disable my custom control), the user agent is > supposed to automatically expose this user interface? Yes, that seems clear. (In reply to comment #2) > Only Opera actually turns on the UI if scripting is disabled. This would seem > to further support my concern that this behavior just isn't expected. That suggests bugs should be filed against non-Opera browsers. > I also think the use of "should" is ambiguous. I believe to be effective, it > should be changed to "must", perhaps with a more emphatic sentence structure to > ensure that developers don't have to try the code out in every browser in order > to verify that yes, they did read this sentence correctly. Hixie normally doesn't use anything stronger than "should" for UI requirements. I agree that "must" would be appropriate here, but I don't think it makes a big difference -- "should" still means "must unless there's some good reason not to". (In reply to comment #7) > But you're removing the options for the web page author or developer. You're > making a value judgment for everyone. The only option that's being taken away is that authors can't disable built-in controls when scripting is disabled. Do you think any authors would legitimately want to do that? That would leave the user with no controls at all. > However, now we don't know if the controls will display or not because of > browser differences. Frankly, we have to code the removeAttribute anyway > because of these differences--the functionality buys us absolutely nothing. That's a problem with the browsers, not the spec. The spec's behavior makes the most sense. If browsers don't display controls unconditionally when script is disabled, they're buggy: they leave the user with a non-functioning media player if the author didn't add a controls attribute. 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: Additional Information Needed Change Description: no spec change Rationale: See above. I don't see anything that's unclear or incorrect about the text you quoted, so I don't see what change there is to make. Please reopen if you either have specific suggestions for how the text could be clearer, or think that the non-Opera behavior is better than the Opera behavior and that the spec should change to require that. Failing that, I'd suggest you file bugs against any browsers that aren't following the spec.
mass-moved component to LC1
Discussed in HTML Accessibility TF Meeting on 13 Feb 2014 http://www.w3.org/2014/02/13-html-a11y-minutes.html#item06 RESOLVED to consider for HTML 5.1 Moved to HTML a11y Task Force component on 08 MAR 2014 for additional info.