Death to px, long live ch

It's starting to look like win32 was the pinnacle of GUI API design.

Ultra zoom approximates a pixel grid, but the pixel grid it approximates no longer exists (and arguably never physically existed, it was always a mapping scheme). We tend to think of pixels as square bricks, but even in the CRT era they were closer to 4:3 rectangles than squares, and that too was an approximation because phosphor beams were a fairly analog technology and hitting a square (or rectangle) grid was an imperfect thing, especially with something as excitable as light. That's why popular arcade emulators have been picking up CRT filters that bleed neighboring pixels over each other to more accurately rebuild the CRT experience.

That's part of what led to dithering being as much or more important than exact color matching. That's also what led to advances at the time in sub-pixel anti-aliasing such as the earliest forms of Microsoft's ClearType brand which blended neighboring colors to make perceptually cleaner font rendering.

As we've moved to solid state hardware the grid didn't get more exact, and sub-pixels became even more interesting, rather than less. Most LED displays are triangular shapes, not square grids, with red/green/blue LED diodes packed closely together to map a virtual pixel. (To my understanding some LED displays get even more complex with hexagonal or octagonal packing.)

The device-specific grids even more rarely today reflect what we would expect of a "square" pixel grid. (Or even a 4:3 rectangular grid.)

Square cartesian grids are easy to program with it. It's always been a useful abstraction, even in the CRT era. It's easy to forget that it was always an abstraction. Ultra zoom operates on the abstraction, not the physical reality. It explodes a cartesian grid, because that's mathematically easy (and the useful abstraction we like to program with).

(All of that is before you get to things like OSes and Browsers gave up on mapping the virtual pixel cartesian grids to physical "pixel" grids in real life because the "pixels" became too small, so most users see "16px" fonts as 125-175% expansion to keep fonts readable without magnifying glasses. Web Browsers have "lied" about the physical size of pixels since roughly the end of the CRT era and browser pixels are font-relative too, in which case the other font-relative measurements are often more useful simply for being "honest". Nobody really wants "pixel perfect" accuracy in websites, not even the designers that pride themselves on it and think it matters more than other characteristics like responsive adaptability to device type.)

rem is related to the ch, though. It's not an awful compromise if a designer insists on tools like Figma. Sometimes just taking their work in rems and just removing the `r`s is enough to meet their designs and also have better relative units.

(The difference between rem and em is "root", ie, only using the top-most font size and sometimes the font-size before things like zoom and other similar adjustments. If a designer complains about the `r`s you removed, sometimes just showing them the difference at multiple zoom levels is convincing enough.)

(The difference between em and ch is em is wider. If a designer is always giving you weird decimals like 0.79em or 1.24em that may be an indicator that they themselves would be happier working and thinking in ch. em is the width of the capital M which is often the widest letter in most latin sections of fonts. ch is the width of the number 0 which is often the most "typical" width in the latin sections of fonts.)

(ETA: Both of which relate to the comment above complaining that both ch/em and others fall apart when dealing with non-latin scripts, because they are established as latin-centric.)

Consistency in viewport size versus consistency in relation to the width of text. It's a little bit of a "top-down" versus "bottom-up" distinction in thinking. (I often find the best answer is "both". vw/vh for "big picture" alignments like outermost grid structures and ch/em/lh/ex for "content" work inside those big grids.)

what hard is making a fully featured website, with panels no wider than 60ch.

typically 60ch equal to 480px (font size 16px), so you need sidebars to the left and the right. which is fine, the holy grail was like that. but if you want to design a layout that look good in all screen resolutions, then a fixed layout does not work. you would have a dozen compromises and layout switches to make it work. at that point, forcing a block to have at max 60ch is painful.

and, if you do the main + sidebar layout, with maximum width for the whole site is around 960px (or 1200px if you have multiple sidebars) then suddenly you do not need to think about 60ch width anymore, because it naturally just fits (except for some width points)