W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2011

[Bug 14260] <track> "text tracks ready" and HTMLMediaElement.readyState

From: <bugzilla@jessica.w3.org>
Date: Fri, 04 Nov 2011 06:13:36 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RMD20-0001oW-UV@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14260

--- Comment #27 from Simon Pieters <simonp@opera.com> 2011-11-04 06:13:35 UTC ---
(In reply to comment #26)
> As Simon pointed out in IRC, it's a bit odd that <track> inserted by script
> behaves completely differently from <track> inserted by the parser. Perhaps
> another way is to define that </video> invokes the resource selection algorithm
> and to instead consider all child <track> elements the last time the resource
> selection algorithm was invoked to block the transition to HAVE_CURRENT_DATA?
> 
> To avoid taking an actual snapshot of the list of <track> elements, I'd
> probably implement it as a "blocking" flag that is set to true for child
> <track> elements when the resource selection algorithm runs.

This sounds good to me.

> P.S. I suggest blocking HAVE_CURRENT_DATA rather than HAVE_FUTURE_DATA because
> a cue might begin at 0.

Blocking HAVE_CURRENT_DATA means you can't show the first frame, which is bad.
I think blocking HAVE_FUTURE_DATA is right, since it means you can show a frame
but you can't start playback. The track doesn't need to appear at the same time
as the first frame.

-- 
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, 4 November 2011 06:15:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 4 November 2011 06:15:56 GMT