On Tue, 19 Jan 2010, Simon Pieters wrote:
>
> What's the use case for .played on media elements? As far as I know
> existing media players don't have any UI for what has been played. We
> think .played should be dropped from the spec.
Many players render the progress bar before the current playback position
in a different colour than after the current playback position. Some, e.g.
the YouTube player, render a different colour from the last play start
position. This suggests that this kind of information could be useful
from a UI standpoint.
It could also be useful from an ads standpoint. For example, finding out
if the current playback position after a seek is inside a range that's
been played already, and not showing any ads if that is the case (on the
principle that the relevant ad has already been shown).
On Wed, 20 Jan 2010, Robert O'Callahan wrote:
>
> It seems that .played is only useful if you want to dynamically add
> scripted controls to an element, where the controls display what has
> been played, and you really want the controls to display what was played
> before they were added.
The API in general is built on the assumption that different controllers
can jump in and be up to speed long after the element was created.
I'm happy to remove the API if nobody is going to implement it, but it
seems to be a useful API in principle, easy to implement, and of low cost,
so unless one of those assumptions is flawed, I'd rather keep it.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'