This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Placeholder bug for a concern raised by individual participants in the HTML Accessibilty Task Force during the LC period. Quoted text from http://lists.w3.org/Archives/Public/public-html-media/2013Oct/0022.html "The second is that while it appears that the purpose of section 2.4.4 is to ensure that all "necessary" tracks render in synch, and it appears that this also applies when the user e.g. seeks to a new position in a "primary", i.e. controlling track, it doesn't say anywhere that this happens. Reading the algorithms is a very complex way to understand what is actually happening, and a simple informative paragraph explaining the effects would be appreciated - especially for this use case, but possibly in other parts of the specification as well."
Section 2.4.4 does not run during seeking. It only runs during playback as the first sentence in the section states. One thing that might make the seeking behavior a little more obvious is to to change the "The media element waits for the necessary media segments to be passed to appendBuffer() or appendStream()." step in Section 2.4.3 to something more along the lines of "The media element waits until an appendBuffer() or appendStream() call causes the coded frame processing algorithm to set the HTMLMediaElement.readyState attribute to a value greater than HAVE_METADATA." I think this would make it easier for the reader to figure out how the element gets out of the HAVE_METADATA state during a seek. As for adding more informative paragraphs around the spec, the concensus in the task force to similar requests in the past has been to keep the spec primarily algorithmic when it comes to specifying behavior. There have been discussions about creating a primer that includes more informative descriptions of the behavior for folks that are not implementing MSE in a UA, but no one has stepped forward to take on that work yet.
Change committed. https://dvcs.w3.org/hg/html-media/rev/306bb395f94e Updated section 2.4.3 with the text proposed in comment 1.
Just for reference here are some of the various discussions that have occurred in the past around informative text and the primer. This is not an exhaustive list since there have also been many minor discussions within bug comments and on the conference calls. Mailing list discussion on the amount of non-algorithmic text in the spec: http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0065.html http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0000.html Primer discussed in April 2013 F2F minutes: http://www.w3.org/2013/04/23-html-wg-minutes.html#item10 Primer call for volunteers: http://lists.w3.org/Archives/Public/public-html-admin/2013May/0002.html Telecon minutes where primer was discussed. http://lists.w3.org/Archives/Public/public-html-media/2013May/0084.html http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0057.html