W3C home > Mailing lists > Public > public-html-media@w3.org > April 2014

Re: [MSE] Resolving Bug 24370

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 6 Apr 2014 15:55:21 +1000
Message-ID: <CAHp8n2kc0YN=_oMyR_nfEQz8bJHzWPo+cX2Q+4JkxVTREDkwdA@mail.gmail.com>
To: Jim Ley <jim.ley@gmail.com>
Cc: Aaron Colwell <acolwell@google.com>, "<public-html-media@w3.org>" <public-html-media@w3.org>
On Thu, Apr 3, 2014 at 12:20 AM, Jim Ley <jim.ley@gmail.com> wrote:
> 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.

Every show should have its own subtitle track. In particular when a
new language track starts. It makes no semantic sense to put them all
in the same track. In particular if I am an English speaker and
suddenly there is a new piece of content and it is on the same track
that I have continued to watch, but it's in a language that I do not
understand. Give me the chance to continue having the English track -
if I want a different language, I will go and pick it. If there is no
English track availaable, the browser may pick a language track that
best meets my preferences.

Maybe what needs to be pointed out is that the Web is different from
TV and that we should not bring poor practice to the Web simply
because there was no different option do it better on TV.


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

We could add a sentence to the spec clarifying that semantically
completely distinct entities in a long-running stream should be
represented by different tracks. That might be the best outcome of
this discussion.


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

@kind actually includes audio descriptions.

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

I don't follow. I think you're misinterpreting the spec.

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

Exactly. This is why we don't want to make it mutable.

The UX is the displayed track. If the track that I am watching and
have selected for watching changes its core properties under me, that
is really poor UX and is therefore not allowed.

Just imagine a person watching a video with described audio track in
English activated, because they are blind. Now, suddenly, you change
that into a "commentary" track in Russian and the user has to go
hunting for the audio description track in English. I don't think
that's acceptable.

Hope that helps understanding the issues.

Cheers,
Silvia.
Received on Sunday, 6 April 2014 05:56:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:02 UTC