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

[Bug 13276] Not allowing author or developer to have absolute control over media playback

From: <bugzilla@jessica.w3.org>
Date: Mon, 18 Jul 2011 19:04:40 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qit7Q-0005yy-BF@jessica.w3.org>

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

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

--- Comment #26 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-07-18 19:04:39 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
Rationale: Media element implementers from two major browsers have commented
here questioning the utility of the proposed change.  The overriding principle
guiding the development of web standards today is that they must match
implementations.  If implementers are not interested in implementing the
feature, it's a nonstarter.  Currently it seems that there's no implementer
interest here.  If at least one major implementer is interested in implementing
this feature, please reopen the bug.  Otherwise the spec will not change.  We
do not spec features that will not be implemented, because it wastes everyone's

(In reply to comment #21)
> I don't believe there's a restriction on bugs that requires that we hunt down
> "real world" examples, especially for a specification that's still in LC status
> and still undergoing significant changes. 

Bug filers are not required to provide real-world use-cases for features they
propose.  However, bugs that don't have clear use-cases are much more likely to
be closed NEEDSINFO or WONTFIX, so it's wise to explain the use-cases you're
trying to meet in as much detail and with as much supporting evidence as
possible.  In addition to lacking implementer support, your comments here do
not convincingly demonstrate that there are pages that need this feature.

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 19:04:41 UTC

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