Media feature for viewing distance


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

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

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



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 “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 and )

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



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.


  • 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


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


Sorry I was mainly bikeshedding/still asking a question. I’ll prefix with :bike: in future :D.

I don’t have any immediate need for light level really and certainly I can’t imagine many use cases for very granular lumen levels besides perhaps an always on photo frame that was web driven (Something like: even then I wouldn’t need anything lumen specific just perhaps a little more granular. I’m sure there will be web enabled projectors one day too.

The reason I was mostly asking is that it seems like letting browsers implement their own interpretation of the light levels will never get consistency, could the spec perhaps specify roughly what the lumens each washed, normal and dim relate to?

Also it does feel a little like the fight with view ports having poor sensors is obviously a problem, if the browser made it clear that sensors were unreliable devices would be forced to fix perhaps? :bike:

The more I think about it “passive interaction mode” makes sense more as a mode where the device could enable always or other devices could choose to be in passive when the users eye isn’t looking at it. I’m thinking of my watch and it’s certainly more than a boolean state:

  • Not looking at it
  • In my peripheral vision
    • Useful for heads up notifications
  • Directly looking at it

I’m not sure if distance doesn’t apply to fixed screens either, for example my sat nav screen is a similar size to a normal phone but the viewing distance means that I am likely going to be upset with phone sized text. My girlfriend might get in the car and then expect the text to be a touch smaller because she is closer to the steering wheel. (It’s a bit of a contrived example as it’s the first I could think of but assume I’m 14ft and she is 4ft and it might be less extreme :smiley: ). In this example would you expect media queries to be used to modify the viewport size?


MQs never modify the viewport size. Devices need to modify their viewport size more intelligently, though.


Sorry to bump this old thread again. It just came up in search and I want to throw in a couple of points.

I agree with Jonathan, that this is not just an issue of default viewport size for the device. The problem IMHO is that you are assuming that the nature of the device is an adequate proxy for its viewing distance, and Jonathan’s use case of using a TV as a computer monitor shows that that is not necessarily the case.

Devices can be used at a variety of distances - right now I have a monitor about half a metre in front of me but another one across the room is displaying a dashboard which I can also clearly read. Both are standard computer monitors with a similar resolution, and the knowledge of how far I am away from the screen is hard coded into the application that is displaying content on the screen, not the screen itself. I think expecting devices to present viewport sizes that are scaled to the ‘expected’ viewing distance is likely to never happen.

Second, the choice of layout that a developer would make for a small viewport will depend on whether that small viewport is a physically large screen that is far away, or a physically small screen that is close up. At the FT, this distinction is exemplified by our Next FT mobile/responsive site vs our Big FT billboard site. Same virtual viewport size, different layout.

This distinction could potentially be explained by the fact that we are bundling other media property assumptions into these products too: interactive vs non-interactive, for example (which certainly correlates, although not perfectly, with viewing distance).