W3C home > Mailing lists > Public > public-html-a11y@w3.org > May 2012

[Bug 13359] <track> A way is needed to identify the type of data in a track element

From: <bugzilla@jessica.w3.org>
Date: Thu, 31 May 2012 16:14:37 +0000
To: public-html-a11y@w3.org
Message-Id: <E1Sa81F-0002CI-Va@jessica.w3.org>

--- Comment #48 from Bob Lund <b.lund@cablelabs.com> 2012-05-31 16:14:32 UTC ---
(In reply to comment #47)
> (In reply to comment #46)
> > roc, how does comment 45 sound for MPEG-4 and MPEG-2 stream? Is it simple
> > enough?
> Sounds OK.
> But why not simply encode the type and value as "TYPE VALUE"? Less chance of
> things going wrong with author regexes if VALUE happens to contain "}". Need to
> require that TYPE does not contain a space.

Sounds OK.

Does the editor have an idea for where the solution will be documented? One
proposal is a separate W3C spec that is referenced by the HTML5 spec.

On a related issue, the solution to this bug will allow script to recognize the
type of data in text tracks in a standard way, even if the UA does not
recognize those tracks. Script access to these tracks is only possible if the
UA exposes all text tracks in a media resource. As far as I can tell, the HTML5
spec has only one requirement for how the UA exposes media resource text tracks
[1]. This could be read to imply that a UA must expose all text tracks.
However, this could also be read to apply to only the text tracks that the UA
makes available. It might be good to add an explicit requirement that all text
tracks in the media resource be exposed . BTW, HTML5 has a similar track list
ordering requirement for video and audio tracks [2]. An explicit requirement
for the UA to expose all video and audio tracks in a media resource would be

[1] http://dev.w3.org/html5/spec/single-page.html#list-of-text-tracks
[2] http://dev.w3.org/html5/spec/single-page.html#audiotracklist

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 31 May 2012 16:14:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:28 UTC