Re: Feedback on MediaController

On Thu, 21 Apr 2011 01:01:53 +0200, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 18 Apr 2011, Philip Jägenstedt wrote:
>>
>> Apart from this, I think that TrackList really should be a list of Track
>> objects or similar, so that getName/getLanguage are pushed onto that
>> object as .name and .language, just like on TextTrack.
>
> This would balloon the number of objects in the platform. Unless there's  
> a
> very good reason to have objects for each of these tracks, we should  
> avoid
> doing that.
>
>
>> I have no strong opinion, but we should have consistency such that
>> changing the paused attribute (e.g. by calling play()) has the exact
>> same effect. It's not clear to me what the spec thinks should happen
>> when play() is called on a media element with a controller.
>
> Could you elaborate on what is unclear?

Supposedly, the spec should no longer allow slave media elements to be out  
of sync. Yet, HTMLMediaElement.play() still does what it always has,  
including seeking when playback has ended. I can't see anything about  
MediaController that controls what happens when some elements are playing,  
some are paused and have seeked to the beginning, as would be the case  
here. As far as I can tell, it wouldn't become a "blocked media  
controller".

Perhaps play() and pause() should throw INVALID_STATE_ERR when there's a  
controller, just like setting currentTime?

> On Wed, 20 Apr 2011, Philip Jägenstedt wrote:
>> >
>> > I've updated the spec to fire a number of events on MediaController,
>> > including 'metadataavailable' and 'playing'/'waiting'.
>>
>> This seems to make the race conditions in HTMLMediaElement.readyState
>> slightly worse than they already were. At the point when the
>> loadedmetadata event is fired on the MediaController, the readyState of
>> the slaved media elements could be just about anything, and might not
>> even be the same on all of them. These open bugs are about race
>> conditions with readyState and networkState:
>>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11981
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12175
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267
>>
>> These open bugs are about other readyState issues:
>>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12195
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12529
>>
>> I'd very much like to see at least the overall issue of race conditions
>> resolved. For these aggregate events on MediaController, we would have
>> to make sure that they are fired in the same task as the last media
>> element changes its readyState and fires the corresponding event.
>
> I'll make sure to keep the MediaController spec consistent with whatever
> happens in those bugs.

Thanks, I'm looking forward to it :)

>> > The use case Silvia suggests seems reasonable (marking on the timeline
>> > what has been played), why is it not good?
>>
>> I've boycotted HTMLMediaElement.played by not implementing it and so far
>> I've never heard a single request for it. I've also never seen controls
>> that expose what has already been played, only what is currently
>> buffered. I know this has been discussed before, but I can't find it in
>> the archives. Then the use case was something like showing or not
>> showing ads depending on what had been watched, I think. IMO, in the
>> absence of compelling use cases it should be removed from both
>> HTMLMediaElement and MediaController. One thing speaking against that is
>> that it's already implemented in WebKit, of course.
>
> I don't feel particularly strongly about this one way or the other. It
> seems useful to me (to highlight the played parts on a timeline, to keep
> track of which segments should have ads shown in them and which should  
> not
> because the user is just going back to a previously watched part again),
> and if scripts can do it then presumably it's just as easy for UAs to do
> it, but also, if scripts can do it then it's not really needed in the  
> API.
>
> I'm happy to follow implementations on this.

At what point would you remove it from the spec because of lack of  
implementor interest?

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 21 April 2011 11:25:34 UTC