This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27116 - <track> element is used for more than just "explicit external timed text tracks"
Summary: <track> element is used for more than just "explicit external timed text tracks"
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC other
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-20 21:44 UTC by John Foliot
Modified: 2016-04-27 21:30 UTC (History)
8 users (show)

See Also:


Attachments

Description John Foliot 2014-10-20 21:44:20 UTC
The current spec states: 
     "The track element allows authors to specify explicit external timed text tracks for media elements."

Yet, immediately afterwards, when defining the the various @kind keywords associated to the <track> element, one of those @kinds is Chapters (i.e. <track kind="chapters" src="" label="Chapters"> - "Chapter titles, intended to be used for navigating the media resource. Displayed as an interactive (potentially nested) list in the user agent's interface.") - which is clearly not an external timed text track - and while timing may in fact be present, the rendering in the user-interface is not (as defined by the same spec) intended to display/not display content based on time-stamps, but rather to render a static view of specific time-markers, intended for use in navigation.

Recommendation is to revisit the definition of the <track> element, to broaden its scope. Perhaps something like:
     "The track element allows authors to specify explicit external supplemental resources for media elements."
Comment 1 Eric Carlson 2014-10-21 04:30:06 UTC
A chapter track certainly is an "external timed text track". The format of a chapter track is exactly the same as any other kind of timed text track, text samples (cues) with display times and durations. The only difference is how the UA renders the text samples.
Comment 2 John Foliot 2014-10-25 00:08:10 UTC
(In reply to Eric Carlson from comment #1)
> A chapter track certainly is an "external timed text track". The format of a
> chapter track is exactly the same as any other kind of timed text track,
> text samples (cues) with display times and durations. The only difference is
> how the UA renders the text samples.

What about metadata (Tracks intended for use from script)? Is the only metadata allowed metadata with timing information? Do we have an example that we can reference in the spec, as this seems, at best ambiguous in its definition.

I ask, because now the MediaStream API is also using @kind to reference both audio and video (https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediastreamtrack-kind), and the Media Capture and Streams [GETUSERMEDIA] draft infers @kind (as not checked, because "attribute not checked because stream was created with video option only." - http://www.w3.org/TR/image-capture/#examples) and so it strikes me now that @kind as a more global attribute is already being used for information other than timed text data.
Comment 3 Eric Carlson 2014-10-27 21:38:33 UTC
(In reply to John Foliot from comment #2)
> (In reply to Eric Carlson from comment #1)
> > A chapter track certainly is an "external timed text track". The format of a
> > chapter track is exactly the same as any other kind of timed text track,
> > text samples (cues) with display times and durations. The only difference is
> > how the UA renders the text samples.
> 
> What about metadata (Tracks intended for use from script)? Is the only
> metadata allowed metadata with timing information? 

Metadata samples (cues) are required to have timing information. This is true for all types of cues.
Comment 4 John Foliot 2014-10-27 21:55:35 UTC
(In reply to Eric Carlson from comment #3)
> (In reply to John Foliot from comment #2)
> > (In reply to Eric Carlson from comment #1)
> > > A chapter track certainly is an "external timed text track". The format of a
> > > chapter track is exactly the same as any other kind of timed text track,
> > > text samples (cues) with display times and durations. The only difference is
> > > how the UA renders the text samples.
> > 
> > What about metadata (Tracks intended for use from script)? Is the only
> > metadata allowed metadata with timing information? 
> 
> Metadata samples (cues) are required to have timing information. This is
> true for all types of cues.


Thanks Eric. Can you supply reference please?

JF
Comment 5 Silvia Pfeiffer 2014-11-03 03:12:06 UTC
You might want to re-visit the text track model:
http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#text-track-model

Every text track has "a list of zero or more cues", and each text track cue consists of "a start time" and "an end time".

While the term "timed text track" is not specified, all text tracks are expected to be time-aligned with the media timeline.
Comment 6 Daniel Davis 2014-11-12 06:31:18 UTC
(In reply to Silvia Pfeiffer from comment #5)

> While the term "timed text track" is not specified, all text tracks are
> expected to be time-aligned with the media timeline.

Just to clarify, time-alignment does not seem to be a requirement, based on "a list of zero or more cues".

In which case maybe the original rewording suggestion is valid, or something similar such as:
"The track element allows authors to specify explicit external text resources for media elements."
Comment 7 Silvia Pfeiffer 2014-11-12 11:10:24 UTC
(In reply to Daniel Davis from comment #6)
>
> Just to clarify, time-alignment does not seem to be a requirement, based on
> "a list of zero or more cues".

Is an <img> element without a reference to an image resource still an image?

The intent of "zero" is to allow adding cues via script. It's not to make the text track non-time-aligned.
Comment 8 Arron Eicholz 2016-04-27 21:30:58 UTC
HTML5.1 Bugzilla Bug Triage: Fixed in latest change using the suggestion from Daniel Davis.

https://github.com/w3c/html/pull/275

If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!