Bug 23663 - Section 2.4.4 is not clear about whether it runs while seeking.
Summary: Section 2.4.4 is not clear about whether it runs while seeking.
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: LC
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
Keywords: a11y, a11ytf
Depends on:
Reported: 2013-10-28 22:45 UTC by Aaron Colwell
Modified: 2013-11-14 00:47 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Colwell 2013-10-28 22:45:06 UTC
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."
Comment 1 Aaron Colwell 2013-10-28 23:55:48 UTC
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.
Comment 2 Aaron Colwell 2013-11-14 00:27:08 UTC
Change committed.

Updated section 2.4.3 with the text proposed in comment 1.
Comment 3 Aaron Colwell 2013-11-14 00:47:47 UTC
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: 

Primer discussed in April 2013 F2F minutes:

Primer call for volunteers:

Telecon minutes where primer was discussed.