W3C home > Mailing lists > Public > public-html-admin@w3.org > April 2014

[Bug 25261] New: Don't require TextTrack.kind = 'metadata' for DataCues?

From: <bugzilla@jessica.w3.org>
Date: Fri, 04 Apr 2014 15:16:24 +0000
To: public-html-admin@w3.org
Message-ID: <bug-25261-2495@http.www.w3.org/Bugs/Public/>

            Bug ID: 25261
           Summary: Don't require TextTrack.kind = 'metadata' for
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: self@brendanlong.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org,

I'm looking at implementing DataCue in Chromium, and the reviewer had this
comment about my code to throw an exception if we try to add a DataCue to a
metadata track:

> philipj 2014/04/04 14:54:33
> The spec does say this, but it doesn't make sense. TextTrack.kind is readonly, but it can change if the TextTrack is backed by a <track> element, and acolwell wants to make the attribute readwrite for MSE. Also, is there any code that is made simpler if DataCue implies kind=metadata? If not it seems the spec should change.


Is there a reason we want to limit DataCues to kind="metadata" tracks? Maybe
the goal is to simplify rendering, but it's pretty easy to just ignore DataCues
when rendering captions / subtitles.

Specifically, can we remove this line:

> If a DataCue is added to a TextTrack via the addCue() method but the text track does not have its text track kind set to metadata, throw a InvalidNodeTypeError exception and don't add the cue to the TextTrackList of the TextTrack.

Maybe we would also want to add something to the "rules for updating the text
track rendering" to note that DataCues aren't rendered?

You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 4 April 2014 15:16:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:35 UTC