Re: [MSE] Resolving Bug 24370

On 2 April 2014 09:26, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

> On Wed, Apr 2, 2014 at 6:04 PM, Jim Ley <jim.ley@gmail.com> wrote:
> >
> > Isn't the use case for language being mutable simply live subtitles of a
> > live "channel" that has programmes in different languages and therefore
> has
> > closed captions / subtitles in different languages.
>
> Each one of those subtitle languages would be a different track, so
> there is no need for mutability.
>

No they're not, some shows are in English, some are in Welsh, the subtitle
track is a single one for the live broadcast, similarly with audio, the
broadcast audio changes languages.

I agree, there should be long-running streams. However, that doesn't
> mean that there can't be new tracks coming and going. Every time there
> is a change in language and a track of that language hasn't been
> created yet, there should be a new track. It makes semantic sense to
> keep such tracks separate.
>

I can see that argument, but the spec would need to say that instead,
simply making them non-mutable doesn't meet that use case.  I don't also
see it really solving the UA and user issues that were raised as the
motivation for not having mutable, but certainly it would solve the use
cases.


> Right, the app developer can change the value of the attribute, though
> I don't know what the use case would be, since nothing is going to
> happen in the browser as a result of this change of value, so it's not
> very useful.
>

Well it's very useful if you have built something on top of the track
metadata to provide the user with a choice - language and kind is not
actually enough for that (how do you identify which is the Audio Described
version) to it will be have to controlled out of band anyway, but the point
was, the spec already requires it to not be read only from a track list, it
doesn't seem to be any value in not having mutable from elsewhere.

You misunderstand: right now, nothing happens when the value of
> language is changed. However, for the use case of in-band tracks
> discussed here, we would need to introduce complicated changes that
> have to deal with a change in language - something that is NOT yet
> part of the spec.
>

Why?   If the language of a track changes, the language of a track changes,
you can't say you have to do some UX change for  it when in band when you
don't for out of band.  There's no distinction.

Jim.