Bug 17465 - <track> text tracks need to allow a @default attribute per group of @kind tracks
<track> text tracks need to allow a @default attribute per group of @kind tracks
Status: RESOLVED FIXED
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
unspecified
PC All
: P2 normal
: ---
Assigned To: This bug has no owner yet - up for the taking
HTML WG Bugzilla archive list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-12 00:24 UTC by Silvia Pfeiffer
Modified: 2012-11-28 15:48 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Silvia Pfeiffer 2012-06-12 00:24:17 UTC
We would like to be able to mark up text tracks such that we can choose a default caption track to activate as well as a default description track. This can be generalised to wanting to point to a default track per @kind value.

Right now, only one <track> element is allowed to have a @default attribute.
Comment 1 Philip Jägenstedt 2012-06-12 09:57:25 UTC
Does it really make sense to enable both a subtitle track and a captions track by default? More sense then enabling two caption tracks?

I'm not opposed to allowing more than one default track, but how should the automatic track selection be influenced by that? With only a single track enabled, it's easy to tell that there's another track in a language that the user knows better, but how can one tell which combination of tracks is better than multiple default tracks?

The simplest thing to do would probably to simply enable all tracks with a default attribute (ignoring their types) and to to disable automatic track selection if there are more than one default tracks.
Comment 2 Silvia Pfeiffer 2012-06-12 12:30:18 UTC
(In reply to comment #1)
> Does it really make sense to enable both a subtitle track and a captions track
> by default? More sense then enabling two caption tracks?

We've made them two separate kinds, so: yes. A caption track would be in the native language (e.g. in English) and an additional subtitle track would be in a different language (e.g. in Swedish), which would be great for deaf people that are trying to learn a foreign language.


> I'm not opposed to allowing more than one default track, but how should the
> automatic track selection be influenced by that?

I am only asking for a default PER KIND. So, a default caption, a default subtitle, a default description, and a default metadata track make complete sense to me, in particular since the descriptions are rendered through audio and the metadata through script.


> With only a single track
> enabled, it's easy to tell that there's another track in a language that the
> user knows better, but how can one tell which combination of tracks is better
> than multiple default tracks?

I don't understand this question. There won't be more than on caption track active. In a menu there would be a list of all the available caption tracks, so you choose a different one which deactivates the previous one. Same for all the other tracks.

For example, I would author to set (out of a list of tracks of different kinds and languages) a default caption track in English and a default descriptions track in English. As a browser, I could be even more clever to choose the default based on the language settings of the browser - and that default would be per kind.

> The simplest thing to do would probably to simply enable all tracks with a
> default attribute (ignoring their types) and to to disable automatic track
> selection if there are more than one default tracks.

How would you do automatic track selection with a single default attribute across all track kinds? I think that's actually not do-able/sensible. A default per track kind, in contrast, makes sense.
Comment 3 Philip Jägenstedt 2012-06-12 13:10:40 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Does it really make sense to enable both a subtitle track and a captions track
> > by default? More sense then enabling two caption tracks?
> 
> We've made them two separate kinds, so: yes. A caption track would be in the
> native language (e.g. in English) and an additional subtitle track would be in
> a different language (e.g. in Swedish), which would be great for deaf people
> that are trying to learn a foreign language.

The site author can't know that the user is learning a language, but even so, wouldn't it make exactly as much sense for a hearing user to have two subtitle tracks enabled?

> > I'm not opposed to allowing more than one default track, but how should the
> > automatic track selection be influenced by that?
> 
> I am only asking for a default PER KIND. So, a default caption, a default
> subtitle, a default description, and a default metadata track make complete
> sense to me, in particular since the descriptions are rendered through audio
> and the metadata through script.

With automatic track selection, you'll want to enable the captions or subtitle track that best matches the user preference, not one captions track and one subtitle track. In other words, I don't think it makes sense to consider captions and subtitles separately, they are in the same bucket as far as automatic selection goes.

Default metadata tracks seems weird, given that scripts are needed to make sense of them and can enable them by setting .mode = 'hidden'.

> > With only a single track
> > enabled, it's easy to tell that there's another track in a language that the
> > user knows better, but how can one tell which combination of tracks is better
> > than multiple default tracks?
> 
> I don't understand this question. There won't be more than on caption track
> active. In a menu there would be a list of all the available caption tracks, so
> you choose a different one which deactivates the previous one. Same for all the
> other tracks.
> 
> For example, I would author to set (out of a list of tracks of different kinds
> and languages) a default caption track in English and a default descriptions
> track in English. As a browser, I could be even more clever to choose the
> default based on the language settings of the browser - and that default would
> be per kind.

The problem is know how to interpret a page with default captions *and* subtitles. Should I pick one of them depending on user preference, try to enable a subtitle and a caption track and fall back to the defaults, or something else?

> > The simplest thing to do would probably to simply enable all tracks with a
> > default attribute (ignoring their types) and to to disable automatic track
> > selection if there are more than one default tracks.
> 
> How would you do automatic track selection with a single default attribute
> across all track kinds? I think that's actually not do-able/sensible. A default
> per track kind, in contrast, makes sense.

We currently enable the first captions or subtitle track with a default attribute. The automatic selection we plan to do would consider all captions and subtitle tracks as a group and pick the one that best matches the user preference, falling back to the default.
Comment 4 Silvia Pfeiffer 2012-06-12 15:56:13 UTC
(In reply to comment #3)
>
> The site author can't know that the user is learning a language, but even so,
> wouldn't it make exactly as much sense for a hearing user to have two subtitle
> tracks enabled?

In theory, maybe. There's much less of a need, because either you don't understand the language that is spoken and want to read in your own native language - then you choose a subtitle track in your own native language. Or you understand the language spoken in the video, but not well enough to fully get it - in which case you want the spoken language's subtitles. In both cases would you likely get confused if there were two tracks available.

We did consider this use case at one stage, but said it would be more of a gimmick and rare and if the author needed it they could always code it up in JS.

 
> With automatic track selection, you'll want to enable the captions or subtitle
> track that best matches the user preference, not one captions track and one
> subtitle track. In other words, I don't think it makes sense to consider
> captions and subtitles separately, they are in the same bucket as far as
> automatic selection goes.

Maybe. It depends on what browser settings you're introducing. If you introduce one for "native language" then that would influence the subtitle selection (and maybe the caption selection if no subtitle track is available). If you introduce a setting for "captions always" on, then that would influence the caption selection (and maybe the subtitle selection if no caption tracks are available). In both these cases you would indeed only pick one default track.


> Default metadata tracks seems weird, given that scripts are needed to make
> sense of them and can enable them by setting .mode = 'hidden'.

They turn the use of tracks on. Not sure what's weird about that.


> The problem is know how to interpret a page with default captions *and*
> subtitles. Should I pick one of them depending on user preference, try to
> enable a subtitle and a caption track and fall back to the defaults, or
> something else?

Yes, this is the only combination for which "default" needs to be defined, since they compete over screen real estate. I'd say that if both kinds have a default track, the one that matches the user preferences better wins (i.e. blind -> caption track, else subtitle track)


> We currently enable the first captions or subtitle track with a default
> attribute. The automatic selection we plan to do would consider all captions
> and subtitle tracks as a group and pick the one that best matches the user
> preference, falling back to the default.

OK, that's another approach that can work. Thus, just one default on (CAPTIONS+SUBTITLES) and a separate default each on DESCRIPTIONS, CHAPTERS, and METADATA?
Comment 5 contributor 2012-07-18 07:10:42 UTC
This bug was cloned to create bug 17877 as part of operation convergence.
Comment 6 Silvia Pfeiffer 2012-11-28 15:48:38 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If
you are satisfied with this response, please change the state of
this bug to CLOSED. If you have additional information and would
like the Editor to reconsider, please reopen this bug. If you would
like to escalate the issue to the full HTML Working Group, please
add the TrackerRequest keyword to this bug, and suggest title and
text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this
document:   http://dev.w3.org/html5/decision-policy/decision-policy-v2.html

Status: Accepted

Change Description:
https://github.com/w3c/html/commit/1a2b91fdeb20d026dc63b5e1623fe21bc35fe0e1

Rationale: Adopted WHATWG spec patch