- 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