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

[Bug 13273] Clarify text in media element user interface section

From: <bugzilla@jessica.w3.org>
Date: Fri, 15 Jul 2011 19:45:59 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QhoKl-0002AW-2P@jessica.w3.org>

Aryeh Gregor <Simetrical+w3cbug@gmail.com> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
                 CC|                            |Simetrical+w3cbug@gmail.com
         Resolution|                            |NEEDSINFO

--- Comment #9 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-07-15 19:45:58 UTC ---
(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

> 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:


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.

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 Friday, 15 July 2011 19:46:04 UTC

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