Media feature for viewing distance

Possible values:

• close, handheld, mobile, …
• desktop, laptop, …
• far, tv, …

E.g.

@media (distance: far) {  
    /* increase text size here */
}

Would this make sense?

That’s already baked into the definition of “viewport” and CSS px - a device’s viewport should be sized to a number of CSS px such that the px takes up a viewing angle of approximately .0213 degrees.

Ah gotcha. I wonder if smart TVs honor this rule. I fear they don’t. PPK complains in a blog post that a Samsung smart TV has a viewport width of 1280px which is “way too high” and that ideally it should be around 768px. The viewport sizes site reports 1280px and even a 1920px value.

How can we deal with this issue in our CSS (and HTML) code? Is there a way to target smart TVs and force a zoom-in that effectively emulates a 768px viewport?

Not really, no. MQs are purposely designed to discourage this kind of device-sniffing in favor of device-agnostic capability testing. If a browser has too large of a viewport for its anticipated viewing distance, it’s simply badly designed, and there’s not much you can do about that.

the behavior of TVs should, in my humble view, be similar to that of browsers on mobile/tablet devices.

by default, the browser is free to choose some viewport size that the manufacturer believes shows the majority of sites in a reasonably ok fashion (e.g. on phones, it’s around 900-ish px. TV manufacturers seem to think that 1280px or even full 1920px is the best initial way to go).

however, if viewport meta (or @viewport) is present and set to width=device-width, TV browsers should switch to an “ideal viewport” which would be much closer to the CSS reference pixel http://www.w3.org/TR/CSS21/syndata.html#length-units

This ideal viewport will depend on the physical size of the TV (e.g. whether it’s a 30" or 50" TV) and the average viewing distance (usually touted as 10’ / ~3m…the “ten foot experience”).

i’ve made a rough ideal viewport calculator here based on the CSS reference pixel calculations http://patrickhlauke.github.io/web-tv/ideal-viewport/

of course, this assumes that TV manufacturers / OEMs will customise the browser’s ideal viewport for each model based on its diagonal screen size. this may or may not happen. also, this raises the issue of what set-top boxes, consoles, etc should do, which don’t have knowledge of the actual physical dimensions of the display they’re attached to. in these situations, however, i could envisage a step during the STB/console/etc setup process (see for instance Google TV, which - on first run - lets you exactly tweak the visible part of the viewport/safe areas to ensure your content isn’t cut off by a shoddy TV…a similar step could be included that asks users to choose out of 3-4 possible lines of text at different sizes to pick the most legible, and extrapolate from that).

