Define that "TV" should appear as token for UA-string when presentation API is used to render on TV #303

Closed
sicking opened this Issue May 26, 2016 · 6 comments

Comments

Projects
None yet
6 participants

sicking commented May 26, 2016

Mozilla's experience is that the few websites that today target TVs require that a "TV" token is included in the UA string in order for the website to render an appropriate TV UI.

I think this is something that's worth getting into a specification as quickly as we can, in order to prevent the mess that we currently have on mobile. The problem on mobile was that originally there was no token to indicate "mobile device", which lead to websites solving the problem with perpetually out-of-date databases, harder for new players to enter the space, etc.

At the very least, we should define that when implementing that 1-UA mode, the implementation should use a UA string apporpriate for the target device. So if using 1-UA mode to stream to a TV, the "hidden iframe" running on the controller device, should use a UA-string appropriate for TVs.

But I think it would also be good to include an informative note that when implementing the presentation-side of the presentation API on a TV, to include a "TV" token in the UA-string.

Contributor

mfoltzgoogle commented Jun 13, 2016

This sounds like a workaround for a lack of CSS media queries for some document properties that might hold true when rendering on a presentation display. What is a "TV" though? Is it defined by screen size? Pixel density? Typical viewing distance? Input capability (or lack thereof)? Presence of HDMI inputs and a tuner?

Consider the following cases:

  • Someone who uses a 81cm (32") or larger TV as a computer monitor on their desk
  • A projector with smartboard or stylus input
  • A laptop/PC connected to a TV by a wired HDMI connection as a second monitor

Would these cases count as "TV" for the purposes of User-Agent? I'm not opposed to this outright, I just want to be as concrete as possible as to when it applies, and then understand if that would make sense to Web developers.

Contributor

mfoltzgoogle commented Jun 13, 2016

This proposal would solve the problem that a document doesn't know for sure it's a presentation until the connectionList promise is resolved, and so would have to delay style decisions until that point.

If we simply say that the receiving user agent should include "TV" in the UA string for the receiving browsing context, that would seem to avoid tricky questions about "what is a TV."

Contributor

tidoust commented Jun 14, 2016

Doesn't the presence of the receiver attribute on navigator.presentation convey the same information?

anawhj commented Jun 14, 2016

Most of smart TVs has the customized UA string for TV device, so I think the condition which determines whether it's TV or not, seems not to be defined.

For one thing, chrome browser on LG webOS TV has the userAgent string value as follows.
Mozilla/5.0 (Linux; NetCast; U) AppleWebKit/... (KHTML, like Gecko) Chrome/... Safari/... SmartTV/7.0

Contributor

tomoyukilabs commented Jun 21, 2016

One of differences between display and TV is that overscan is typically applied to TVs. TVs in overscan mode hide a 5% margin of a picture and show the rest in full screen.

Generally, TV app developers should be careful that UI could work properly whether a TV would be in overscan mode or not. (It is unnecessary for displays, though.) For example, pictures could be displayed in the full range of 1920x1080, but active UIs should be placed on the action-safe area (the inner area surrounded by the 5% margin). IMHO, including "TV" in the UA string could help web apps to control UIs by JavaScript in this manner.

Note: Android TV has the similar guidelines. https://developer.android.com/design/tv/style.html

anssiko added the v1 label Sep 7, 2016

Contributor

tidoust commented Sep 26, 2016

See discussion at TPAC

PROPOSED RESOLUTION: For #303, add a note about feature detection through the receiver attribute, no guideline on the UA string.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment