- From: <bugzilla@jessica.w3.org>
- Date: Fri, 04 Apr 2014 15:16:24 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25261 Bug ID: 25261 Summary: Don't require TextTrack.kind = 'metadata' for DataCues? 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, public-html-wg-issue-tracking@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. https://codereview.chromium.org/224833002/diff/1/Source/core/html/track/TextTrack.cpp 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 the QA Contact for the bug.
Received on Friday, 4 April 2014 15:16:25 UTC