Hacker News Reader

Comment by arximboldi | Hacker News Reader

I have mixed feelings about this. I get the point about touch: i.e. the button should have a fixed size in proportion to your finger. However in other scenarios I am not sure size should be constant. In most cases, you have to factor in the distance to the viewer. This is, probably "projection angle in the retina" is a more useful invariant.

For example, in a big TV that is far from you, you want things to be bigger than in a monitor, that is closer. And in a laptop, you probably want it even smaller.

"Design by pixel" takes this into account somewhat indirectly because most display are designed to have their pixel density in inverse proportion to the size of the display, which is also inversely correlated to the expected usage distance. Sometimes technology changes our expectations of definitions and things become small, until designs catch up with the new expected pixel density. We have worked around this problem with pixel density factors on retina/QHD.

I agree that all this in the is a evolutionary "hack". But I am not sure that the proposed solution, even though more rational sounding, actually makes things better.

View on HN

An inch should be an inch. A pixel should be a pixel. A point should be a point which is defined as 1/72 inch.

Those are all physical measurements, meant for the surface of the screen. If you design with them, it means you're designing with the screen size in mind. It's often wrong to design with those measurements.

There are relative sizes too.

%, em (current size of font), and measurements relative to viewports. That's what designers use very often.

So you are saying you would want one physical square inch on a phone to be the exact same size one square inch on a projector screen?

I have been designing and building interfaces for a couple decades and I have been down the "relative size" path and learned not to do that the hard way. There lies nothing but tears. Sizing to pixels, for some reason, results in the most predictable and consistent appearances.

But pixels are a lie!

Pixels are being scaled all over the place these days, up to 300-400%.

The only reason pixels appear to "work" is that everyone uses pixels, so the software has to be written to lie about pixels. And so they continue to seem to work and people continue to use them to size things.

They might as well just call them "screen fractions" or something, because they sure aren't pixels.

You are confusing pixels with points. Points are being scaled, and a simple workaround to accomplish that is often duplication of pixels.

On HiDPI mobile devices, pixels aren't real pixels. They're actually treated like points -- a pixel in CSS ends up being something like 3-ish real device pixels, plus or minus, depending on the device.

Windows: pixels are pixels. Some systems there (e.g. WPF) use also dip units (Device Independent Pixel, 1/96in == 1px in twisted CSS terms). And that's how it should be done in CSS form the very beginning.

MacOS/iOS uses screen units. Each such unit is of N physical pixels. Where N is a number obtained by [ nsscreen backingScaleFactor] function for particular screen (monitor).

> Device Independent Pixel, 1/96in == 1px

That's a point. 12pt font means 12 points.

A point is 1/72". A dip is 1/96".

Even points are a lie now. I open a PDF on my computer, and the PDF viewer might scale it to fit the window, and the OS might scale it based on my preferences, and maybe my monitor is a projector which means the OS has no idea how big the viewing area actually is.

They're not necessarily true pixels anymore, but the effect of using px as the unit of measurement hasn't really changed. You're controlling more physical pixels, but a similar size of the screen.

Actually, the W3C calls it a "reference pixel": https://www.w3.org/TR/css-values-3/#reference-pixel -- other units: https://www.w3.org/TR/css-values-3/#lengths

I believe they are saying that there should be several types of sizes:

    a: Relative sizes (to bounding boxes/etc)
    b: Exact physical sizes (E.G. points which are 1/72nd inch)
    c: Precise device sizes (REAL pixels, not compatibility pixels)

It might be nice to have a way of specifying the minimum and maximum size among those three values, and a priority for fulfilling the min / max request ordering.

Why do you need precise pixel sizes? What if I gave you a 3000 PPI screen? Would you really care to make any feature of your UI be the size of one pixel? Wouldn’t “smallest visible solid dot” as covered by (b) suffice?

Yes, as a gamedev and as someone who has tried to do a lot of fanciness regarding human visual perception, I would love to have the ability to specify "use the absolute smallest, device-sized pixel value."

It's a special case, sure. But those special cases suddenly enable what was previously impossible.

Again, even if you are looking at a 3k/6k/9k PPI display? Even if a single pixel is in no way visible? Isn't there a limit beyond which you don't care?

