Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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.
  • It's starting to look like win32 was the pinnacle of GUI API design.
  • 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.
  • 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.

  • 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.
  • 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 happened to em?
  • designers don't like doing math
  • 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.
  • 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.

  • 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

  • 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.

  • 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.
    by npn
  • Huh?

      <main style="max-width: 60ch; margin: auto>
        Your content
      </main>
    
    What is hard about that?
  • 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.

  • 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.

  • 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.
  • 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.

  • Who broke px? It was W3C. In "CSS Values and Units Module Level 3", px was defined as 1/96th of an inch

    But even in CSS1 (1996), a "reference pixel" based on a typical 90 DPI monitor was recommended. You could argue its always been broken

    by culi
  • 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.

  • 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.

    by fsmv
  • 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:

        body { --resolution-scale: 1; }
        @media (min-resolution: 2dppx) { body { --resolution-scale: 2; } }
        @media (min-resolution: 3dppx) { body { --resolution-scale: 3; } }
        .myPixelSizedElement { width: calc(96px * var(--resolution-scale)); }
    
    
    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 article links to

    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.

  • > 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.

    [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

  • Just to check: when were you growing up? In the CRT, it was often possible to see the physical pixels (i.e. the phosphors and the rows defined by the shadow mask), but there was not necessarily any guarantee that a logical pixel lined up with a physical pixel.
  • 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.
  • Nobody uses ch, let's be honest.