in answer to “How can we deal with this issue in our CSS (and HTML) code” … well, currently, TV manufacturers etc have apparently been living under the illusion that “developers will build a separate TV version of their site for OUR device”…i suspect this is a side effect of having walled gardens like HbbTV and (web-based) TV app stores (like Opera TV Store for instance), where devs are effectively forced to make a custom version. but for the “wild” web it’s simply ludicrous to think that all but the largest sites (and even there it’s often doubtful) will do some form of UA sniffing and then redirect to a “TV optimised” version. (echoes of old “dot mobi”/“m dot” sites…including same arguments “people don’t want the ‘full’ site on their TV, they just want video and pretty pictures”). (see for instance “Redirecting TV users to the right version” on https://developers.google.com/tv/web/docs/implement_for_tv#architecture)

related: https://bugzilla.mozilla.org/show_bug.cgi?id=1015872

some additional thoughts: having a media feature that simply says “tv” or similar risks repeating the same mistake that media types made, trying to neatly categorise devices into broad buckets of “screen”, “handheld”, “tv” etc. device boundaries are far more fluid than that. true, one of the big problems with media types was also their mutually-exclusive nature (a device can’t react to more than one type at the same time) and the fact that - through cargo cult, or simply ignorance - a lot of web content still uses “screen”. TVs already had to adapt to this and ignore media type “tv” as otherwise most web content would simply be unstyled (same as mobile/tablet browsers ignoring “handheld”).

see also http://dev.w3.org/csswg/mediaqueries/#media-types “Unfortunately, media types have proven insufficient as a way of discriminating between devices with different styling needs”

curious side-note: the only browser i’m aware of that reacts to media type “tv” is the original Opera-based Wii browser, but even here it uses heuristics: if there is any “tv” stylesheet/@media block present, it will react to that. otherwise, it will be a “screen” device (see https://twitter.com/g33konaut/status/452551318683803649/photo/1 and https://twitter.com/g33konaut/status/452751113369157632/photo/1 )

with media features at least, it wouldn’t be mutually exclusive…but the problem of being overly broad remains. it’s better to stick with granular, discrete features (for instance, i could envisage some media feature to say that the browser uses d-pad-style controls, for instance).

Hi

Rather than create a new thread thought it made sense to continue this one on.

I was just reading “Media Queries Level 4” and was disappointed to see their still doesn’t appear to be a way to properly recognise the kind of device that a user is using. Without a way to recognise that the user is using a TV in some way we are unable to provide them with the optimum experience when using our site, we know that when a user is using a TV that they are:

• far away from the display
• likely using a remote control of some kind

With this knowledge we can then enhance our interfaces to work best under these constraints, then if the browser supports further features we can then progressively enhance for them. For a TV I would want to make many of my elements bigger and easier to interact with, without a way to distinguish between a TV and Desktop browsers I can’t do this.

You mentioned that we have had issues in the past with TV manufacturers however I would hope that now we are seeing a convergence of smarttv platforms such as android TV we will see more standardisation across the industry and our web specifications should be supporting this from a web point of view.

How do you respond to this?

This is theoretically handled by the ‘pointer’ media query - a remote is definitely a “coarse” pointer, so your buttons should be large. If there’s more we can provide, we’d like to know about it.

We definitely dont’ want to expose the device type itself, because that’s meaningless; if I’m using a TV as a 4k desktop monitor (totally reasonable), it should act like any other monitor. I definitely don’t want any silly TV styles in that case. This is why we’re providing more granular MQs to replace the old and busted “media type” concept, so you can style based on what you actually care about.

So when it comes to responding to “Far away from the display” you respond by providing bolder and clearer call to actions.

If we take the example of the iPlayer application the web based tv guide looks like this

Its really functional, works really well but its built for using on a desktop where you are up close and can clearly see all the different interactions. Imagine viewing that on your TV however and it wont work as well as it is harder to see everything that is going on. The BBC have solved this problem by building dedicated Apps, take the PS3 app for example:

Everything is bigger and bolder, it is showing similar information but it is bigger so it can be seen better from a distance. Its this that I want to be able to achieve without a native app, I want to know someone is using a device which they are not up close and personal so I can adapt my sites to work better by increasing text size, adding bigger and bolder call to actions.

This is really important for us being able to build responsive sites, responsive no longer should be about catering for mobile, tablet and desktop. Its about progressively enhancing our sites to work on any device and as I hope I have pointed out, the TV is currently being let down by us in terms of what we could do with it.

We can’t assume that our TV’s will always be paired with remote controls so from a spec point of view we couldnt assume they are using a TV based upon their input method.

Take the example of the Sony X9005B, it comes with a traditional up down, left right controller but it also comes with a remote control that uses a trackpad which could therefore be seen as a ‘fine’ pointer. If we only increase button sizes for “coarse” pointers then users of a TV that uses a “fine” pointer will not be getting the refined experience that we are trying to offer them.

I understand we don’t want to expose the device type itself because you are not only relying on vendors to properly implement them (which historically they haven’t) but also we have no idea what new devices will come out tommorow that we will have not added support for in our spec. Your point about a TV being used as a desktop monitor however doesn’t make sense as as soon as its plugged into a desktop it is using the desktop browser running on the computer, rather than using a TV browser, or games console browser. By this I mean the way in which the software chooses what the device is changes because the context is different, it is very unlikely in that scenario you will be using your TV’s built in browser.

So having ruled out pointers, and ruled out exposing a device type a couple of ideas spring to mind:

context media query - a media query that allows us to understand the context of the device and what it is used for, is it a personal device used up close or is it a display that we sit away from and perhaps share with others

distance - a value for expected physical distance from the display the user is expected to be, this could have a sensible default for different device types but potentially be configurable in a browser setting

I prefer the idea of context as they can be device independant yet provide us with context about how the user might use a device which could help us provide better context based experiences.

Thanks for the examples! This is literally just “large vs small viewport”, though. A TV might be huge, but with a similarly large viewing distance, may actually present a much smaller viewport (in CSS px, which are technically an angular measure) than a monitor. No additional MQ is needed here; you’d present similar UI to a tablet user.

(Now, TVs might not present an appropriately-sized viewport, but that’s just a bug in their browser implementations. We don’t add features just to work around bugs; it’s simpler for everyone if the bug is just fixed.)

A trackpad is indeed a “fine” pointer; what difference in “refined experience” does this present? The coarse-pointer TV would just get larger buttons. If you’re basing a bunch of unrelated UI decisions off of pointer:fine/coarse, you’re doing it wrong and will be giving people bad experiences.

The software is irrelevant. My point is that the correct display for a TV is entirely dependent on use. You seem to understand this, but are dismissing it somehow as a software difference, rather than as a usage difference. If I run my desktop browser on my TV (and set things up so that it has a proper viewport size, etc), I should be getting the same experiences as a “TV browser” or “game console browser”. There’s no difference in environment.

Again, this is just a matter of viewport size. You don’t actually care about how far away the person is, you care about how large the screen is in their field of view, which, when set up appropriately, is automatically handled by scaling the px unit appropriately and sizing the viewport accordingly. Based on a rough eyeballing from my couch, my TV’s viewport should be about 1000px wide; that’ll give a px size similar to my laptop.

As I’ve said before, there might be more context that could be usefully provided. For example, you mention “share with others” - if this is a useful bit of information that authors would cause authors to change their page style, we can think about adding it as media query.

I disagree that this is about viewport because you might not want to render the same interface on a tablet as the TV even if they have the same viewport size. This could be for many reasons:

• You might be optimising the tablet experience for how you would interact with it with touch, this can effect the look of the UI
• The context of use is different, the way you would use a website on a TV is very different to how you would want to use it on a tablet - see how BBC do iPlayer on iPad for example.

I was replying to your suggestion that you would make buttons bigger for a coarse pointer, but on a TV with a “fine” pointer because of the viewing distance you would also need the larger buttons to make them clearer from being further away. This is why I wouldnt want to target large buttons using the pointer media query if my intent for them is for TV users (of course you should do this for other course input types, but in the example of TV I always want them to be big)

If you are using a 40 inch 4k tv up close as a monitor vs using it as a TV you wouldn’t want to get the same interface as when using the TV as an actual TV. By plugging it into your computer it is working just like any other monitor, your up close so the viewport can be bigger because you wouldnt be expecting to get a mobile or tablet experience, you would expect the full desktop experience, you wouldn’t want it to work like your TV browser or game console browser because the context in using it is different.

When reclining on your sofa however your in a different frame of mind, and the way you interact with content is different, typically these would be quick interactions so the interface needs to be able to reflect this. As mentioned earlier, this cannot be achieved with just viewport alone

It is this context that matters, even if you are using the TV on your own, the fact that its a device your viewing from far away gives it a very different experience than a tablet which is up close and feels a lot more personal. Both could have different interfaces, and they should.

What’s the difference there? We suspect there’s a use for a MQ for how easy it is to scroll or otherwise interact with the screen, for instance; remotes are hard to use, touch is easy. Is that what’s being captured there?

I don’t have an ipad, so I can’t see this in action. What’s the important differences there?

You need large buttons even for a “(pointer:fine)” TV because the TV screen is small at standard viewing distances. That should be reflected in the viewport size, and the size of the CSS px, so creating a reasonably-sized button for a normal monitor should also make it reasonably-sized for a good pointer on the TV. Like I said in my earlier message, my 40" tv is actually only about 1000px wide. (And my living room is small and thus the TV is closer than normal; it’s very possible that it should report itself as 800px to be good for “standard” viewing distance.)

In other words, if you need to oversize your buttons to make them good for a TV with a touchpad, it’s because the TV browser is not setting up the px size properly. If it was, a standard button would be big enough.

Yeah, that’s possible. It would be interesting to figure out how to phrase a media query for capturing this distinction. I wonder what else might want to do it? Like, video games should present the same UI for TV and monitor; the distance of the screen doesn’t really make a difference. Is it really just television (and its equivalents) that need it?

So what they do is optimise the experience based upon how you would use the app, the Tablet you might scroll through swipe through lots of content to find something that appeals, where as with the TV app they seem to expect you to know more about what you want to watch.

###Tablet

• Swipe through content
• Text is smaller as you are close to device
• Takes advantage of gestures to swipe content, while this is a functionality difference it effects how it looks
• Buttons are medium sized, just right for clicking on

###Tv

• Step through content,
• Text is big and bold
• Buttons really big and bold
• Bigger iconography

Part of the problem with this is we have to imagine devices that havent been invented yet and plan for them. Technically all devices have a context of use BUT we currently make assumptions of context of use based mainly on viewport size. Perhaps something that stops us assuming context would be useful

Much like the light-level media queries does leaving the manufacturer open to implementing the meaning of ‘far’ and ‘close’ make sense.

Does leaving open the meaning of such values much like (‘dim’, ‘normal’ and ‘washed’) allow for better alignment or end up in vendor hell?

I have come accustomed to expect absolute units like (x meters, y cm) and (y lumen, 80% washed) but perhaps adding units like this add very little meaning.

Another thing to mention is that part of the problem with all of these is that the definition of far and close would need to be clearly defined in the specification to stop them being open for interpretation by the manufacturers. 2 ft could be far for some manufacturers but close for others.

@jonthanfielding +1

@tabatkins was there any motivation for light-level to not be specific units at all?

Yeah, devices in the wild report wildly varying lumen levels for the same light level; actual lumen sensors seem to be all over the place in terms of calibration.

I was thinking that might be your answer.

Could those issues both for lumen and distance be resolved by using averaging and thresholds windows?

So similar to how server alerts generally work to average out peaks in CPU usage but alert when after a window of x seconds and the average is over y.

So perhaps:

@media (light-level: 1000lm avg 5s) {
  p { color:#000; }
}

@media (distance: 1m avg 5s) {
  p {font-size: 4em;}
}

Can you justify why you need that at all? The other reason we omitted lumens is that there’s doesn’t seem to be any need for it; even if every device reported lumens correctly, there’s really no reason to have light-level information at the lumen granularity. The three categories we defined seem to capture all that you need to actually respond to - normal light, low light, and bright light. There just isn’t anything you can usefully adjust at a higher granularity than that.

(It also means you don’t have to go research what lumen levels actually mean, since I doubt very many people know off the top of their head how bright 1000 lumens are. ^_^)

The problems with viewing distance are separate, and have already been discussed - viewing distance just isn’t a useful thing to ask about. It’s being used as a proxy for a few other types of things, and if we want to address those, we should do so directly. Using indirect variables just means you’ll react incorrectly when the things you’re measuring don’t perfectly correspond to the things you’re trying to respond to.

In particular, “far” viewing distance is really just a proxy for “probably interacting more passively” - it’s a user interaction mode you’re trying to detect/respond to, not the distance from the screen.