which confuses me, because I definitely remember pixels being visible when I was growing up. I remember the first time I got a 1080p monitor. I felt a visceral terror at the fact that I could no longer see the pixels.
> because I definitely remember pixels being visible when I was growing up
Was this on an LCD or CRT display? Because on a CRT, you can't really see the pixels [0] [1], so what you were seeing was probably the shadow mask instead [2]. You could definitely see the pixels on old LCD monitors though, and new LCD monitors too if you look really close, although even big LCD pixels aren't quite as prominent as the shadow mask is on a CRT.
Yeah, you can see square-looking pixels on most screens if you display something with sharp aliasing. "There is no universal grid" is good to understand, but there are device-specific grids all over the place.
And all the examples that are ultra zoomed and/or showing antialiased font rendering obscure the pixels that are more visible in other situations.
That 0.01 to 0.04 degree range later in the article is big enough to drive a truck though. And you can see stairstepping at even finer distances.
I’ve found that ch and ex units are heavily influenced by latin characters. They just give weird results with non-latin characters leading to magic numbers. But the concept is really solid: use them if you want the spacing relative to text.
This is a problem whenever someone outside a culture tries to design for that culture. I have just enough knowledge of say, CJK+Arabic to read them, but not enough to know if the font/kerning/justification I'm using is attractive or ugly to natives.
It's often easy to spot Chinese goods because English writing on the stickers or manuals is in that horribly ugly latin serif font with bad kerning, which almost certainly looks fine if you don't read English all day.
What I want to know is who decided to break px, the last thing we need is yet another screwball physical measurement, css was already full of them. But what "tut tut, everybody is using px and these new hi-dpi displays are rendering things really tiny, we can't have that" and now px as a useful unit is ruined.
Is there a way to use real pixels? My, admittedly quick, search says no. at least nothing jumps out at me from the spec.
You can kinda get close in pure CSS with CSS media queries using the resolution query on dppx measurements; but that only allows you to be as granular as however many distinct "dots per CSS pixel" values you want to add media queries for. Something like this would let you scale by device resolution for both traditional 96dpi screens, higher DPI 192dpi screens, and super high resolution 288dpi screens:
But unfortunately there's no way to directly use the devicePixelRatio value you can read from Javascript directly in a CSS calculation to be able to get a precise scaling on any arbitrary pixel density.
> But unfortunately there's no way to directly use the devicePixelRatio value you can read from Javascript directly in a CSS calculation to be able to get a precise scaling on any arbitrary pixel density.
The indirect way is for the JS to post the metric to the server, then you run with server-generated CSS. Don’t ask me if it actually works well though.
Much simpler, you also just have JS update (and keep updated - initial DPI is not always the current DPI) --devicePixelRatio under :root on the client side. Something like that existing by default is all that's really missing.
px is still a useful unit. the user's operating system applying a scaling fator doesn't make it not useful.
if the user's operating system is configured to draw pixels at a 1:1 ratio, your pixels will be drawn at a 1:1 ratio. if the user's operating system is configured to draw pixels at a 2:1 or 3:1 ratio, you as a web developer don't get to override that, but you're still addressing pixels directly. if you want to write software that manages the user's hardware directly without giving them options to override it, the web is probably not the right platform for you.
The spec fafs around a bit talking about how the px is a "visual angle unit" But I am unable to form an interpretation where the "reference pixel" is anything other than 1/96 inch.
I guess theoretically a tv could say "this tv will be viewed at 12 feet away so our reference pixel is 1/16 inch" and still be in spec. Which sounds like it has messy implications, Does anyone do this?
Anyway the point being a pixel should fundamentally be a hardware measurement, and if they wanted a "visual angle unit" they should have introduced one.(the moa?) But the last thing we need is a pixel being defined as a hard 1/96 of a inch. which is what we got.
Windows used to let you set the DPI setting of the monitor, circa Win95-WinXP. Software tended to only expect a value of 96dpi, so it wasn't a very practical setting to change, and eventually windows introduced display scaling (which leaves old software in the belief that you are on a 96dpi screen, while allowing software to opt in to knowing about the real device pixels)
I guess you could use that setting on an old version of windows to set a screen to 16dpi, and now a CSS reference pixel is 1/3rd of a real pixel? But more realistically, what the spec is getting at is that a mobile device should set its dpi setting close to the real device setting, and a reference pixel is now something that looks about as big as a pixel on a 96dpi screen. That nobody actually sets their screen dpi on desktops is probably of secondary importance to them
what the spec says doesn't really matter though, the spec is just nonsense people wrote down to try to back-explain decisions that the browsers had already made.
pixels are pixels, and no browser implements them as a fractional-inch measurement. in every actual implementation i'm aware of, they're a hardware based unit.
Pixels very much exist in hardware outside mobile. Microsoft’s clear type even exploited the specific layout of color channels in discrete hardware pixels. Mobile displays are all over the place, but most other displays use standard RGB layouts.
Right, but there's still an addressable set of display units that convert an RGB signal to actual glowing lights, right?
It seems like defining px to be perceptual is one of those compatibility hacks that probably helped a ton back in the day, but we have perceptual units and now we're stuck with that baggage.
I don't have much of an opinion on this (I use em) but it has taken me by surprise a few times.
You could set the CSS zoom property to 1/window.devicePixelRatio with JavaScript but I think you can't do it with CSS only. If you do that then px is physical px. This doesn't include browser zoom though or mobile pinch to zoom. You could also get those with JavaScript but then people would be really confused by the behavior of your website.
You definitely can't get pure integers though it's always a float even if you use whole numbers. It does eventually get rounded before becoming pixels though.
That is sort of where I ended up, Not that it matters, Pixels should probably never actually be used. It just offends me that a unit that is sort of messy and tied to physical hardware but does provide measurement that can not be found elsewhere. gets neutered and we end up with another useless absolute unit, inch, point, millimeter, pica, the Q(did we really need the Q?) and now the pixel.
To be honest, I'm quite thankful to whomever decided this. If it were the other way around and everyone used px but it represented true pixels, there's no doubt developers would be incorrectly designing interfaces across the board and websites looking totally off would be a common occurance due to you having an hdpi display or not having one (like what frequently happens with x based apps in Linux).
As an aside, technically, yes, it may have been better to converge on some more clearly "fake" unit rather than calling it a pixel but for me that's a nit pick.
It was around 1/96" on a conventional PC screen because that was the conventional pixel density for PC screens; it was 1/72" (i.e. 1pt) on a conventional Mac screen for the same reason. That was something to deal with already in the GIFs-in-tables era and remained one as we moved on to CSS, right until Retina happened.
Unfortunately, Retina gave us a nonsensical and hacky “scaling ratio” rather than separate and independent units of physical length, viewing angle, and interaction granularity. (I still can’t get an A4 PDF in GNOME to display at “100%” such that it would actually be 210mm wide on my screen. And Darktable is the only piece of software I know where you can configure ppi and ppd separately.)
Knowing about the screen also doesn't do you much good if you don't know how far it is going to be away from the viewer. (Yay at fonts rendering with 3 point on my projector because it reports some 6m³ of "screen" area.)
They decided to break px because web designers used it for things like setting text size. Why did designers use px rather than pt which was supposed to scale? Because early browsers interpreted pt differently across platforms, so specifying text size in px rendered more consistently.
I also did some experiment with ch many years ago. I found that 60ch is ideal width for block text for easy reading. too bad it is pretty hard to make websites with only 60ch wide.
I'm still waiting for operating systems to adopt true physical units. You know, that trick PostScript printers have doing since the 80s (running at 300dpi no less). I realize there are large screen projectors in the wild, that's solvable problem. Bitmaps icons are also an issue, but again, solvable.
Real physical units make sense when you're printing on paper.
I don't see how they make sense on screens. A one square inch image is fairly large on my phone, not too big on my desktop monitor, and pretty darn small on my tv. That's not to say that pixels make sense to use for layout at those scales either, but before everybody got into high dpi with scaling, it kind of worked... If you were comfortable with tiny text, you ran a higher resolution and if you needed things big, you ran a lower resolution.
That's what I wondered. I found the spec*. I'd vaguely thought that 1em was the width of "M" but apparently it's just the font-size, and the connection between font-size and the actual size of the text is very font dependent.
So 1ch is defined to be the advance width of "0" (zero), so it's actually telling you something about the current font.
I know this is an irrelevant factoid and literally does not matter at all, but it's a tad more meta that just em = font size. Prepare to be bored:
The em unit/point size in typography was based on the height of the lead sorts you were using. [0] (A sort is basically a little lead stamp with a single letter jutting out on the front face. [1]) Its almost always larger that any dimenion of the actual character, since the sorts are just clamped together when doing the actual typesetting, so you want a gapless grid of lead to keep everything in place. [2] You couldn't have any spacing between letters/lines if the castings themselves were only as tall or wide as the character.
That meant the em height was a real physicial thing you could measure with a ruler, commonly in points, where 1/72 of an inch = 1 point. When you ordered typefaces from foundaries, you'd specify what point size you wanted, so all of your large-point headings would line up in one slug, which you'd clamp above another slug of body copy text all sized to a smaller point size. That tied an em to both the size of text, but only in the context of 1 font family. You could leave the em size the same and cast a glyph larger on the same size of sort, changing the baseline, line-height/ledding and letter-spacing/tracking. Now it doesn't line up with your other font faces with the same em size, even if they clamp together just fine.
But in modern typesetting, you don't have a physicial em-height lead block to deal with. Internally, the font uses it's own unitless values to describe both the vector shape of the glyphs, as well as units like the line height, letter spacing, and em height. It's no longer a "real" measurement you could actually measure. It's a relative one that acts like the unit value when scaling fonts. [3] If you render a font at 12pt, the text rendering scales the relative em unit until it would be 12pt or 1/6in, and then apply that scaling factor to all glyphs.
That means, digital fonts are emulating the same weird use for ems as a proxy for both the size of the glyphs AND the size of the lines/spaces between characters. If you shrink the internal em unit inside a font file, the size of glyphs increase, but so will the line height/letter spacing and other font metrics.
So... all of that together, yep the em unit is 100% dependant on the font's own settings, but it's not the font size itself. It's a sort of base-unit for everything else in the font, where 1em is defined as being a certain height in the internal font domain AND being the height of whatever the font renderer says the point size is. If you halve the em height and double the point size, you end up with exactly the same raster ouput. It also means you can't look at the screen and find any part of the letters/lines that is precisely 1em, like you could for simplier glyph-size-based unit like 1ex or 1ch. (Unless there's an em-dash... but even then, making the em-dash exactly 1em long is just convention.)
em is a generic "font-size" without regard to the axis. ch is specifically related to the font width, and ex is specifically related to the font height. So if you want things like padding and margins to be proportionate to the font size, then using em will be suboptimal for fonts that happen to be tall or short. And as a web developer, you generally don’t know which font will be used (content management systems, designers making different choices in the future, users overriding fonts for accessibility reasons, etc.)
For lengths that you specifically want to be axis-independent and related to the font size, e.g. border-radius, then you should still use ems.
I always use em or px, basically nothing else (except perhaps vw or vh). When something should be relative to the size of text, it's em. When it should be relative to the size of images, it's px.
I’d like to hear the author’s approach to vw and vh units. I’ve tended to use these units where I want a specific feel and it’s worked relatively well over the years. I’m surprised it was not mentioned given the justifying of ch was around the desire of a consistent layout.
I’m somewhat out of the loop but I remember the time everybody switched from px to em’s. When I came back to CSS for a short while it was px again and behold it worked for 4K screens. To be honest I didn’t really liked the usage of em and actually prefer px.
content-driven websites that aim to be responsive and accessible should use as little size-related styling as possible. fr for containers and rem/em for text.
In fact, I think CSS made the wrong decision by proliferating so many
things, em, %, px, ch, whatever-else. The human brain is not well-equipped
to have so many things for basically the same thing. That's a design flaw
in CSS, plain and simple. And the author is thus also wrong. There won't
be a mass movement of people using "ch". It would be a good first april
article though.
https://shkspr.mobi/blog/2018/11/the-myth-of-the-pixel-perfe...
which confuses me, because I definitely remember pixels being visible when I was growing up. I remember the first time I got a 1080p monitor. I felt a visceral terror at the fact that I could no longer see the pixels.
Was this on an LCD or CRT display? Because on a CRT, you can't really see the pixels [0] [1], so what you were seeing was probably the shadow mask instead [2]. You could definitely see the pixels on old LCD monitors though, and new LCD monitors too if you look really close, although even big LCD pixels aren't quite as prominent as the shadow mask is on a CRT.
[0]: https://en.wikipedia.org/wiki/Fixed-pixel_display
[1]: https://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf#page=8
[2]: https://en.wikipedia.org/wiki/Shadow_mask
And all the examples that are ultra zoomed and/or showing antialiased font rendering obscure the pixels that are more visible in other situations.
That 0.01 to 0.04 degree range later in the article is big enough to drive a truck though. And you can see stairstepping at even finer distances.
It's often easy to spot Chinese goods because English writing on the stickers or manuals is in that horribly ugly latin serif font with bad kerning, which almost certainly looks fine if you don't read English all day.
Is there a way to use real pixels? My, admittedly quick, search says no. at least nothing jumps out at me from the spec.
The indirect way is for the JS to post the metric to the server, then you run with server-generated CSS. Don’t ask me if it actually works well though.
But even in CSS1 (1996), a "reference pixel" based on a typical 90 DPI monitor was recommended. You could argue its always been broken
if the user's operating system is configured to draw pixels at a 1:1 ratio, your pixels will be drawn at a 1:1 ratio. if the user's operating system is configured to draw pixels at a 2:1 or 3:1 ratio, you as a web developer don't get to override that, but you're still addressing pixels directly. if you want to write software that manages the user's hardware directly without giving them options to override it, the web is probably not the right platform for you.
https://drafts.csswg.org/css-values/#absolute-lengths
I guess theoretically a tv could say "this tv will be viewed at 12 feet away so our reference pixel is 1/16 inch" and still be in spec. Which sounds like it has messy implications, Does anyone do this?
Anyway the point being a pixel should fundamentally be a hardware measurement, and if they wanted a "visual angle unit" they should have introduced one.(the moa?) But the last thing we need is a pixel being defined as a hard 1/96 of a inch. which is what we got.
Screenshot: https://www.softacom.com/wp-content/uploads/2022/03/11111-10...
I guess you could use that setting on an old version of windows to set a screen to 16dpi, and now a CSS reference pixel is 1/3rd of a real pixel? But more realistically, what the spec is getting at is that a mobile device should set its dpi setting close to the real device setting, and a reference pixel is now something that looks about as big as a pixel on a 96dpi screen. That nobody actually sets their screen dpi on desktops is probably of secondary importance to them
pixels are pixels, and no browser implements them as a fractional-inch measurement. in every actual implementation i'm aware of, they're a hardware based unit.
Screens very rarely contain a matrix of individual squares.
For example - https://global.samsungdisplay.com/29043/
https://en.wikipedia.org/wiki/Subpixel_rendering
It seems like defining px to be perceptual is one of those compatibility hacks that probably helped a ton back in the day, but we have perceptual units and now we're stuck with that baggage.
I don't have much of an opinion on this (I use em) but it has taken me by surprise a few times.
You definitely can't get pure integers though it's always a float even if you use whole numbers. It does eventually get rounded before becoming pixels though.
As an aside, technically, yes, it may have been better to converge on some more clearly "fake" unit rather than calling it a pixel but for me that's a nit pick.
The problem with different screens having different pixel densities was already present and obvious in 1996.
"Real" pixels are useless if you don't know anything about the screen you're going to render on.
Unfortunately, Retina gave us a nonsensical and hacky “scaling ratio” rather than separate and independent units of physical length, viewing angle, and interaction granularity. (I still can’t get an A4 PDF in GNOME to display at “100%” such that it would actually be 210mm wide on my screen. And Darktable is the only piece of software I know where you can configure ppi and ppd separately.)
This website layout (tall brick surrounded by voids) was very popular in the 2000s.
I don't see how they make sense on screens. A one square inch image is fairly large on my phone, not too big on my desktop monitor, and pretty darn small on my tv. That's not to say that pixels make sense to use for layout at those scales either, but before everybody got into high dpi with scaling, it kind of worked... If you were comfortable with tiny text, you ran a higher resolution and if you needed things big, you ran a lower resolution.
So 1ch is defined to be the advance width of "0" (zero), so it's actually telling you something about the current font.
* https://www.w3.org/TR/css-values-4/#font-relative-lengths
The em unit/point size in typography was based on the height of the lead sorts you were using. [0] (A sort is basically a little lead stamp with a single letter jutting out on the front face. [1]) Its almost always larger that any dimenion of the actual character, since the sorts are just clamped together when doing the actual typesetting, so you want a gapless grid of lead to keep everything in place. [2] You couldn't have any spacing between letters/lines if the castings themselves were only as tall or wide as the character.
That meant the em height was a real physicial thing you could measure with a ruler, commonly in points, where 1/72 of an inch = 1 point. When you ordered typefaces from foundaries, you'd specify what point size you wanted, so all of your large-point headings would line up in one slug, which you'd clamp above another slug of body copy text all sized to a smaller point size. That tied an em to both the size of text, but only in the context of 1 font family. You could leave the em size the same and cast a glyph larger on the same size of sort, changing the baseline, line-height/ledding and letter-spacing/tracking. Now it doesn't line up with your other font faces with the same em size, even if they clamp together just fine.
But in modern typesetting, you don't have a physicial em-height lead block to deal with. Internally, the font uses it's own unitless values to describe both the vector shape of the glyphs, as well as units like the line height, letter spacing, and em height. It's no longer a "real" measurement you could actually measure. It's a relative one that acts like the unit value when scaling fonts. [3] If you render a font at 12pt, the text rendering scales the relative em unit until it would be 12pt or 1/6in, and then apply that scaling factor to all glyphs.
That means, digital fonts are emulating the same weird use for ems as a proxy for both the size of the glyphs AND the size of the lines/spaces between characters. If you shrink the internal em unit inside a font file, the size of glyphs increase, but so will the line height/letter spacing and other font metrics.
So... all of that together, yep the em unit is 100% dependant on the font's own settings, but it's not the font size itself. It's a sort of base-unit for everything else in the font, where 1em is defined as being a certain height in the internal font domain AND being the height of whatever the font renderer says the point size is. If you halve the em height and double the point size, you end up with exactly the same raster ouput. It also means you can't look at the screen and find any part of the letters/lines that is precisely 1em, like you could for simplier glyph-size-based unit like 1ex or 1ch. (Unless there's an em-dash... but even then, making the em-dash exactly 1em long is just convention.)
[0] https://www.thomasphinney.com/2011/03/point-size/#:~:text=ou...
[1] https://en.wikipedia.org/wiki/Sort_(typesetting)
[2] https://commons.wikimedia.org/wiki/File:Sorts_on_composing_s...
[3] https://www.thomasphinney.com/2011/03/point-size/#:~:text=Ty...
For lengths that you specifically want to be axis-independent and related to the font size, e.g. border-radius, then you should still use ems.
Or, have your perhaps selected one of the different themes at the top of the site?
In fact, I think CSS made the wrong decision by proliferating so many things, em, %, px, ch, whatever-else. The human brain is not well-equipped to have so many things for basically the same thing. That's a design flaw in CSS, plain and simple. And the author is thus also wrong. There won't be a mass movement of people using "ch". It would be a good first april article though.