[Bug 12283] New: No indication of parsing error

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12283

           Summary: No indication of parsing error
           Product: HTML WG
           Version: unspecified
          Platform: All
               URL: http://dev.w3.org/html5/spec/Overview.html#sourcing-ou
                    t-of-band-text-tracks
        OS/Version: All
            Status: NEW
          Keywords: a11y
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: sean.hayes@microsoft.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


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
UA’s 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.

-- 
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 Thursday, 10 March 2011 14:05:45 UTC