How is a "forced" subtitle track identified so that a UA may determine if one is present and select it?

(In reply to comment #1)
> How is a "forced" subtitle track identified so that a UA may determine if
> one is present and select it?

In-band "forced" tracks are identified in a format-specific way (eg. with metadata). I am proposing that we add a new @kind="forced" to the track element so authors can identify them in the markup as they do with other types of tracks.

I wasn't aware there were so many different categories of subtitles:
http://en.wikipedia.org/wiki/Subtitle_%28captioning%29#Categories

However, it seems that the general distinction is between "forced" and "narrative" subtitles. I think it is appropriate to define a @kind="forced" or @kind="forcedSubtitles". It seems to me that the other categories are covered by these two. It also seems to me that it's possible to have several forced subtitle tracks in the same language required to be on (see the "forced" and the "titles only" examples in the above link). So this is different from normal subtitle tracks.

How is the browser expected to identify the language for which it has to display forced subtitles? Would that be the language setting of the browser? Would we continue to have @default on such tracks in case the browser doesn't know which language track to choose?

[Aside: I noticed there are 3D positioned subtitles - might this be something that we need to consider introducing into WebVTT?]

(In reply to comment #3)
> I wasn't aware there were so many different categories of subtitles:
> http://en.wikipedia.org/wiki/Subtitle_%28captioning%29#Categories
> 
> However, it seems that the general distinction is between "forced" and
> "narrative" subtitles. I think it is appropriate to define a @kind="forced"
> or @kind="forcedSubtitles". It seems to me that the other categories are
> covered by these two. It also seems to me that it's possible to have several
> forced subtitle tracks in the same language required to be on (see the
> "forced" and the "titles only" examples in the above link). So this is
> different from normal subtitle tracks.
> 
> How is the browser expected to identify the language for which it has to
> display forced subtitles? Would that be the language setting of the browser?
> Would we continue to have @default on such tracks in case the browser
> doesn't know which language track to choose?
> 
 I believe it should be the language of the video's primary audio track, because forced subtitles are enabled in a situation where the user can presumably understand the dialog being spoken in that language (they have not indicated a preference for captions or subtitles).

> [Aside: I noticed there are 3D positioned subtitles - might this be
> something that we need to consider introducing into WebVTT?]
>
  Lets wait and see how popular that is. Forced subtitles are already widely used, so I think we need to deal with them now.

(In reply to comment #4)
>  I believe it should be the language of the video's primary audio track,

How does the browser know what language that is?

(In reply to comment #5)
> (In reply to comment #4)
> >  I believe it should be the language of the video's primary audio track,
> 
> How does the browser know what language that is?

From metadata in the media file.

Eric, Edward: are you ok with the resolution in bug 23507#c36 ?

Essentially the idea is that a forced subtitle track is marked as @kind="subtitles" with a @default attribute. If there are several in different languages, then the @default attribute needs to be set accordingly (either by the browser for in-band tracks or by JavaScript for <track> supplied tracks).

Note that Ian's latest changes to bug 23507 have been cherry-picked into HTML5.1:

https://github.com/w3c/html/commit/a4e6c4acbc814e2fe2af4d4d1163e3b5f6f6195d

(In reply to Silvia Pfeiffer from comment #7)
> Eric, Edward: are you ok with the resolution in bug 23507#c36 ?
> 
> Essentially the idea is that a forced subtitle track is marked as
> @kind="subtitles" with a @default attribute. If there are several in
> different languages, then the @default attribute needs to be set accordingly
> (either by the browser for in-band tracks or by JavaScript for <track>
> supplied tracks).

I am not happy with that resolution, it assumes that the client and script won't select an alternate audio track after the file has been opened. This isn't a problem for the UA, which knows which in-band tracks are forced so it can enable or disable caption tracks as appropriate, but a script has no way of knowing which tracks have "regular" subtitles and which are forced so it can not handle forced tracks correctly. 

Additionally, a track selection script may wish to treat forced subtitles differently (eg. not include them in the menu by default, put them in a different section of the menu, etc), but this is also not possible unless it can identify them.

HTML5.1 Bugzilla Bug Triage: 

This bug constitutes a request for a new feature of HTML. Our current guidelines, rather than track such requests as bugs or issues, is to create a proposal for the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG (https://www.w3.org/community/wicg/). As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process (https://wicg.github.io/admin/intent-to-migrate.html).