W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2011

[Bug 13275] Display of media control UI when scripting is disabled

From: <bugzilla@jessica.w3.org>
Date: Mon, 18 Jul 2011 18:31:54 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qisbi-0004Cj-5m@jessica.w3.org>

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:


Status: Rejected
Change Description: no spec change

(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

> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:55 UTC