Re: Remove .played from media elements

On Feb 9, 2010, at 6:42 PM, Ian Hickson wrote:

> 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 agree, this is precisely the use case I imagine for it as well.

> 
> 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.
> 
  The currently shipping WebKit implements .played. It wasn't difficult to implement, and I think it is a useful attribute so I am opposed to removing it.

  My apologies for missing this thread when it came up last month.

eric

Received on Wednesday, 10 February 2010 04:46:30 UTC