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 16:00:15 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QiqEx-0002Ch-LK@jessica.w3.org>

--- Comment #23 from Shelley Powers <shelleyp@burningbird.net> 2011-07-18 16:00:15 UTC ---
(In reply to comment #22)
> > What you're saying is that the browser makers are indifferent to the needs of
> > developers/authors? Well, there is some truth to this.  
> Not indifferent, but we have very strong incentives to put the wishes of users
> above the wishes of authors in cases where authors have the tools to do
> annoying things. Audio playback is definitely such a case.

But that's a subjective opinion, not a technique limitation. You're making
assumptions about why the author or developer is choosing not to display the
default controls (in UI or context menu)--to the point where you're abrogating
their ability to have fine control over the media elements in their web pages
and apps.

> > The web developers can work around the intransigence of the browser makers if
> > need be. However, it would be better if there were options that gave the
> > developers the flexibility they need without having to use kludges. 
> The best way to "work around" the problem is to just handle the few extra
> events needed to make it work. Allowing pages to force audio/video playback
> without the option for users to override it is not an option, as users are
> asking us to add *more* such overrides, not remove them.

The simplest and easiest "override" the user has is to leave the page and not
come back. They've always had this option. 

And as I've shown, developers can apply hacks to work around the, well, for
want of a better term, developer hostility that's embedded in HTML5. 

We don't want people to have to hack things. We want to provide granularity of
control so that they have the ability to turn things on, and off, as needed. 

Then if they create an annoying page, well, users can blow the developers a bit
raspberry, leave and never come back. 

It's not really the HTML5 spec's place to come between the users and the web
developers. We're not the enemy. 

> > But these actions are between the user and the user agent, and the developer
> > and the user agent--these actions are not codified in the specification.
> Neither is the context menu or UI to pause/mute all elements in a page.

Actually, it is, in the section I linked earlier. The problem is, the
specification states user agents may or may not provide the context menu, but
then left the implementation of such a menu to the user agent. The only
requirement on the context menu items is which events the options fire. 

We developers and authors have no granularity of control of the media elements.
We have only the illusion of control.

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 16:00:20 UTC

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