[Bug 24860] When can user agents honor the user preferences for automatic text track selection

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24860

--- Comment #8 from Jon Piesing (HbbTV) <hbbtvjon@gmail.com> ---
(In reply to Silvia Pfeiffer from comment #7)
> 
> Are we talking about Web pages or native TV applications here?

With very few exceptions, the only native TV apps come from manufacturers.
Hence what I mean by "TV app developer" is someone developing an interactive
service offering for a TV set using HTML+JavaScript. 

> > b) they can ensure that the app has control over the VCR-style features,
> > pause/resume, fast-forwards/fast-reverse, jump forwards/backwards. This is
> > particularly critical for broadcasters funded by advertising.
> 

Let me try again. There are at least three reasons why people developing
HTML+JavaScript for TV sets would not set the controls attribute.
1. They don't want the TV set to draw anything that is part of the page because
it would disrupt the user experience and would likely be wildly inconsistent
between manufacturers
2. They rely on video advertising to fund the content/app/service and want to
ensure the end-user cannot fast-forwards through the advert or jump past it.
3. The language relating to the controls attribute is all written as "should".
That basically means it's not testable and experience shows that things which
aren't testable in TVs cannot be relied on to work.

I apologise for being blunt but in my experience any solution that assumes
HTML+JavaScript apps for TV sets will set the controls attribute is simply
irrelevant.

> > That depends on what functionality provided by the UA would be disabled when
> > the controls attribute is absent.
> 
> None. The @controls attribute does not disable or enable any features. It
> only exposes some features visually with buttons and sliders to the user
> that otherwise are only available to script.

There are a several different reasons why this doesn't work in TV ...
- there are gaps in the set of APIs that an app would need to be able to offer
the functionality through script (e.g. reading previously set user preferences
so the user doesn't have to re-enter them)
- the remote control buttons (or virtual buttons) that are used for the UI
offered by the TV are typically hard-wired to the TV and never delivered to the
browser. 
- it is widely felt to give a poor user experience if pressing volume up (or
audio description or subtitle) gives a very different UI (not just colour but
also conceptually) when the user is watching broadcast TV than when the
end-user is watching web delivered video. This isn't an issue with
play/pause/ff/frew/skip (etc) because they aren't used when watching broadcast
TV.

<snip>

> To me, an "app developer" is the person who wrote the Web page and the
> layout and the graphical design in HTML, CSS and Javascript and has made
> sure that all the functionality is there that is required to interact with
> the Web page.

Yes - to me as well.

> If they decide to use @control, then the UA gets to render the
> controls. If they decide to do it themselves, the don't use @control. Is
> that the same "app developer" you are talking about?

Yes this is the same "app developer" but please see the assumptions I mention
above.

I think the issue here is that typical HTML+JavaScript apps for TV will need to
replace some of what is covered by the controls attribute but are not able to
fully replace the rest of what is covered by that attribute and probably would
not want to do so anyway.

If we look at the list of features in the spec for the UI provided if the
controls attribute is present, an HTML+JavaScript app for TV would typically
want to provide the following;
- begin playback
- pause playback and
- seek to an arbitrary position in the content (if the content supports
arbitrary seeking), 
- (Also fast forward + fast rewind which aren't mentioned in the spec)

It would typically not want to provide the following basic TV functionality;
- change the volume
- change the display of closed captions or embedded sign-language tracks,
- select different audio tracks or turn on audio descriptions, and
- show the media content in manners more suitable to the user (e.g. full-screen
video or in an independent resizable window).

Having the absence of the controls attribute block this basic TV functionality
unless the app provides it would (IMHO) be very bad.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 11 March 2014 14:51:53 UTC