[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 #10 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to Jon Piesing (HbbTV) from comment #8)
> 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.

Good. We have established that we mean the same thing.

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

To re-iterate: there is absolutely no functionality that would only be
available through @controls. Everything is 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)

Yes, that's already possible. YouTube does that with their caption preferences
and many other things purely in JS.

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

See Simon's reply.

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

See Simon's reply.


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

The absence of the controls attribute blocks has no such effect.

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

Received on Tuesday, 18 March 2014 11:41:25 UTC