This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In section "sourcing-out-of-band-text-tracks" of the HTML5 spec, the spec defines an algorithm for loading out-of-band text tracks for <video> elements. Step 4 in that algorithm says this: "The tasks queued by the fetching algorithm on the networking task source to process the data as it is being fetched must examine the resource's Content Type metadata, once it is available, if it ever is. If no Content Type metadata is ever available, or if the type is not recognised as a text track format, then the resource's format must be assumed to be unsupported (this causes the load to fail, as described below). If a type is obtained, and represents a supported text track format, then the resource's data must be passed to the appropriate parser as it is received, with the text track list of cues being used for that parser's output." However the behaviour seems to be underspecified in the case that the data fetched is partial or mangled. Microsoft's understanding is that in such cases UAs may attempt to rescue malformed content in the parser, or they may simply abandon the processing. But that in either case the parser should always return and processing continue with a properly formed track; although in the error case the returned text track list of cues may be empty, truncated or otherwise incomplete. We believe it is a problem however if no indication is made to the web page author as to whether the processing completed without error, or whether errors were encountered. Suggestion. clarify in the text that the above understanding is in fact correct, and add an error state/event to the JS API to indicate whether the track parser completed properly or not.
The HTML Accessibility Task Force Bug Triage sub-team does not consider this bug to be TF priority.
How to handle broken content is an issue for the specification that defines the content. For example, the XML spec says to report the content up to the first error and then stop processing. The WebVTT spec defines specific error handling rules for all possible inputs. Other formats may have other rules. I don't understand what more there is to define here. What is the use case for reporting an error to the script? I don't understand when an author would ever check whether the text track was broken or not. Could you elaborate on this?
The user should be made aware when selecting a track which has superficially valid but which contains no, or incomplete data. A blind user for example may not notice 20% of the description was missing. The mechanism for making the user aware may need to be made through script, particularly in the case that the player controls are being provided by the page. In addition, the cues may in fact be metadata that the author is relying on for some activity in the page. If only a subset of the expected cues are present then the script may wish to not process any of them to avoid getting into an inconsistent state.
mass-move component to LC1
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: see diff given below Rationale: If there was a network error and the data is incomplete, then an 'error' event gets fired. That's already specified. Since some formats (e.g. XML formats) report errors for syntax errors I've added support for firing 'error' in such cases. Note that WebVTT is more like HTML or CSS in this regard and does not distinguish syntax errors from forward-compatible parsing rules, so WebVTT files will never fire 'error' events in this way. A script that wants to test for completeness in metadata tracks can always just put a sentinel cue at the end of the file and check for it. User agents are, of course, always allowed to report this kind of thing to the user. Given how unlikely it is for authors to actually check for this kind of thing, if you think it is a concern for your users, I strongly recommend that you handle this at the UA level rather than relying on scripts.
Checked in as WHATWG revision r6470. Check-in comment: Allow UAs to fire 'error' events if they get, e.g., XML errors while reading subtitle files. Doesn't affect WebVTT files. http://html5.org/tools/web-apps-tracker?from=6469&to=6470