This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
I'd like to clarify that the kind & lang attributes being mutable for MSE is still being discussed on the public-html-media mailing list. I don't think the "acolwell wants to make the attribute readwrite for MSE" correctly reflects my position or what is going on. I didn't realize this comment would be posted here verbatim before I had a chance to respond. I think a decision should be made about whether kind='metadata' is required independent of the mutable attribute discussion on MSE.
(In reply to Aaron Colwell from comment #1) > I didn't realize this comment would be posted here verbatim before I had a chance to respond. Sorry about that. I think the fact that the 'kind' can change is reason enough to remove this requirement.
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.
(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?
(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. Better to say "not automatically rendered by UA". That is, it isn't meant that it can't be rendered (in general) or that it can't be rendered by the UA under the direction of the app (e.g., app translates into HTML to be rendered by UA). > > 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? Actually I think Brendan's suggestion is a good one, that if a DataCue is on a track of @kind !metadata, then the UA should ignore it for the purpose of automatic rendering.
Note to self: Aaron also found a typo in the spec s/TextTrackList/TextTrackCueList/ .
(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.
(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?
(In reply to Silvia Pfeiffer from comment #8) > (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? definitely #1 (no rendering, an otherwise ignored by UA)
(In reply to Glenn Adams from comment #9) > > 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? > > definitely #1 (no rendering, an otherwise ignored by UA) I agree. DataCues aren't meant to be rendered. Making them renderable just makes it easier for them to be rendered by accident.
(In reply to Brendan Long from comment #10) > (In reply to Glenn Adams from comment #9) > > > 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? > > > > definitely #1 (no rendering, an otherwise ignored by UA) > > I agree. DataCues aren't meant to be rendered. Making them renderable just > makes it easier for them to be rendered by accident. Just to be clear, what I meant was no "automatic" rendering by UA. That doesn't mean an APP can't render (something). The spec should be clear about this point.
(In reply to Glenn Adams from comment #11) > Just to be clear, what I meant was no "automatic" rendering by UA. That > doesn't mean an APP can't render (something). The spec should be clear about > this point. I think it's generally understood that JavaScript can do whatever it wants with cues.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: https://github.com/w3c/html/commit/98fc073b1f0ae14388a44773cfcabd708b17b73a Rationale: Just ignore DataCue rather than raising error when on a non-metadata track kind.