- From: <bugzilla@jessica.w3.org>
- Date: Sun, 27 Apr 2014 01:37:03 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25261 --- Comment #8 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> --- (In reply to Philip Jägenstedt from comment #7) > (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. OK, but we have to deal with the consequences, which means we have to define "rules for updating the text track rendering", seeing as now DataCue objects can become active and rendered. We have the following options: 1. no automatic rendering by UA 2. rendering of content of .text as plain text If we pick 2. (which could be useful for debugging, for example), then we would probably render it at the bottom of the video viewport, centered. What do ppl prefer? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Sunday, 27 April 2014 01:37:04 UTC