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.
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.
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.
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.)
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.
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.
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’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.
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.
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.
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.
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.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.
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.
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)
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
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.
They aren't hardware based. As I say in the first link, pixels mostly don't exist in hardware.
Screens very rarely contain a matrix of individual squares.
For example - https://global.samsungdisplay.com/29043/
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.
No one decided to break it, it was 1/96th of an inch from the beginning.
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.
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.)
Correction: in CSS1, from December 1996, a pixel was defined slightly differently, which works out to 1/90th of an inch.
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.
Thought a magic number is when you hard code a number in logic instead of pulling from a data source
I'm guessing the GP means the weird results leads to adding magic numbers to get good results.
Nobody uses ch, let's be honest.
Until design tools like figma use these other units, people will be stuck to rems and pixels.
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.
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’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.
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.
I’d like to hear the
What happened to em?
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.
* https://www.w3.org/TR/css-values-4/#font-relative-lengths
Layout shift when the font loads
Not necessarily. See https://screenspan.net/fallback
Headline length changes in that demo: https://screenspan.net/prototypes/fallback-font/
I will not take CSS advice from a website that looks like such utter crap on mobile
May I ask which browser you're using? I do test on all the major ones at a variety of screen sizes.
Or, have your perhaps selected one of the different themes at the top of the site?
There is no way I will abandon px.
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.