Media feature for viewing distance

#20

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.

#21

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: https://www.electricobjects.com/) 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?

#22

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

#23

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

#24

Again, the viewing distance is an indirect proxy for what you’re actually asking for, which is something about how the device is being used:

Someone using a wall projector as their primary monitor will have a large viewing distance, but is interacting actively with it. Pages should act the same way they would for a “normal” desktop monitor. In Jonathan’s earlier example, the meaningful metric is not viewing distance, but viewport size - a TV on the wall should have an adjustment that reduces its viewport size, relative to the viewport size when it’s used as a desktop monitor.

Your FT example (thanks for bringing it up, it’s great!) is similar. As you say, viewport size isn’t enough to distinguish this - the Big FT is meant for low/no user-interaction displays, while the Next FT is a normal website designed for smaller viewports. So expected user-interaction is what you want to respond to there.

As far as I can tell, there is never a need to know how far away the user is. There’s other variables you actually need to know. Some are expressible today, but TVs are terrible and don’t report them “correctly”. Others need to be developed, like how the user is expected to interact with the device (which is something that needs to be settable by the user, just like they need to be able to scale the viewport to reflect the viewing distance).

#25

This idea is just as bad as using break point dimensions in an environment where pixels aren’t pixels. We don’t currently know when those break points match with hardware pixels or not. We won’t really know if a specific device is far or close, ever, unless we’re using something like Hololens.

In my humble opinion, something better to give us would be full control over pixels, then we can make decisions that are more accurate. For exampe, we could detect physical size of a device, and therefore probably assume that a device is a phone if the dimensions are 2 inches by 4.5 (real-world) inches. We can automatically (try to) associate a “close” keyword with a matching set of device sizes.

The question of close vs far is kind of hard to determine. What if it’s a big touch screen (like the ones Microsoft puts in the malls in front of their stores) that are meant for the user to be right in front of, up close, touching. The display is huge, and the user is close (but sometimes far when the screen saver is on and the user isn’t up close touching). It’s just not really possible to determine far vs close.

On the other hand, if we know we can make something be exactly some number of real-world inches in size on the display, and we know what use-case and platform we’re targetting (for example, a movie screen far away versus a large touch-display meant to be used up close), then real-world size units will get us further.

#26

Seriously, quit spamming your “give us access to hardware pixels” idea to other threads. It’s not even remotely relevant here.

#27

You’re wrong. Yes it is, and hence I posted here in relation to the topic here.

#28

If you can explain how hardware pixels have anything to do with viewing distance / interaction mode, great. If not, keep it to its own topics.

#29

Because if we had the ability to design things based on the hardware size (in physical units) and pixel density of a display, then we’d be able to better approximate experiences meant to be “far” or “close”. The ability to say we want “this when far” and “that when close” is related to the pixel density and size of the display, because if we were able to know the physical size of a display, we could better guess whether that device is meant to be close or far, although it will always be impossible to know for sure.

I’m also saying here that knowing pixel density and physical size of a display, coupled with the ability to present things in real-world units, is more powerful than targetting “close” or “far” (if not complimenting to it), because “close” or “far” isn’t necessarily meaningful without the physical size of the display and an ability to design things for a certain size at a certain distance to begin with.

So, even if the physical size or pixel density of a display isn’t exactly the same as “close” or “far”, I’m posting here to show that close/far needs size to make sense.

close/far/big/small/etc are all part of a bigger overall want that we have, a want to be able to know more metrics about a display that we are presenting information on so that we may better estimate how we will present that information.

#30

A large screen might be close up or far away, a small might be close or far away. There’s no relationship. Some of the first examples in this very thread were about TVs, which are often within the same size range as desktop monitors. Other examples were of info screens that can be displayed on small monitors, within the range of tablets.

Even if we pretend that hardware size is relevant, you can get an appropriately close answer by just asking for the size in pixels and assuming that 96px = 1 inch. That’s approximately right (in the absolute worst case, it’s either .66x or 1.5x off), and getting “real” dimensions will not improve the estimation enough to change anything.

(When the device is far away and it’s appropriate to give it a small viewport as a result, the ratio will be a lot more off, but then 1in will be way different than 1 inch, and basing anything off of inches will be almost certainly terrible. You’ll either be making bad assumptions about visual size and creating tiny things, or you’ll compensate for visual size and end up approximating the same work that was already done by the UA when it shrank the viewport and made 1in larger.)

#31

That’s horrible though. The advantage of native frameworks is you can rely on things like 1in actually being 1 inch. This is a powerful thing for a designer who knows what the target medium is. The web has it wrong, and I feel it is this way to “make it easy” for anyone to start writing web apps with basic HTML and CSS (and not necessarily even know JavaScript). But anyways, that’s about all I have left to say on that topic, so I won’t mention it any more in this thread specifically).

#32

and how would you determine the use case and platform? and if you already know the use case and platform, then the “close vs far” question isn’t hard either, no?

#33

Yeah, if you know the use case and platform, close or far can be something that the developer just knows and assumes. In that case, I can fairly accurately make a function that can convert the web’s fake units to real-world units (although it’d be much more elegant if the units were real to begin with).

#34

@trusktr - this is not the “1in is not 1in” thread. This thread discusses viewing distance, which is really not related.

#35

That’s indeed a great example, which also shows it would be useful to be able to know if the interface is meant to be scrollable or not.

Is there anything like “possible interaction queries” in the work somewhere? Something like

@media not (interaction: scroll) {
  body {
    …
  }
}

Or

@media (interaction: zoom) {
  .class {
    …
  }
}

interaction: scroll would be useful for fullscreen interfaces like in games, also, and might help fix the strange behavior of 100vh in most mobile browsers.

#36

There’s the overflow-block media query, which works for the scroll case, at least:

none
There is no affordance for overflow in the block axis; any overflowing content is simply not displayed. Examples: billboards
#37

You’re right, so we need a way for the device to tell CSS there is no scroll available, maybe with the app manifest… But we are out of topic here… :wink:

#38

Wait, doesn’t overflow-block: none do (exactly) that?

@media (overflow-block: none) {
  /* the device cannot scroll */
  /* e.g. styles for Big FT */
}

E.g. on a digital billboard, overflow-block would always be set to none.

#39

What if I put a standard computer on a big TV screen, with a standard browser?