"not visible" is a very tricky thing in human perception. I'd love a way to subtly mess with someone's eye. And not for trolling purposes. It matters in art.

Me? I don't need that. HOWEVER, I can understand why someone else might.

Mostly these cases revolve around implementing something in program instead of with basic standard features. Some standards even recognize that more complex decisions need to be made and allow for 'shaders' that determine the outcome instead of basic operations.

Providing low level primitives in a responsible interface allows for the corner cases to be approached with nuance and care instead of glaring presence of omission.

> So you are saying you would want one physical square inch on a phone to be the exact same size one square inch on a projector screen?

If they're not the same, then they're not inches.

Right, the argument is that if you want some arbitrary sizes you should get a new unit for it, not inconsistently use an existing unit to mean something that it doesn't.

The current system of pts or inches varying by context would be like if an oven manufacturer said "Well, 60°F is pretty warm, and 90°F is downright hot, so we'll just recontextualize those numbers for our oven gauge. Bake cookies for 10 minutes at 80 degrees.

Unless you're using some other oven that scaled temperatures differently, in which case bake them at some other temperature instead ¯\_(ツ)_/¯

One could argue that you really are using inches, it's just that everything ever displayed on a screen has an implied "not to scale" note with it, but I don't think that's a particularly useful argument.

Heck, if you're editing something in MS Office it'll show you an 8.5x11 page with a scale meter. Set it to 100% and surely that's to scale.

Nope, 100% of some other totally arbitrary scale. That's what you wanted, yeah?

This is why working around a problem rather than fixing it is rarely a good idea.

In regards to Microsoft Word, it might be exactly to scale if your monitor happens to be a multiple of 96 DPI: https://www.anandtech.com/show/11050/the-microsoft-surface-s...

Microsoft Word sizes everything for the printer. What you see on screen is merely an approximation. This actually makes sense, since printers will be more consistent than screens.

If I'm editing a Word document, I'm designing something to be printed. If I set zoom to 100% I expect the screen to display the exact size a paper would.

But I'm designing when I'm in Word, it's not necessary or convenient to do all of my work at 1:1 scaling, that's what the ruler is for.

Yup. Best way to test it: take a sheet of paper from your printer and put it against your screen; MS Word at 100% zoom should have the document area match the physical paper size.

Just tested this: Not even close to being true (current Word/Office 365 on Windows 10)

Is it word, or the OS scaling (which is where a lot of the current font size sins exist)?

This requires that Windows knows about the exact size of the display, but Windows cuts a few corners there so it's unlikely to be as precise as an 8.5x11 piece of paper.

Compounding the problem is that the operating system relies on the monitor reporting its physical size correctly via EDID and for a lot of vendors (most notoriously Dell) this isn't guaranteed either.

You should check out OvenBakes. It's a free service that tries your recipe in dozens of different ovens and then ships you the result so you can check for consistency.

Do you have a link? Google doesn't seem to know anything about it.

I think they're in stealth mode until 01/04/2018

> Right, the argument is that if you want some arbitrary sizes you should get a new unit for it

