Re: WebVTT bidi: should a cue be allowed to contain more than one paragraph?

 As a side note, we should be prepared for people confusing "captions" and
"subtitles".  I think we're guaranteed to see a lot of captions marked as
subtitles, because the difference is subtle.  Also, automated conversion
tools are probably not going to be able to set this reliably.  I'm not
suggesting this should be removed--there is a difference, and some movies
do have both captions and subtitles for the same language--just noting an
issue that'll probably crop up.


On Mon, Dec 12, 2011 at 3:05 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> "When a text track corresponding to a track element is added to a
> media element's list of text tracks, the user agent must set the text
> track mode appropriately, as determined by the following conditions:
>
> * If the text track kind is subtitles or captions and the user has
> indicated an interest in having a track with this text track kind,
> text track language, and text track label enabled, and there is no
> other text track in the media element's list of text tracks with a
> text track kind of either subtitles or captions whose text track mode
> is showing
> * If the text track kind is descriptions and the user has indicated an
> interest in having text descriptions with this text track language and
> text track label enabled, and there is no other text track in the
> media element's list of text tracks with a text track kind of
> descriptions whose text track mode is showing
>
>    Let the text track mode be showing.
>
>    If there is a text track in the media element's list of text
> tracks whose text track mode is showing by default, the user agent
> must furthermore change that text track's text track mode to hidden.
> "
>
> I read that as follows:
> When the UA parses a track element and the user wants this track to be
> enabled, and no other track of the same kind is already enabled, this
> track will be "showing" and any other track that has been marked with
> @default will be hidden.
>
> That to me indicates that only one track of a kind will be showing.
>

Only one per kind selected from user preferences--it doesn't say anything
about the UI or API afterwards.

That aside, I think this says too much about how to select a default
track.  The spec shouldn't appear to restrict the UA from using other
methods to select defaults based on user preferences.  (For example, "for
all languages except English and Spanish, show English subtitles if
available, otherwise Spanish subtitles" for users who speak those two
languages.  The above algorithm also doesn't deal with there being both
captions and subtitles for the user's language.)  Disabling "shown by
default" tracks should be normative, but the algorithm above for picking a
user-preference track would be better as an example in a note, as one
approach a UA might use.

It seems wrong that a UA enabling English subtitles via user preferences
causes a default chapter track to be disabled.  I do think that disabling
"shown by default" tracks should be per-kind (with subtitles and captions
lumped together).

> Markup doesn't need to represent every possible state.  Is there a reason
> to
> > want to mark multiple tracks as enabled by default?
>
> The previous example with two tracks in different languages being
> active at the same time is a use case IMO.
>

I don't know why content would want to do this by default, though.  For
that matter, I'm not sure why content should select even a single subtitle
track by default.  Usually, only the UA has any idea what the user wants.
It seems like you'd only need to set a @default for these if UAs have poor
defaults.

@default does make sense for chapters, though.

> I think there is at least for metadata.  You may have separate, unrelated
> > metadata tracks for the same video, driving unrelated scripts.
>
> Yes, another use case. But note that I was focused on "showing" not on
> "hidden" states. Since metadata tracks don't have a default display
> means, they will never be "showing". They will be "hidden" and thus
> loaded into the browser and available to script to do something with,
> but not displayed and certainly not displayed by default.
>

FWIW, I think kind=metadata can be in "showing" like any other track, and
will be in "showing by default" if they're marked @default.  (They'll just
never be rendered, even if set to "showing".)

 It's  a use case, yes. This can lead to an overload of showing tracks,
> though, where somebody has activated, say, 10 tracks of different
> languages and these can't be displayed sensibly in the browser any
> more. I was under the impression that we didn't want to allow that.
> But it's good if we can - we can't always stop the user from doing
> stupid stuff.
>

The UA can also place its own limitations on its own UI.  (Of course, you
can still request unreasonable things via the API, but you can always do
that.)

-- 
Glenn Maynard