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 14:22:34 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QioiQ-0005Bg-R1@jessica.w3.org>

--- Comment #21 from Shelley Powers <shelleyp@burningbird.net> 2011-07-18 14:22:34 UTC ---
(In reply to comment #19)
> (In reply to comment #14)
> > Why would the HTML5 specification override the web page author and developer's
> > wishes? They don't matter? Are web developers an encumbrance to be worked
> > around?
> If we don't give users the ultimate control over if/when video and audio plays,
> they'll switch to a browser which does. If the spec tried to forbid
> implementors from doing this, then it will just be ignored.

What you're saying is that the browser makers are indifferent to the needs of
developers/authors? Well, there is some truth to this.  

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. 

> > We're forcing developers into using kludges because we're not giving developers
> > options to completely control the media elements. 
> All cases of disabling the context menu that I'm aware of have been to make it
> harder to download the resource, not because the script was unable to deal with
> play/pause from scripts. Which real-word sites are using "kludges" because of
> the pause/play/seek problem?

I'm not talking about disabling the context menu directly--I'm not talking
about disabling the options. Gray them out. 

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. 

I believe the purpose of these bugs is to create a specification that helps
prevent future kludges.

> > > (In reply to comment #10)
> > > > And I'll ask in return: what was the technical reason for removing playback
> > > > control for the media elements from the web page author/developer?
> > > 
> > > Do you mean why the controls attribute was omitted? Usually, because they look
> > > different in all UIs and don't match the design of the embedding page. If some
> > > page author thought it would also guarantee that the user couldn't pause their
> > > video, they were wrong.
> > 
> > No, why was it decided that web developers cannot have complete control over
> > the media element's playback? What was the technical reason to remove such
> > control from the web developer?
> It wasn't removed, it was never there. It's really the same situation with user
> style sheets, extensions, ad blockers, pop-up blockers, click-to-play plugins,
> etc. Sometimes users use these to override authors. Sometimes that breaks
> pages. The best way to avoid that happening is to not do things that users will
> want to override.

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.

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 14:22:41 UTC

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