7 ms·

Death to px, long live ch

92 points by Brajeshwar 2mo ago

microflash 2mo ago
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.
- LowTechHN 2mo ago
  [dead]
  - goda90 2mo ago
    I'm guessing the GP means the weird results leads to adding magic numbers to get good results.
    - LowTechHN 2mo ago
      [dead]
- shevy-java 2mo ago
  Nobody uses ch, let's be honest.
  - dawnerd 2mo ago
    Until design tools like figma use these other units, people will be stuck to rems and pixels.
    - WorldMaker 2mo ago
      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.)
  - JackCooper7 2mo ago
    Totally.
- qingcharles 2mo ago
  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.
shevy-java 2mo ago
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.
rado 2mo ago
Layout shift when the font loads
- microflash 2mo ago
  Not necessarily. See https://screenspan.net/fallback https://screenspan.net/fallback
  - rado 2mo ago
    Headline length changes in that demo: https://screenspan.net/prototypes/fallback-font/ https://screenspan.net/prototypes/fallback-font/
npn 2mo ago
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.
- andai 2mo ago
  Why's it hard? I just tested it by applying 60ch width to TFA. It hardly changed, it was already not much wider than that. This website layout (tall brick surrounded by voids) was very popular in the 2000s.
- atoav 2mo ago
  Huh? <main style="max-width: 60ch; margin: auto> Your content </main> What is hard about that?
  - npn 2mo ago
    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)
    - atoav 2mo ago
      main should contain the semantic content of the website, you can still make full width headers and footers and have on the side. Well and <aside> can be just where the name implies, depending on the screen width. This is really not that hard nowadays. How to do responsive design is no black magic and can be done with only HTML and CSS. You basically just need to wrap (no pun intended) your head around a few basics. Especially CSS grid templates combined with media queries allow you to rearrange the whole page depending on the screen width in a simple way, especially compared to how we had to do this 20 years ago. You write your website semantically (or ensure the template produces semantic HTML) and then you write the CSS with realtime preview right there in the browser.
cynicalsecurity 2mo ago
What happened to em?
- masfuerte 2mo ago
  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 https://www.w3.org/TR/css-values-4/#font-relative-lengths
  - graypegg 2mo ago
    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.) [0] https://www.thomasphinney.com/2011/03/point-size/#:~:text=output%2E-,The,spacing,-%2E https://www.thomasphinney.com/2011/03/point-size/#:~:text=ou... [1] https://en.wikipedia.org/wiki/Sort_(typesetting) https://en.wikipedia.org/wiki/Sort_(typesetting) [2] https://commons.wikimedia.org/wiki/File:Sorts_on_composing_stick.jpg https://commons.wikimedia.org/wiki/File:Sorts_on_composing_s... [3] https://www.thomasphinney.com/2011/03/point-size/#:~:text=Typophile%3A-,In,points https://www.thomasphinney.com/2011/03/point-size/#:~:text=Ty...
somat 2mo ago
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.
- notatoad 2mo ago
  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.
  - somat 2mo ago
    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 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.
    - notatoad 2mo ago
      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.
awestroke 2mo ago
I will not take CSS advice from a website that looks like such utter crap on mobile
- edent 2mo ago
  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?
- SoMomentary 2mo ago
  Agreed. This site is always literally unreadable for me on mobile like they placed a blur filter over then entire page.
theokrueger 2mo ago
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.
LowTechHN 2mo ago
[dead]
jeberle 2mo ago
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.
- toast0 2mo ago
  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.
  - account42 2mo ago
    > 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. And even with so-called "dpi" scaling, CSS pixels remain that except users have more options to also have their large TV display finer details.
  - yencabulator 1mo ago
    Monitors these days provide metadata on their physical size. This laptop screen defines itself as 280x190 mm. Sure, that's not 1:1 with end user distance from screen, but it's a hell of a lot better than switching to mobile layout on my desktop based on how much I zoom my fonts and narrow the window.
squidlib 2mo ago
I’d like to hear the
squidlib 2mo ago
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.
- WorldMaker 2mo ago
  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.)
deleted 2mo ago
[deleted]
larusso 2mo ago
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.
blueshoess 2mo ago
[dead]
andai 2mo ago
The article links to https://shkspr.mobi/blog/2018/11/the-myth-of-the-pixel-perfect-grid/ 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.
- Dylan16807 2mo ago
  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.
  - penteract 2mo ago
    It never says 0.04 degrees, just 0.04mm (corresponding to about 0.015 degrees at the stated 15cm distance).
    - Dylan16807 2mo ago
      Ah, I see. In that case let's look at what reaching .01 degrees means for a desktop. At normal viewing distance, a 20 inch screen needs to be 4k, and a 30 inch screen needs to be 6k. Very few desktops reach the level where pixels are mostly hidden.
  - WorldMaker 2mo ago
    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.)
coolThingsFirst 2mo ago
why would anyone care if 1cm is actually 1.024cms on some monitors?
- Zecc 2mo ago
  Maybe a website is selling screws and wants to show a 1:1 picture.
- moring 2mo ago
  I tried and with 1:1 zoom, a "10cm" width DIV was actually less than 7cm. Why even call it "cm" if it is actually "whatever, I don't know"...
account42 2mo ago
Just leave the viewport size up to the user rather than making assumptions about which widths work best for people you don't know. Also despite the aggressive title, this article gives basically no reason for why you shouldn't use px.
BearOso 2mo ago
It's starting to look like win32 was the pinnacle of GUI API design.

