RE: [media] Moving forward with captions / subtitles

David Singer wrote:
> 
> 
> On Feb 17, 2010, at 22:42 , Silvia Pfeiffer wrote:
> 
> > On Thu, Feb 18, 2010 at 4:49 PM,  <philipj@opera.com> wrote:
> >
> > I think Eric has already considered using this API for both, tracks
> > embedded and external to the media resource. Also, in MPEG there is
> > the construct of groups, too. So maybe we need to introduce that in
> > the API somehow?

All,

I am increasingly becoming worried about the reliance of client side
scripting in these messages/suggestions/proposals (as I am reading things
- correct me if I am wrong).  Regulatory compliance here is quite clear;
today critical functionality must be maintained when client side scripting
is not supported (WCAG1, Section 508). If the API enhances or improves the
ability to do key functional things, or allows for alternate behaviors and
'style' considerations great, but anything beyond that is going to receive
a fair bit of pushback from certain quarters.


> 
> 
> It seems to be that if a trackgroup represents an optional feature (e.g.
> "captions"), then
> 
> a) the expression that says whether the trackgroup as a whole is wanted
> or not, should be, well, at the trackgroup level (a media query)
> b) *which* of the trackgroup you want should be expressed by attributes
> on the enclosed tracks.

Thumbs up on attributes, as they are processed not by script, but by the
UA (no?)


<snip and insert>

> * If there is a @enable attribute, the track is enabled - if there
> isn't it's not.
> -> in a trackgroup only the first such track is enabled [1]
> 
> * If the track matches browser preferences (e.g. auto-enable all
> tracks with role "caption" and lang "en") then the track is
> auto-enabled by the browser.
> -> only the first such track in a trackgroup is enabled [2]
> 
> * Further the track can be enabled through a javascript call like:
> video.tracks[1].enabled = true;
> -> if such a track is part of a trackgroup, this will disable any
> other enabled track in that trackgroup [3]

OK, so I am a little (lot?) confused. In an off list email I asked Silvia
a question about <tracks> inside and outside of the media asset, and about
order of precedence. The above confuses me even more: is @enabled an
attribute for tracks both inside *and* outside of the media element? When
I asked about precedence, the answer I received was that all tracks
ultimately would be exposed in the UI - both those inside (extracted by
the JS API) and 'hard coded' into the page.  In [1] above, which is
'first'? If I have a track burned into the media that is 'enabled', and
another track that is hard-coded in the web page that is 'enabled' - well,
you can't have 2 can you? Which one wins?  In [2] it seems a little
clearer to me, as the user should ultimately decide - but here I raised a
second question: what if there are 2 very similar but yet different
'tracks' that meet those basic criteria "caption/EN", where the first one
is 'burned in', and the second, slightly modified version is referenced
via hard-coding.  They are sufficently different, yet tagged the same. Now
what? And in [3]... well back to my concern about client side scripting...
and what if the original source file has "captions/EN" enabled, but the
page author specifies "captions/SP" enabled...?

I've been encouraged to ask these questions more openly, so, am I missing
something fundamental here?

JF

Received on Friday, 19 February 2010 02:40:19 UTC