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

On Mon, Dec 12, 2011 at 6:35 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Mon, Dec 12, 2011 at 12:59 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>>
>> I suppose that the way in which the spec is currently written only
>> requires during loading of the text tracks that only a single track is
>> "showing". There is no statement about what happens when the user
>> activates a different track of the same kind. In particular it doesn't
>> say that when a track is newly "showing" that every other one that was
>> previously "showing" should now be hidden. However, I am pretty sure
>> that that was the intention.
>
>
> I don't see anything in the spec suggesting this.  It would be unnecessarily
> limiting.

This is quoted from
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#sourcing-out-of-band-text-tracks
:

"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.


> 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 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.


>> My preference is actually on the latter. If anyone wants more than one
>> track *of the same kind*  to be "showing" at the same time,
>
>
> It's perfectly reasonable to allow showing subtitles in two languages
> simultaneously, or two separate tracks in a single language, eg. Japanese in
> both kanji and transliterated forms.  (People seem to like doing this for
> songs.)

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.

>> I recommend they use metadata kind tracks.
>
>
> Unless it's actually a metadata track, this would be intentionally
> mislabelling the track.  Anything that encourages people to do that should
> be avoided.

Fair enough.

> Also, metadata tracks aren't rendered, so this wouldn't work, even as a
> hacky workaround.

It would require the developer to display it. But yes, agreed, it's hacky.

Cheers,
Silvia.

Received on Monday, 12 December 2011 08:06:17 UTC