W3C home > Mailing lists > Public > public-html@w3.org > February 2010

Re: Remove .played from media elements

From: Philip Jägenstedt <philipj@opera.com>
Date: Wed, 10 Feb 2010 12:18:46 +0100
To: "Ian Hickson" <ian@hixie.ch>, "Simon Pieters" <simonp@opera.com>, "Robert O'Callahan" <robert@ocallahan.org>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.u7wsdkbqsr6mfa@nog>
On Wed, 10 Feb 2010 03:42:59 +0100, Ian Hickson <ian@hixie.ch> 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.

YouTube's different color seems to be based on what's buffered, not what's  
been played. (If I seek forward before the new position has been buffered,  
the color starts from the new position. If I seek forward when it has been  
buffered, the color starts from the old position.)

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

It seems unlikely that an advertiser would go to such lengths to *not*  
show ads. Still, this seems more straightforward to implement by simply  
setting a "showed" flag on the ad itself.

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

I don't agree that it's useful, at least not based on the arguments given  
so far. It is relatively easy to implement, but it's easy to do with  
scripts too. For the time being, we won't implement it unless everyone  
else does and we get site compatibility bugs because of it.

Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 10 February 2010 11:19:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:58 UTC