[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

--- Comment #4 from Shelley Powers <shelleyp@burningbird.net> 2011-07-15 23:39:22 UTC ---
(In reply to comment #3)
> (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?
> 

No, this is about context menus, not timeupdate. 

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


No, not really. 

If I create a custom control, I'm listening to the click even on the buttons
not the play or pause events on the video object. 

If I'm enabling or disabling buttons based on play or not of the video, I have
to listen to both sets of events. If removing the controls attribute also
disabled the context menu, I'd only have to listen to the button events. 

My custom control is no longer the only place where the user can begin video
playback.

-- 
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:39:25 UTC