- From: <bugzilla@jessica.w3.org>
- Date: Mon, 18 Jul 2011 18:31:54 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13275 Aryeh Gregor <Simetrical+w3cbug@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |Simetrical+w3cbug@gmail.com Resolution| |WONTFIX --- Comment #3 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-07-18 18:31:53 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: (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". -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 18 July 2011 18:31:55 UTC