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 17877 - <track> text tracks need to allow a @default attribute per group of @kind tracks
Summary: <track> text tracks need to allow a @default attribute per group of @kind tracks
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 07:10 UTC by contributor
Modified: 2012-11-23 07:46 UTC (History)
4 users (show)

See Also:


Attachments

Description contributor 2012-07-18 07:10:39 UTC
This was was cloned from bug 17465 as part of operation convergence.
Originally filed: 2012-06-12 00:24:00 +0000
Original reporter: Silvia Pfeiffer <silviapfeiffer1@gmail.com>

================================================================================
 #0   Silvia Pfeiffer                                 2012-06-12 00:24:17 +0000 
--------------------------------------------------------------------------------
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.
================================================================================
 #1   Philip J                                        2012-06-12 09:57:25 +0000 
--------------------------------------------------------------------------------
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.
================================================================================
 #2   Silvia Pfeiffer                                 2012-06-12 12:30:18 +0000 
--------------------------------------------------------------------------------
(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.
================================================================================
 #3   Philip J                                        2012-06-12 13:10:40 +0000 
--------------------------------------------------------------------------------
(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.
================================================================================
 #4   Silvia Pfeiffer                                 2012-06-12 15:56:13 +0000 
--------------------------------------------------------------------------------
(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 1 Simon Pieters 2012-09-07 08:54:38 UTC
I was pondering about this issue the other day not knowing/remembering that this bug had been filed already. It is bogus that default="" is applied to all <track>s together. It should be grouped depending on kind="" as follows:

subtitles, captions: allow 0 or 1 with default=""
descriptions: allow 0 or 1 with default=""
chapters: allow 0 or 1 with default=""
metadata: allow 0 or more with default=""

Since the author might use different metadata tracks for different purposes and the browser can't know what they are, it makes sense to allow several default metadata tracks.
Comment 2 Ian 'Hixie' Hickson 2012-09-11 16:30:16 UTC
Yeah, comment 1 seems reasonable.
Comment 3 contributor 2012-11-23 07:46:59 UTC
Checked in as WHATWG revision r7528.
Check-in comment: Make the <track default> element restrictions make more sense
http://html5.org/tools/web-apps-tracker?from=7527&to=7528