92 points by Brajeshwar 2mo ago

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.

LowTechHN 2mo ago
[dead]
- goda90 2mo ago
  I'm guessing the GP means the weird results leads to adding magic numbers to get good results.
  - LowTechHN 2mo ago
    [dead]
shevy-java 2mo ago
Nobody uses ch, let's be honest.
- dawnerd 2mo ago
  Until design tools like figma use these other units, people will be stuck to rems and pixels.
  - WorldMaker 2mo ago
    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.)
- JackCooper7 2mo ago
  Totally.
qingcharles 2mo ago
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.

shevy-java 2mo ago

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.

rado 2mo ago

Layout shift when the font loads

microflash 2mo ago
Not necessarily. See https://screenspan.net/fallback https://screenspan.net/fallback
- rado 2mo ago
  Headline length changes in that demo: https://screenspan.net/prototypes/fallback-font/ https://screenspan.net/prototypes/fallback-font/

npn 2mo ago

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.

andai 2mo ago
Why's it hard? I just tested it by applying 60ch width to TFA. It hardly changed, it was already not much wider than that. This website layout (tall brick surrounded by voids) was very popular in the 2000s.
atoav 2mo ago
Huh? <main style="max-width: 60ch; margin: auto> Your content </main> What is hard about that?
- npn 2mo ago
  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)
  - atoav 2mo ago
    main should contain the semantic content of the website, you can still make full width headers and footers and have on the side. Well and <aside> can be just where the name implies, depending on the screen width. This is really not that hard nowadays. How to do responsive design is no black magic and can be done with only HTML and CSS. You basically just need to wrap (no pun intended) your head around a few basics. Especially CSS grid templates combined with media queries allow you to rearrange the whole page depending on the screen width in a simple way, especially compared to how we had to do this 20 years ago. You write your website semantically (or ensure the template produces semantic HTML) and then you write the CSS with realtime preview right there in the browser.

cynicalsecurity 2mo ago

What happened to em?

masfuerte 2mo ago
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 https://www.w3.org/TR/css-values-4/#font-relative-lengths
- graypegg 2mo ago
  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.) [0] https://www.thomasphinney.com/2011/03/point-size/#:~:text=output%2E-,The,spacing,-%2E https://www.thomasphinney.com/2011/03/point-size/#:~:text=ou... [1] https://en.wikipedia.org/wiki/Sort_(typesetting) https://en.wikipedia.org/wiki/Sort_(typesetting) [2] https://commons.wikimedia.org/wiki/File:Sorts_on_composing_stick.jpg https://commons.wikimedia.org/wiki/File:Sorts_on_composing_s... [3] https://www.thomasphinney.com/2011/03/point-size/#:~:text=Typophile%3A-,In,points https://www.thomasphinney.com/2011/03/point-size/#:~:text=Ty...

somat 2mo ago

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.

notatoad 2mo ago
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.
- somat 2mo ago
  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 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.
  - notatoad 2mo ago
    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.

awestroke 2mo ago

I will not take CSS advice from a website that looks like such utter crap on mobile

edent 2mo ago
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?
SoMomentary 2mo ago
Agreed. This site is always literally unreadable for me on mobile like they placed a blur filter over then entire page.

theokrueger 2mo ago

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.

LowTechHN 2mo ago

[dead]

jeberle 2mo ago

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.

toast0 2mo ago
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.
- account42 2mo ago
  > 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. And even with so-called "dpi" scaling, CSS pixels remain that except users have more options to also have their large TV display finer details.
- yencabulator 1mo ago
  Monitors these days provide metadata on their physical size. This laptop screen defines itself as 280x190 mm. Sure, that's not 1:1 with end user distance from screen, but it's a hell of a lot better than switching to mobile layout on my desktop based on how much I zoom my fonts and narrow the window.

squidlib 2mo ago

I’d like to hear the

squidlib 2mo ago

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.

WorldMaker 2mo ago
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.)

deleted 2mo ago

[deleted]

larusso 2mo ago

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.

blueshoess 2mo ago

[dead]

andai 2mo ago

The article links to https://shkspr.mobi/blog/2018/11/the-myth-of-the-pixel-perfect-grid/ 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.

Dylan16807 2mo ago
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.
- penteract 2mo ago
  It never says 0.04 degrees, just 0.04mm (corresponding to about 0.015 degrees at the stated 15cm distance).
  - Dylan16807 2mo ago
    Ah, I see. In that case let's look at what reaching .01 degrees means for a desktop. At normal viewing distance, a 20 inch screen needs to be 4k, and a 30 inch screen needs to be 6k. Very few desktops reach the level where pixels are mostly hidden.
- WorldMaker 2mo ago
  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.)

coolThingsFirst 2mo ago

why would anyone care if 1cm is actually 1.024cms on some monitors?

Zecc 2mo ago
Maybe a website is selling screws and wants to show a 1:1 picture.
moring 2mo ago
I tried and with 1:1 zoom, a "10cm" width DIV was actually less than 7cm. Why even call it "cm" if it is actually "whatever, I don't know"...

account42 2mo ago

Just leave the viewport size up to the user rather than making assumptions about which widths work best for people you don't know. Also despite the aggressive title, this article gives basically no reason for why you shouldn't use px.

BearOso 2mo ago

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