They already exist (vw and vh are percents of the viewport width and height respectively). Renderers "relativised" supposedly absolute units because 1. they already were not correctly handled (as output devices often don't correctly report their densities and renderers would then just fallback to 72dpi or whatever) and 2. they were ubiquitous.

Something like that. The article may be technically correct, but it's putting the cart way in front of the horse. We shouldn't be using "points" to specify type face size in the first place. Because obviously we don't want type to be the same physical size on all display devices.

Most high DPI web-browser/software run into the main problem that the world runs on <= 96dpi screens. So for the act of sainty they all throw their arms up and say, `We assume the device is 96dpi and we scale a pixel to that`.

Consider it this way. When you had a A4/A3 size paper it it natural to talk in point, inches because your A4/A3 sheet of paper doesn't suddenly change to A5/A6, so you're all-ways designing for a fixed size.

Most high DPI web-browser/software run into the main problem that the world runs on <= 96dpi screens.

I'm typing this on a 27″ iMac 5K with 218 dpi resolution. My smartphone (an iPhone 6) has 325 dpi; my 9.7″ iPad has 264 dpi. And you don't even have to use "retina" high-DPI displays to beat 96 dpi. The older 27″ displays, with 2560×1440 resolution, have 109 dpi when you work out the math; the MacBook Air 11″ has 135 dpi.

I think it's fair to say the world ran, past tense, on screens that were 96 dpi and under. But that's just not a very good assumption to make anymore.

I think it's fair to say you're wrong.

https://www.w3.org/TR/css3-values/#px

1px = 1/96th of 1in

There is a A LOT of content being built, have been build by designers for 96dpi. The reason why it isn't a concern for you is because that standard exists, and your webkit knows you're on a 218 dpi monitor and scales to the px unit.

I prefer 3/4 square inch square inches on the phone and 1.3 square inch square inches on a projector.

Sizing to pixels works great when the device manufacturers all use approximately the same ratio of resolution to viewing distance. The problem with that approach is that it doesn't allow for nicer, high-resolution displays.

Sizing to pixels is vital when using low-resolution displays, since any scaling will be unacceptably blurry.

Apple's approach with their Retina displays was brilliant - make the high-res screens an integer multiple of the low-res ones. That made the scaling issues much easier to deal with.

The tragedy is with Windows. Microsoft has long emphasized font hinting, which results in sharper display fonts. But it means that the font metrics don't scale linearly with the resolution. Apps that weren't tested at anything but the default resolution would invariably have rendering issues, so nobody used oddball resolutions. Because nobody used high resolutions, the app makers didn't feel the need to test them. Chicken/egg problem. It has taken far too long to overcome this.

> Apple's approach with their Retina displays was brilliant

Brilliant? Rather "lazy". They jeopardized the entire screen resolution spectrum introducing non-standard resolutions just to fit their vision, producing a new set of problems on its own.

Unless I’m missing something, if your programs are designed properly, non standard resolutions shouldn’t be a problem; Your app layout should flow to fill the space.

The web has already solved this.

HiDPI screens just get a multiplication factor, where a 1px by 1px <div> shows up as 2x2 or even 3x3 physical pixels.

So the CSS px unit is a bit of a hack, but ultimately works well.

Stuff sized in px stays readable across a super retina iPhone X, an older screen, a projector, or a stadium Jumbotron.

That's more than can be said of physical pixel or distance units.

>So the CSS px unit is a bit of a hack, but ultimately works well.

No, it doesn't. That "innovation" breaks programmatic graphics big time. Imaging you are drawing something on the screen, and you have no way to prevent things to alias at those 3x3 CSS pixels

In web design, at least, there are plenty of relative-size units available to create a scalable, responsive design. Em, rem, %, vw, and vh are all very useful for this. In my designs I almost exclusively use these units, with little to no issues.

I think the article falls into a pattern of web developers demanding too much control.

Fine grained control belongs to the users. The browser is a User Agent, after all.

Users may have their computer configured to display text bigger or smaller than normal. They may have blocked ads. They may have disabled autoplaying video. They might be using Flux or Reader Mode. They might be sitting on a couch, projecting a 6ft image onto a wall.

Just size your stuff in px. How many millimeters that works out to is up to the user.

At 100% zoom yes. I should be able to take a ruler to my drawing and verify that it is exactly one physical inch. (to the limits of the display). This implies the projector somehow has feedback to the computer some sort of scale factor depending on how large the screen is. When I'm doing CAD, or paper layout this is very important.

Note that an inch (or more likely cm) is rarely what I want. Most of my use case is text where physical measurements are not important. When I'm writing code I want text to scale to be readable. This means web browsers and many other editors should not have any concept of points/inches/cm.

Em may be a relative size, but it's based on a font whose size is specified in points or pixels. Thus it's indirectly a physical measurement too.

Although points are formally defined as a physical size, they really only make sense in their historical context - the printed page.

I think the W3C definitions make the most sense when relating measurements to displays. You are encouraged to use definitions that are flexible but consistent with the context of your display. https://www.w3.org/TR/css-values-3/#absolute-lengths

> Em may be a relative size, but it's based on a font whose size is specified in points or pixels. Thus it's indirectly a physical measurement too.

A size specification that can be correctly converted into any amount of meters at all is most definitely not a physical measurement. A unit that has a conversion factor to the corresponding SI unit for the respective dimenion that can be chosen completely arbitrarily is certainly not a phyiscal unit of measurement.

While the conversion from points/pixels to em is not fixed, it is fixed for any particular font. As the pixel and point sizes change, so will the em - they're directly proportional except for any font hinting your browser might apply.

In other words: They are not a physical size measurement.

The definition of physical units is precisely that they are relative to only one unambiguous standard which relates it to all other dimensions of the universe. Distances, for example, are related to time. As such, one meter, as a unit of distance, is the distance that light in a vacuum travels in 1/299792458th of a second. A unit that does not have such a fixed relation to time is not a unit of distance by definition. So, unless increasing the font size in your browser also slows down time, the em is not a unit of physical size.

There are many more perfectly fine ways to specify how to derive a physical size relative to a given situation, but that does not make that specification a physical size itself.

OK, I'll grant your point. But Em is much more closely tied to the other physical units than intuition would suggest. It's one step removed rather than being completely independent.

Fun thing is: pixels don't have a size. They are just 2d locations (with a color assigned).

But most devices relate them to screen pixels. And therefore scale coded pixels to the screen density.

High density devices can do this in multiple ways: every screen pixel is a coded pixel, or scale the coded pixels so the user can 'see' them.

That's why using pixels in code work because the device is scaling them to a screen size that is nice for the user.

> Fun thing is: pixels don't have a size. They are just 2d locations (with a color assigned).

Sometimes pixels are not even 2d locations. I've seen experimental hardware running hexagonal and other unusual pixel configurations. Vector images look absolutely amazing, even at low resolution, however certain font types (formats, not typefaces) look better than others and some look downright terrible.

> An inch should be an inch. A pixel should be a pixel.

We had that in Win95. You could scale the display for 1:1 dimensional matching with an on screen ruler. Then Microsoft found out how broken everything became if you scaled the display to a non-default value because invariably some GUI elements were built around hard coded pixel dimensions that couldn't adapt when the fonts weren't rendered the same as the developer's machine. So they hid all of that machinery in '98.

Guess what? People are still designing web apps today with px units and the same scaling breakage persists with browsers jumping through all sorts of hoops to hide it.

That machinery is still there, and has always been - it's exactly what happens when you muck around with "make everything smaller/bigger" in display settings in Control Panel.

The problem, rather was that the OS didn't really do much to implement it. That ruler was basically just surfaced to the apps as an API to query, and then they were supposed to apply their own calculations as needed. One exception was the API used to create dialogs (but not other types of windows) from Win32 resoures - CreateDialog etc - these measure widget sizes in "dialog units", which is "an average width and height of characters in a system font"; the idea being that this way, the size of the widgets would naturally scale to the size of the text labels, according to DPI. However, many (arguably, most) Win32 don't use CreateDialog even for actual dialogs, and many frameworks in the past didn't respect the DPI setting at all.

    > In most cases, you have to factor in the distance to 
    > the viewer. This is, probably "projection angle in the
    > retina" is a more useful invariant.

That's actually exactly what CSS specifies:

"The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch)."

Of course this means "pixel" is kind of a misnomer, but at least the semantics of the unit are about what you want.

Note that there's slightly more choice here than just that: 1px may be either (1 physical real-world inch on the output medium)/96 or set related to the reference pixel. (Though in CSS 1in always equals 96px, etc.)

(See https://drafts.csswg.org/css-values-4/#absolute-lengths)

What is written in CSS specification may work only if CSS has any means to measure distance of observer from display surface.

Like @media distance(1m) {}

Otherwise it is just a good wish like "hope you have normal eyesight".

The only information that is available to CSS is that it gets rendered on some media. And so 100mm shall be 100mm measured by the ruler on that media surface. Monitor or printer. Dot. No other options.

Phones already have proximity sensors and facial recognition. We're just not using them to scale pixels yet.

But for most intents and purposes, it's enough to assume a "typical" distance for the type of device in question. People with bad eyesight are free to place the device closer to their eyes, zoom in, or adjust a system setting that makes everything look larger.

> And so 100mm shall be 100mm measured by the ruler on that media surface. Monitor or printer. Dot. No other options.

So, you connect a projector to your laptop, point it at a 20 m screen, open a web page, and then ... the browser has to scale the web page to a width of 10 pixels without any options to adjust things for the user?

The projector is a great example. The projector generally will know neither how far the projector itself is from the screen nor how far the viewers will be. So specifying how large the type should be on the screen in inches is obviously not a useful thing to do.

Generally 'as large as possible' is the best answer for this case...

Exactly. It doesn’t make sense to talk about this topic without reading and understanding that spec first. The “px” unit has already been virtualized. It’s already based on visual angle (or the idea of visual angle), and notably not absolute display distance (because of TVs, projectors, and now VR goggles).

TVs and projectors should be an exception. They are always mentioned as an objection when this comes up, but I think there is no problem to limit resolution to certain devices where it makes sense.

"Non-technical" people don't understand why 1cm isn't the same on screen or printed out. They hold a piece of paper to the screen and are frustated.

That 12pt means something different on Mac than on Windows is also confusing - and the exact handling changes between apps. I think Word makes it so that the printed out size is the same (it has to be), but the displayed size is smaller. On my Mac, "100%" zoom doesn't fit a piece of paper, but "135%" does. On Windows, it is about "115%" for me. Other apps have subtly different behavior.

It would be really great for multimonitor setup if stuff would have the same physical size on each screen (and while we are at it, color! Even a very basic per-model color calibration would be better than nothing). It would be really useful if you could display something at an exact scale on a tablet, and maybe hold a real ruler up to it.

I understand why this stuff is hard, I've worked a bit on related things myself. And to be honest, most people won't probably notice. But I still think it would be a good usability and ergonomics improvement.

> TVs and projectors should be an exception.

No, they are just extremes making the point unmistakably clear, if you decide they're exceptions you just refuse to accept the issue exists at all.

The exact same issue exists going from a smartphone to a tablet to a laptop or desktop computer, just to a lower degree. If you're not solving the issue such that it works from a smartphone to a projector, you're not actually solving it you're just providing one more bandaid, of which we already have plenty.

The difference is, on a projector I want the content to be blown up. That's the whole purpose.

On the other hand, I want text on monitors to look like printed out, and hung up. Real paper doesn't scale with viewing distance. Instead, there is foreshortening - stuff a bit further away looks smaller, but I know it is the same size.

It doesn't mean all text should be the same size ever - on the contrary. If I sit further away, I want to choose a larger font size or greater magnification.

All I want is, when dealing with physicality - stuff to print out, or stuff behind a touchscreen that pretends to be real - I want to be able to set a slider to "100%", and put a ruler or comparison document up to the screen, and have it match perfectly. I want stuff on dual monitors and large tablets to be the same size by default.

I needed these features already several times this week: I printed out a document just to get a better impression of how the font size looks on paper. I also had a scan of an architectural drawing on milimeter paper (1cm = 1m), and wanted to compare it with a paper blueprint - if it was the same scale, I could just hold a ruler against it.

I've been experimenting with the concept of using subtended angles on the retina. For devices that can sense the distance to the user, we'd use that, otherwise you make an assumption based on the kind of device.

That way you should be able to get sizes that appear roughly the same size regardless of whether they are on a huge screen far away or a small screen up close.

IMO this is easily fixable by making any display output its exact pixel size as some sort of universal standard. For example, 1 pixel = 0.0147 cm. And vice versa. Together with the screen diagonal size (and maybe some flag whether it's a tablet or desktop, etc), you have all the information needed. You could perfectly adjust websites for different use.

On a Mac (probably elsewhere, too), you can open an A4 print PDF and have it exactly the same size as the output, to the millimeter. That is so helpful.

Such a standard exists, but it measures the total display area across the entire width and height of the display. Thus the pixel to pixel gaps become negligible compared to the imprecision of humans interpreting illuminated pixels.

EDID parameters 20 and 21... https://en.wikipedia.org/wiki/Extended_Display_Identificatio...

Reply on news.ycombinator.com