This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, as the HTML5 is defined, if a person does not provide the controls attribute for whatever reason, and are using the autoplay functionality to start a video when the page loads, if scripting is disabled, the user agents are supposed to expose the control UI to the user. This means that the web page author/developer has no control over the display of this control if scripting is disabled. I'm not aware of any other case where an element attribute is added into the page when scripting is disabled. If the developer is unaware that this happens when scripting is disabled, they may remain totally unaware that the control UI is being displayed whenever the user accesses the page with scripting disabled. More importantly, they're not given the option to not have the control UI display. The controls attribute is a boolean attribute, which means when its present, display the control UI. It's reasonable to assume, then, that when it isn't present, the author or developer does not want the control UI to be present. By enabling the control UI when the attribute is not listed and scripting is disabled, the HTML5 specification is making it impossible to not have a control UI whether the author wants one or not. This limits the choices available to the author or developer.
(In reply to comment #0) > I'm not aware of any other case where an element attribute is added into the > page when scripting is disabled. If the developer is unaware that this happens > when scripting is disabled, they may remain totally unaware that the control UI > is being displayed whenever the user accesses the page with scripting disabled. The attribute is not added. The controls are simply displayed, which happens to be the same thing that occurs if you set the attribute. > More importantly, they're not given the option to not have the control UI > display. > > The controls attribute is a boolean attribute, which means when its present, > display the control UI. It's reasonable to assume, then, that when it isn't > present, the author or developer does not want the control UI to be present. > > By enabling the control UI when the attribute is not listed and scripting is > disabled, the HTML5 specification is making it impossible to not have a control > UI whether the author wants one or not. This limits the choices available to > the author or developer. Disabling the control UI when there is no possibility of providing custom controls is almost certainly going to be done accidentally, by an author assuming that scripting is always on and their script-based controls will be added, and so just omitting the @controls attribute.
(In reply to comment #1) > (In reply to comment #0) > > I'm not aware of any other case where an element attribute is added into the > > page when scripting is disabled. If the developer is unaware that this happens > > when scripting is disabled, they may remain totally unaware that the control UI > > is being displayed whenever the user accesses the page with scripting disabled. > > The attribute is not added. The controls are simply displayed, which happens > to be the same thing that occurs if you set the attribute. > > Point taken. OK, then I'm not aware of other cases where the browsers change the web page elements on their own when scripting is disabled -- other than implementing noscript. > > More importantly, they're not given the option to not have the control UI > > display. > > > > The controls attribute is a boolean attribute, which means when its present, > > display the control UI. It's reasonable to assume, then, that when it isn't > > present, the author or developer does not want the control UI to be present. > > > > By enabling the control UI when the attribute is not listed and scripting is > > disabled, the HTML5 specification is making it impossible to not have a control > > UI whether the author wants one or not. This limits the choices available to > > the author or developer. > > Disabling the control UI when there is no possibility of providing custom > controls is almost certainly going to be done accidentally, by an author > assuming that scripting is always on and their script-based controls will be > added, and so just omitting the @controls attribute. But we've always had this problem. Does the browser then automatically display a hidden section when scripting is disabled? Does it automatically un-collapse a div element when scripting is disabled? So what is it about the video or audio element that requires a complete change to the programming paradigm we've lived with for over 15 years? And what about the cases where the author or developer does not want the UI to display? For whatever reason? This is changing the web page when scripting is disabled, and in such a way that the developer or author has absolutely no control over this change.
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: (In reply to comment #0) > This means that the web page author/developer has no control over the display > of this control if scripting is disabled. Correct. If the user chooses to disable scripting, they have deliberately taken a great deal of control away from author. Part of what makes the web platform good for users is that users are the ones with final control, not authors. We do not give authors control if the user has chosen to take it away. > I'm not aware of any other case where an element attribute is added into the > page when scripting is disabled. The attribute isn't added. The controls are displayed with no attribute. I agree that it would be bad if we generated a different DOM based on whether script was enabled (although we already do for <noscript>). > By enabling the control UI when the attribute is not listed and scripting is > disabled, the HTML5 specification is making it impossible to not have a control > UI whether the author wants one or not. This limits the choices available to > the author or developer. If you want to argue authors need more control here, you have to give specific reasons for why the author needs that control. What are the use-cases where an author would really want to disable browser controls even when their custom controls won't work? (In reply to comment #2) > OK, then I'm not aware of other cases where the browsers change the web page > elements on their own when scripting is disabled -- other than implementing > noscript. I'm not either, but it makes no sense to not provide browser controls if author controls won't work. That would result in a broken media player. > Does the browser then automatically display a hidden section when scripting is > disabled? Does it automatically un-collapse a div element when scripting is > disabled? If authors use <details>, they indicate to the browser that it should let the user collapse and uncollapse that part of the page even without script. If they use just a <div>, then the browser can't do anything to make the page work without script, unfortunately, because it doesn't know that's what the <div> is supposed to do. Authors should use semantic markup like <video> and <details> so that their page can work as intended in as wide a variety of circumstances as possible, even outside the conventional browsers with script enabled that are all most authors test in. > So what is it about the video or audio element that requires a > complete change to the programming paradigm we've lived with for over 15 years? The paradigm we lived with for over fifteen years was fundamentally broken. HTML didn't provide enough features for things like video or collapsing sections to work without script or Flash. One of the goals of HTML5 is that things like media players should be able to work even if the user chooses to disable scripting or not install Flash. > And what about the cases where the author or developer does not want the UI to > display? For whatever reason? > > This is changing the web page when scripting is disabled, and in such a way > that the developer or author has absolutely no control over this change. Correct. This is working as designed. If you have a good use-case for why the author would want to not provide working controls to the user, please reopen with an explanation. Note that "good" means "good for the user", not "good for the author".
I was going to add a TrackerRequest to this item, but doing is useless. Nothing comes of these issues in the W3C.
mass-moved component to LC1
HTML Accessibility Task Force agrees with the Editor's response to this bug in comment 3, but has decided to track the bug in case it gets reopened. We would not want to see the proposal implemented as that would impair many assistive technologies.
(In reply to comment #6) > HTML Accessibility Task Force agrees with the Editor's response to this bug in > comment 3, but has decided to track the bug in case it gets reopened. We would > not want to see the proposal implemented as that would impair many assistive > technologies. The converse is that if we don't get authors the control they need, they'll just stick with Flash, and that can be even more inaccessible. However, I have no intention of re-opening this bug. I can't speak for others, though.
Discussed at HTML Accessibility Task Force call on 06 FEB 2014 http://www.w3.org/2014/02/06-html-a11y-minutes.html#item05 Text remains in the spec, filer does not intend to re-open. Closing.