This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
With the current specification, each time an author uses timestamps within a cue they should also add a CSS rule that hides the future nodes (given that opacity or visibility will be supported) I suggest that when timestamps are present, the future nodes should be hidden by default. I believe that most of the use cases expect them to be hidden, while the ones that don't, usually have some other visual change of the future nodes as well (e.g. Karaoke would also use a different color and therefore the requirement to use CSS is justified) Since hiding the nodes is a simple and extremely useful feature, it will probably be supported by players that do not rely on CSS and therefore I think that the exact mechanism of hiding the nodes could be done individually by each agent.
I agree. A default of "visibility:hidden" on these future node, which changes to "visibility:visible" when their time is reached makes sense.
(In reply to comment #1) > I agree. A default of "visibility:hidden" on these future node, which changes > to "visibility:visible" when their time is reached makes sense. For non-CSS players I believe there should be some more flexibility (meaning that the hiding process should not be necessarily described through CSS properties).
It's also what is implemented in Chrome and Safari right now. (In reply to comment #2) > (In reply to comment #1) > > I agree. A default of "visibility:hidden" on these future node, which changes > > to "visibility:visible" when their time is reached makes sense. > For non-CSS players I believe there should be some more flexibility (meaning > that the hiding process should not be necessarily described through CSS > properties). Sure. I just referred to what to add to section 3.5.1 of the spec. BTW: This hidden-before-active display means is already implemented in Chrome and Safari.
(In reply to comment #0) > I believe that most of the use cases expect them to be hidden, What are those use cases? > while the ones that don't, usually have some other visual change of the future > nodes as well (e.g. Karaoke would also use a different color and therefore the > requirement to use CSS is justified) I thought Karaoke was the *main* use case for timestamps.
(In reply to comment #4) > (In reply to comment #0) > > I believe that most of the use cases expect them to be hidden, > > What are those use cases? Paint-on captions, a requirement from the FCC. > > while the ones that don't, usually have some other visual change of the future > > nodes as well (e.g. Karaoke would also use a different color and therefore the > > requirement to use CSS is justified) > > I thought Karaoke was the *main* use case for timestamps. I think the main use case should be the formal requirement by the FCC, and Karaoke should represent the extra feature that can be build on top of this requirement (by adding an additional CSS rule). At this point, for both paint-on and karaoke we need additional CSS rules (visibility for paint-on, color for Karaoke) and timestamps are simply ignored. I strongly believe that it would be a win to have by default paint-on (without any extra rule, just the presence of the timestamps) and for Karaoke simply add one rule containing visibility and color.
(In reply to comment #4) > > I thought Karaoke was the *main* use case for timestamps. I don't think Karaoke is the main use case for tracks that are of kind="captions" - rather Pain-On captions would be. It may be true that for tracks of kind="subtitles" Karaoke is *a* use case, though subtitles are mainly focused on supporting foreign language speakers. I do wonder why we explicitly support "subtitles" and "captions", but never bothered to come up with an explicit kind="karaoke". It is, after all, a semantically different type.
(In reply to comment #5) > > What are those use cases? > Paint-on captions, a requirement from the FCC. Paint-on is something that you would do for a live stream, right? How do timestamps help for a live stream? Currently the <track> and WebVTT features don't work with streaming at all (video playback blocks until all tracks are completely loaded). To do streaming right now, you'd have to use something like WebSocket and create the cues with the API. In such a situation, why bother with timestamps rather than just updating the cue's .text when more data comes in? That said, paint-on does not appear to be mentioned at all in http://wiki.whatwg.org/wiki/Timed_tracks which suggests it was not considered in the design of WebVTT. Streaming was left as an open issue (and is still not addressed): http://wiki.whatwg.org/wiki/Timed_tracks#Streaming (In reply to comment #6) > I don't think Karaoke is the main use case "inline time cues for karaoke" - http://wiki.whatwg.org/wiki/Timed_tracks
(In reply to comment #7) > > Paint-on is something that you would do for a live stream, right? No, not only. Same as roll-up. Both are being used for canned caption files just as much. > To do streaming right now, you'd have to use something like > WebSocket and create the cues with the API. Let's fix live streaming in the bugs that are registered for live streaming. > That said, paint-on does not appear to be mentioned at all in > http://wiki.whatwg.org/wiki/Timed_tracks which suggests it was not considered > in the design of WebVTT. I am not sure what Ian used at the time as motivation to include timed markers. I regarded the time stamps as a solution for paint-on captions and was happy when the time stamps were included for kind="captions", where they are used for paint-on, not for karaoke. > (In reply to comment #6) > > I don't think Karaoke is the main use case > > "inline time cues for karaoke" - http://wiki.whatwg.org/wiki/Timed_tracks Right, that document distinguishes captions, subtitles and karaoke. For captions we use the time stamps for paint-on.
My plan is to add this to the style sheet: ::cue(::future) { color: rgba(128,128,128,1) } ::past and ::future are only intended for Karaoke. Captions that don't show their full text straight away aren't a use case. They're bad UI, as documented by e.g.: http://www.w3.org/community/texttracks/wiki/images/9/96/Live_captioning_report.PDF http://lists.w3.org/Archives/Public/public-texttracks/2011Dec/0010.html
I'm inclined to say that we should just not have a default style for ::future. People are going to use it for various things, some of which we think are silly, but just showing all the cue text seems like the safest default. Resolving as WONTFIX, please reopen if lack of a default style is going to be a problem.