Timed tracks - Revision history

Annevk: removed Category:Proposals using HotCat

2014-09-27T15:14:48Z

← Older revision		Revision as of 15:14, 27 September 2014
Line 228:		Line 228:
	# Add DOM API		# Add DOM API
	# Add CSS extensions — propose them to CSSWG		# Add CSS extensions — propose them to CSSWG

	~~[[Category:Proposals]]~~

Annevk at 15:14, 27 September 2014

2014-09-27T15:14:34Z

← Older revision		Revision as of 15:14, 27 September 2014
Line 1:		Line 1:
			{{obsolete\|spec=[https://html.spec.whatwg.org/multipage/embedded-content.html#the-track-element HTML: <track>]}}

	This page contains notes for the development of the first version of timed track features in HTML.		This page contains notes for the development of the first version of timed track features in HTML.

GPHemsley: /* Markup */ Work around parsing issue caused by .

2013-12-18T19:34:44Z

Markup: Work around parsing issue caused by <source>.

← Older revision		Revision as of 19:34, 18 December 2013
Line 84:		Line 84:
	==== Markup ====		==== Markup ====

			<pre>
	<track src="" enabled="true" kind="" label="" lang=""></track>		<track src="" enabled="true" kind="" label="" lang=""></track>

Line 90:		Line 91:
	...		...
	</track>		</track>
			</pre>

	enabled="" is true or false.		enabled="" is true or false.

Annevk: categorize

2011-01-26T12:18:15Z

categorize

← Older revision		Revision as of 12:18, 26 January 2011
Line 224:		Line 224:
	# Add DOM API		# Add DOM API
	# Add CSS extensions — propose them to CSSWG		# Add CSS extensions — propose them to CSSWG

			[[Category:Proposals]]

Philipj: /* Specification approach */

2010-05-07T03:59:00Z

Specification approach

← Older revision		Revision as of 03:59, 7 May 2010
Line 219:		Line 219:
	#* file format — parsing requirements		#* file format — parsing requirements
	#* processing model — rendering rules		#* processing model — rendering rules
			#:See also [[SRT research]] about compatibility with existing parsers.
	# Define processing model for active timed tracks — events, display, etc		# Define processing model for active timed tracks — events, display, etc
	# Add requirements to pause playback while active tracks load		# Add requirements to pause playback while active tracks load
	# Add DOM API		# Add DOM API
	# Add CSS extensions — propose them to CSSWG		# Add CSS extensions — propose them to CSSWG

Hixie: /* File format */

2010-05-02T06:46:33Z

File format

← Older revision		Revision as of 06:46, 2 May 2010
Line 115:		Line 115:

	The two formats that are the cleanest in terms of existing syntax, that are a subset of the above feature set, and that can be extended relatively cleanly in a backwards-compatible way are the FAB subtitler format and the SRT format. The former, however, lacks much documentation. The latter appears to be more well-known.		The two formats that are the cleanest in terms of existing syntax, that are a subset of the above feature set, and that can be extended relatively cleanly in a backwards-compatible way are the FAB subtitler format and the SRT format. The former, however, lacks much documentation. The latter appears to be more well-known.

			Proposal: http://damowmow.com/temp/srtspec

	==== CSS extensions ====		==== CSS extensions ====

Hixie: /* CSS extensions */

2010-05-02T06:44:25Z

CSS extensions

← Older revision		Revision as of 06:44, 2 May 2010
Line 122:		Line 122:
	The block box is matched by the pseudo-element ::cue on the media element (<video>).		The block box is matched by the pseudo-element ::cue on the media element (<video>).
	Only visible cues are matched (those on tracks enabled and shown by the UA whose start/end time range contains the current time).		Only visible cues are matched (those on tracks enabled and shown by the UA whose start/end time range contains the current time).
	The ::cue pseudo takes an optional argument that is the voice of cues that it is to match.		The ::cue pseudo takes an optional argument that is the voice of cues that it is to match. The keyword "*", matching all voices, is assumed if the argument is absent.

	video::cue { color: white; background: rgba(0,0,0,0.5); font: 900 sans-serif; text-transform: uppercase; }		video::cue { color: white; background: rgba(0,0,0,0.5); font: 900 sans-serif; text-transform: uppercase; }
Line 129:		Line 129:
	video::cue(2) { color: lime; }		video::cue(2) { color: lime; }

	The ::cue~~-fragment~~ pseudo matches all ~~inner-most~~ inline boxes in the cue of the element. Its ~~last~~ argument is one of "i", "b", "ruby", "rt"~~, "before", "after". Its first argument, if it has two, is a voice. If it has arguments, the pseudo-element only~~ matches inline boxes ~~that correspond to "i"~~, "b", "~~ruby", or~~ "~~rt" fragments~~ (~~for those keywords) or that correspond to~~ fragments before/after the current time ~~(for those keywords~~).		The ::cue pseudo when given _two_ arguments matches all innermost inline boxes in the cue of the element that match its second argument. Its first argument is a voice; the keyword "*" matches all voices. Its second argument is one of "i", "b", "ruby", "rt" (matches inline boxes immediately inside one of those annotations), "before", "after" (fragments before/after the current time).

	video::cue~~-fragment~~(i) { font-style: italic; }		video::cue(*, i) { font-style: italic; }
	video::cue~~-fragment~~(narrator, i) { font-style: bold; }		video::cue(narrator, i) { font-style: bold; }
	video::cue~~-fragment~~(b) { font-size: larger; }		video::cue(*, b) { font-size: larger; }

	[This isn't great. Any better ideas?]		[This isn't great. Any better ideas?]

Hixie: /* Processing model */

2010-05-02T06:41:04Z

Processing model

← Older revision		Revision as of 06:41, 2 May 2010
Line 115:		Line 115:

	The two formats that are the cleanest in terms of existing syntax, that are a subset of the above feature set, and that can be extended relatively cleanly in a backwards-compatible way are the FAB subtitler format and the SRT format. The former, however, lacks much documentation. The latter appears to be more well-known.		The two formats that are the cleanest in terms of existing syntax, that are a subset of the above feature set, and that can be extended relatively cleanly in a backwards-compatible way are the FAB subtitler format and the SRT format. The former, however, lacks much documentation. The latter appears to be more well-known.

	~~==== Processing model ====~~

	~~...~~

	==== CSS extensions ====		==== CSS extensions ====

Hixie: /* File format */

2010-05-02T06:32:00Z

File format

← Older revision		Revision as of 06:32, 2 May 2010
Line 112:		Line 112:
	==== File format ====		==== File format ====

	~~Should~~ be ~~backwards~~-~~compatible with an existing format~~.		Based on studying a broad range of [[Timed track formats]], there does not appear to be a format that is easy to read and write, supports automatic positioning to avoid overlapping titles while still supporting some level of positioning control, supports temporally-overlapping titles, uses video-independent positioning instead of pixel-based (for visual) or frame-based (for temporal) positioning, and supports some inline structure for ruby, italics, bold, and karaoke.

	~~[[Timed track~~ formats]]		The two formats that are the cleanest in terms of existing syntax, that are a subset of the above feature set, and that can be extended relatively cleanly in a backwards-compatible way are the FAB subtitler format and the SRT format. The former, however, lacks much documentation. The latter appears to be more well-known.

	==== Processing model ====		==== Processing model ====

Hixie: /* File format */

2010-04-27T00:13:05Z

File format

← Older revision		Revision as of 00:13, 27 April 2010
Line 112:		Line 112:
	==== File format ====		==== File format ====

	Should be backwards-compatible with an existing format~~, ideally SRT given the huge volume of subtitles available in SRT format on the Web today~~.		Should be backwards-compatible with an existing format.

	~~...~~		[[Timed track formats]]

	==== Processing model ====		==== Processing model ====