Unclear definition of time range

[nigelmegitt]

The data model for WebVTT cues omits the begin and end times, because they are defined as extensions of text track cues, whose definition is:

A start time
The time, in seconds and fractions of a second, that describes the beginning of the range of the media data to which the cue applies.

An end time
The time, in seconds and fractions of a second, that describes the end of the range of the media data to which the cue applies.

It is unclear in any of the definitions of the begin and end times are included in the range or excluded. They should be aligned with the TTML and SMIL definitions where the begin time is included in the range and the end time is excluded, so that if there are two adjacent cues where the first cue's end timestamp is equal to the second cue's begin timestamp then the cues' presentation does not overlap.

[dwsinger]

I'm fine with formally matching the SMIL/TTML definition.

[silviapfeiffer]

Yes, that's how time intervals generally work. This is an underspecification in the HTML spec and needs to be fixed there.

[nigelmegitt]

This is an underspecification in the HTML spec and needs to be fixed there.

Hmm, I'm not so sure. In fact the statement that a WebVTT cue is a text track cue looks wrong to me. I've raised this as #416.

Regardless, it is reasonable to state in the data model of a WebVTT cue that the begin time is included in the range and the end time is excluded. How a text track cue is constructed from this depends on the specification of the text track cue and the algorithm for processing it.

A further argument in favour of doing this: not all WebVTT implementations necessarily use text track cues at all, and they are not required to be built on an HTML5 processor.

[silviapfeiffer]

Actually, I just read up on the HTML5 specification. The "time marches on" algorithm specifies what start time and end time mean - how to interpret them. It would be wrong for the WebVTT spec to redefine that:

The time marches on steps are as follows:

Let current cues be a list of cues, initialized to contain all the cues of all the hidden or showing text tracks of the media element (not the disabled ones) whose start times are less than or equal to the current playback position and whose end times are greater than the current playback position.

Also, note my comment on #416 - a WebVTT cue is defined as a derivative of a text track cue, so this algorithm applies. Even a WebVTT implementation that doesn't use HTML5 needs to refer to it.

I'd be open to adding a note to the spec to re-iterate this fact - it has to be non-normative. Would that satisfy your request?

[dwsinger]

I support adding a note, as long as it refers to this as the normative text (so it's clear it still applies even outside an HTML context).

[nigelmegitt]

Agree - at least a note that references https://www.w3.org/TR/html51/semantics-embedded-content.html#time-marches-on would be useful, if it's clear that the current spec does normatively reference it. For me, it isn't that clear - I think the link is made by saying that a WebVTT Cue is a text track cue in the data model, but it isn't totally clear that the processing model is also the same. I'd expect to see something at the top of the Rendering or Processing Model sections that makes it really clear in a normative way, rather than the slightly handwavy notes that are there now.

Specifically, the text:

The rules for updating the display of WebVTT text tracks render the text tracks of a media element (specifically, a video element), or of another playback mechanism, by applying the steps below.

allows for "another playback mechanism" in an unscoped way, and it is possible that "another playback mechanism" is interpreted or implemented as something that has nothing at all to do with Text Track presentation in HTML5.

[dwsinger]

So, let's normatively reference HTML for the definition of start and end times and Note that the end time is not included in the range while the start time is...

[silviapfeiffer]

Can you please stop using "hand-wavy" for a normative spec - it really irks me that people can just walk all over carefully crafted language that avoids re-defining something that is already specified elsewhere. Normative is normative.
</rant>.

So yes, that reference to HTML is already normative by definition. The spec is very clear:

A WebVTT cue is a text track cue that additionally consist of the following...

That's where the definition and interpretation of id, start time and end time come from and that's already normatively referenced, including links and all. All I can do is add a note.

[dwsinger]

so, how about "A WebVTT cue is a text track cue (as defined in HTML) that…" and

"Note that the HTML definition includes the start time but excludes the end-time from the time-range of a cue, so that adjacent cues that have the same time for the end of the first and beginning of the second do not overlap in time."

[silviapfeiffer]

Please review #419