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: Fri, 15 Jul 2011 21:31:46 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qhpz8-0007wM-Gc@jessica.w3.org>

Shelley Powers <shelleyp@burningbird.net> changed:

           What    |Removed                     |Added
                 CC|                            |shelleyp@burningbird.net

--- Comment #2 from Shelley Powers <shelleyp@burningbird.net> 2011-07-15 21:31:46 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > This may seem like an acceptable alternative, but it requires extra machine
> > resources, and playback may not be as smooth, depending on machine resources.
> > It's an ugly kludge but it is the only way for an author or editor to have
> > complete control over the playback of the video. 
> It seems acceptable *because* it's not as good.  When we can't prevent authors
> from doing user-hostile things, making the user-hostile thing worse than the
> user-friendly thing is an acceptable fallback.  In this case we don't even have
> to do anything proactive - the clunkiness just happens for free.
> In addition to being hostile to users in general, this seems to be *extra* bad
> for users with disabilities, who may need access to the video's playback to
> view the content effectively.
> (The only case I can imagine where this isn't actively user-hostile is using a
> <video> to do some type of animation in a game.  It seems perfectly normal to
> draw it into the <canvas> then, so the "workaround" is actually just the
> standard procedure.)

Some would say embedding a complex image into a web page without providing a
link to an in-depth textual description in a separate page is also "user
hostile". The term "user hostile" is subjective. 

You're basing your disagreement with this request on a value judgment, but
you're not providing a solid technical rationale why this additional control
can't be provided. And you're making an assumption that a developer or author
wants this capability because they're somehow hostile to users, which is,
again, a very subjective assumption. 

There is no technical reason _not_ to provide this finer control. There are,
however, sound technical reasons for providing this finer control--not the
least of which not providing this functionality will either force the
developer/author into relying on previous technology (such as Flash) or using a
kludge to get the behavior they need.

In addition, continuing to allow playback options in the context menu when
controls is not present also adds additional complexity to applications that
provide custom controls. They not only have to listen for events triggered by
their own custom controls, but also to handle events triggered by the menu.

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 21:31:53 UTC

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