[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 #6 from Jon Piesing (HbbTV) <hbbtvjon@gmail.com> ---
>> If it's a reference to the controls attribute then that has numerous issues
>> in a TV environment. TV apps generally do not include the controls attribute
>> to avoid those issues and the subtitle key would need to work when that
>> attribute is not present.

>To avoid what issues?

TV app developers (almost?) always provide their own controls for several
reasons;
a) they get to control the visual appearance (if any) so it fits with the rest
of their UI
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.

>I don't understand. How can you have UA provided controls when you
> disallow the @controls attribute?

That depends on what functionality provided by the UA would be disabled when
the controls attribute is absent.

This may sound cryptic but an example is audio volume control. Audio volume
control would probably work regardless of whether the controls attribute is
present or not.

>Also, if you disallow the browser from creating controls, but then provide 
>your own on top, then it's up to you to expose such a user interface and
> take care of the providing the features that the @controls attribute
> would provide.

I agree 100% but an app has to make assumptions about what features the
@controls attribute would provide in order to take care of providing those
features. Also the UA needs to include the functionality to enable the app to
provide those features. This may not be the case for all possible features that
the UA could provide in which case setting @controls had probably better not
disable those features from the UA.

> "You" being whatever interface u are adding in top of the browser.
> If there is some sort of "middleware" that provides remote control
> mapping to the browser, but is not part of what you call an "application",
> then its up to that part to make sure that the right tracks are 
> activated/deactivated. From the HTML spec's point of view, that's still
> an "application".

This is also true from HbbTV's point of view.

<snip>

>The issue here is that with HTML pages and video elements that have no 
>@controls attribute, you might find that the page author has created the >controls through JavaScript and is rendering them on top of the video elements.

TV apps would normally handle the remote control keys for
pause/resume/ff/frew/jump (etc) themselves.

They may do this without rendering any visible UI though.

> I don't know how you want to handle that in the set-top box case.
> Do you want to disable such controls and render some default controls
> of the TV that include the remote control access?

This would be completely unacceptable to TV app developers for the reasons
given at the start of this comment.

> Or do you want to have the remote control also activate/deactivate
> the subtitles? Both is possible. Neither is disallowed in the spec.

Well the spec can be interpreted as disallowing control of subtitles. Please
see the fragments of the text quoted in the original report.

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

Received on Monday, 3 March 2014 15:11:42 UTC