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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13276

Silvia Pfeiffer <silviapfeiffer1@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |silviapfeiffer1@gmail.com

--- Comment #3 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-07-15 23:31:51 UTC ---
(In reply to comment #2)
> (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.

I think you are arguing for two things here, IIUC: one is a finer resolution of
timeupdate, so the  developer has more control over what is happening with the
video/audio, and a second one (below) about removing context menus. Right?


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

They are the same events. I don't understand what issue the context menus are
creating since they are not raising separate events, but the same ones that the
JS needs to listen to already.

-- 
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 23:31:57 UTC