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

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 01 Feb 2012 15:59:55 +0000
To: public-html-a11y@w3.org
Message-Id: <E1RscbD-0001v7-OF@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13359

--- Comment #40 from Bob Lund <b.lund@cablelabs.com> 2012-02-01 15:59:49 UTC ---

(In reply to comment #39)
> It does seem unnecessarily complicated.

All for possible simplification.

> For the usage described (enabling a
> script to find its metadata track), all that's needed is to expose a single
> string from the track to the script. For WebM the contents of the track's
> CodecID element would be appropriate and sufficient. 

If CodecID provides the same information as TrackType, e.g. distinguishes
between subtitle and control, then I agree. Otherwise it seems TrackType
provides essential information in determining a text track type.

>For Ogg, the contents of
> the 'name' field should be enough. Similar simplifications for the other
> formats should be possible.

According to [1], "Role describe what semantic type of content is contained in
a track" and "This field (Name) provides the opportunity to associate a free
text string with the track". If only one of these fields can be provided I
think Role would be more appropriate as it's values are defined. However, Role
still doesn't fully identify the type of data in, for example, text/metadata,
so it seems Name could be useful.

> 
> Comment #37 seems to be trying to create a feature that exposes a subset of the
> container-specific per-track metadata to script, which is overkill for the
> use-cases described in comment #0. IMHO.

[1] http://wiki.xiph.org/SkeletonHeaders

-- 
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 Wednesday, 1 February 2012 16:00:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:53 GMT