- From: <bugzilla@jessica.w3.org>
- Date: Thu, 24 Apr 2014 13:00:25 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25261 --- Comment #7 from Philip Jägenstedt <philipj@opera.com> --- (In reply to Silvia Pfeiffer from comment #4) > (In reply to Philip Jägenstedt from comment #3) > > Sorry Aaron, I should have worded that more carefully. > > > > I don't think anything (normative) needs to be said about DataCue rendering, > > because there is no default rendering algorithm that could apply. > > When cues are of kind captions, subtitles, chapters or descriptions, some > kind of rendering is expected, see > http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#attr- > track-kind . > > The only kind of cue that is not rendered is of metadata. For that reason, > kind=metadata is appropriate for DataCues which are per definition not > rendered. > > If we allowed DataCue to be on a caption track, for example, we'd need to > define a rendering algorithm - likely the content of the text attribute > being rendered verbatim on screen. Is there a use case for that? It's not a matter of use cases, it's that guard in the spec is incomplete: var track = document.createElement('track'); track.kind = 'metadata'; track.mode = 'hidden'; track.track.addCue(new DataCue(0, 0, new ArrayBuffer()); track.setAttribute('kind', 'captions'); Throwing an exception on that last line would be very weird. Lacking a (sane) way to ensure that a DataCue is never in a TextTrack with a kind other than metadata, just allowing it seems much simpler. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 24 April 2014 13:00:31 UTC