CSS Unit Might Be a Combination

Posted3 months agoActive3 months ago

speckx

49 points

34 comments

oddbird.netTechstory

calmmixed

Debate

60/100

CSSWeb DevelopmentUi/ux

Key topics

CSS

Web Development

Ui/ux

The article discusses potential improvements to CSS units, sparking a discussion among developers about the best practices for unit selection and the limitations of current CSS capabilities.

Snapshot generated from the HN discussion

Discussion Activity

Very active discussion

First comment

Peak period

Day 3

Avg / period

11.3

Comment distribution34 data points

Loading chart...

Based on 34 loaded comments

Key moments

01Story posted
Sep 29, 2025 at 9:13 AM EDT
3 months ago
Step 01
02First comment
Oct 1, 2025 at 8:04 PM EDT
2d after posting
Step 02
03Peak activity
25 comments in Day 3
Hottest window of the conversation
Step 03
04Latest activity
Oct 14, 2025 at 5:35 AM EDT
3 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (34 comments)

Showing 34 comments

alberth

3 months ago

4 replies

After 30-years of CSS, we’re still debating what is the best unit to use.

lmm

3 months ago

4 replies

What would it take to get people to abandon the whole thing? CSS has never delivered on any of its promises, yet somehow people still defend it.

duskwuff

3 months ago

1 reply

What would "abandoning" CSS even mean? Going back to table layouts? (Oh good lord no.)

Anyways, CSS is fine. The problem space is complicated.

lmm

3 months ago

3 replies

> Going back to table layouts?

Nested tables and inline styling yeah. It works better. It's always worked better, unless you're handwriting your HTML, and virtually no-one does that anymore.

maxbond

3 months ago

You should check out Flexbox and Grid. They're fantastic and aren't as brittle as table layouts (eg you can reflow things on mobile rather than having a big horizontal scroll bar). There is some complexity but the dev tools help a lot.

https://css-tricks.com/snippets/css/a-guide-to-flexbox/

https://css-tricks.com/snippets/css/complete-guide-grid/

As an aside, hand-rolling HTML templates is still pretty common (such as for SSG themes), which is substantially similar to hand-rolling HTML. You just get `if` and `for` and a couple other primitives.

rjh29

3 months ago

So simple. Want a fancy border? Just make 9 images in photoshop and put them into a 3x3 table with your text inside. Those were the days...

baggy_trough

3 months ago

I for one don't miss the one pixel spacer gif.

fijiaarone

3 months ago

2 replies

Tailwind is the solution to CSS

geuis

3 months ago

Tailwind is a hot bloat of a mess. Adds tons of crap to html elements. It's mostly popular among frontend folks who haven't taken the time to actually learn css.

I still remember the star selector pattern to prevent IE6 from reading malformed css. So me old.

But having grown up in my early career during the transition from embedding styles into html to sites like css zen garden, I am extremely critical of modern "frameworks".

I still see so much bloat in poor performing pages and often when I dig deeper it's tailwind in addition to other inefficiencies adding repeated cruft that doesn't help with site rendering.

A proper 20 year old understanding of css class style inheritance isn't hard, and it negates 80-90% of the complexity of maintaining complex web apps (react components mainly).

CSS grids are cute and useful, but for a hell of a lot of web interfaces a simple float and clear:left still works wonders.

bryanrasmussen

3 months ago

so you've decided to use Tailwind, now you have two problems: you don't know CSS and you're using Tailwind.

tyleo

3 months ago

I disagree. CSS can do a lot. I find myself yearning for it when working in non-web UI frameworks.

easyThrowaway

3 months ago

> What would it take to get people to abandon the whole thing?

A new styling language, with better syntax, written taking into account real-world scenarios, widely deployed across all browsers (or at least cross-compiling into CSS)?

I wouldn't hold my breath.

geuis

3 months ago

Agreed. I always used px versus anything else. It made for the easiest conversions from designer to interface. Was predictable and consistent for almost all users.

It has never translated well to custom font settings from a user browser, but it turns out those are exceptionally rare vs people who just ctl/cmd +/- on the keyboard or pinch and zoom on the phone.

bryanrasmussen

3 months ago

After a few years of the comparison and math functions used in this article being widely available this article was written showing how to use them to improve CSS sizing. Not quite as punchy I guess.

paulddraper

3 months ago

After 70 years of programming languages, we're still debating what is the best language to use.

FrostKiwi

3 months ago

3 replies

Doing lot's of WebGL, I'm still surprised we don't have a way to describe things in native screen pixels, but rely on a mix of dpr [1] and using 4 corners of a DOM object [2] to calculate true size in relation to CSS pixels. Works great across all platforms, but still doesn't give true pixels in certain combinations of screen DPI and resolution. I understand why web has to be this way, but it still baffles me that such a basic thing is so hard.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Window/devi...

[2] https://stackoverflow.com/a/35244519

paulddraper

3 months ago

2 replies

I don't really understand your point.

This is common among visual technologies.

There are logical pixels, an abstract description of size.

And there are physical pixels, that are the actual dots of color.

---

This is not unlike a printed page of text.

The font size is measured in points.

The physical output is dots and determined by DPI.

01HNNWZ0MV43FF

3 months ago

2 replies

Yeah but when I'm making a game it would be nice to render exactly the right amount of pixels for a desktop display

I targeted Firefox and ended up with some bonkers magic constant where a pixel was actually like 1.05 pixels or something.

If I don't render enough it'll be blurry. If I render too many it's wasteful. If I am slightly off then the filtering will make it look weird

It's not a phone with a Bayer matrix, it's not VR, I don't know why they have to be weird about it

SAI_Peregrinus

3 months ago

1 reply

If I play your pixel-exact game on my 21" diagonal 3840x2160 pixel monitor, does it show up as 1/4 the size from when I play it on my 21" diagonal 1920x1080 monitor?

FrostKiwi

3 months ago

That of course depends on the implementation. The point is not the game or the UI ignoring DPI scaling or browser zoom, in fact you would want to support that. The point is, that you cannot do so on a pixel perfect-level across the board, because the widely supported way to do so, DevicePixelRatio, is just that: a ratio with precision issues under certain combinations of screen dpi and browser zoom.

The browser can do pixel perfect rendering, it has to for sharp text. But in WebGL there is no reliable way to get the coordinates to do so as well. Browser specific ways to do so exist, but using standard APIs doesn't work browser zooms like 130% or DPI scales like 1.25 in combination with certain resolutions.

paulddraper

3 months ago

1 reply

To be honest, a lot of what you're saying doesn't make sense.

But yes you can have "bonkers" devicePixelRatio. Namely, when the browser is zoomed.

Logical pixels measure UI "size." And Physical pixels (logical pixels * devicePixelRatio) is the number of dots.

Your game layout should target logical pixels. And rasterization, textures, etc should target physical pixels.

If weird devicePixelRatio causes problems with a lot of pixel-exact UI, you may choose to use your own logical pixels that has a rounded devicePixelRatio.

---

I have a MacBook with a retina display. Versus a non-retina display, I would not expect that everything is 2x smaller, but rather 2x more detailed (or, if not that, the same level of detail but same size). That important distinction is reason for two different constants.

FrostKiwi

3 months ago

> If weird devicePixelRatio causes problems with a lot of pixel-exact UI, you may choose to use your own logical pixels that has a rounded devicePixelRatio.

Exactly that is unfortunately not possible, you may or may not get off by one resolution.

> I would not expect that everything is 2x smaller

Of course.

> but rather 2x more detailed

That's specifically the thing you cannot guarantee, as sometimes due to lack of standarization, it maybe 2.01x size, leading to those UI elements being the right size, but slightly blurry due to pixel grid mismatches.

FrostKiwi

3 months ago

Very much unlike printed text, for 3D and 2D rendering, the difference between native and non native resolutions is huge in terms of sharpness. A whole host of rendering techniques give subpar results if that cannot be guaranteed, even if off by one pixel. It's a basic necessity, that in WebGL you may or may not have.

o11c

3 months ago

1 reply

Use an img srcset and inspect currentSrc?

bawolff

3 months ago

2 replies

window.devicePixelRatio ?

FrostKiwi

3 months ago

DevicePixelRatio changes with screen DPI and browser zoom, some combinations result in repeating decimals. You will get off by one pixel rendering and thus a sudden loss in sharpness due to the whole canvas getting bilinear interpolation.

o11c

3 months ago

Parent said that's not reliable apparently.

jdashg

3 months ago

1 reply

Well unfortunately, the device pixel size of something does actually depend not just on the css size and dpr scaling, but also on position and iirc even potentially what else is on the page due to think like border and thin line dilation. Unfortunately that's just how css layout works in practice, due to pixel snapping and dealing with ambiguities in how to render thin or generally non-integer-sized elements.

There are two approaches these days though: https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/W...

FrostKiwi

3 months ago

> There are two approaches these days

I'm aware of those, it's just sad nothing is nailed as a standard. Those are two workarounds unfortunately. A browser API not supported on Apple Safari and pixel-presnap with JS doing the CSS px calculation backwards + snapping and even that code has an extra branch to fix a macOS+Chrome bug. The whole situation smells of duct tape.

Sniffnoy

3 months ago

Looks like the title-mangler mangled this title.

tyleo

3 months ago

I use px. It seems less likely to break and most zoom setting I’m a custom to respect it (e.g., pinch, browser zoom).

On some em-based websites I’ve seen them break at high zoom levels defeating the purpose.

koolala

3 months ago

The real world units like mm and inches would be amazing in VR one day.

eduction

3 months ago

Auto editing rules written by subliterate YC partners made this headline completely illegible. Almost as bad as techmeme headlines.

zamadatix

3 months ago

I'm not sure which part of their set of approaches this stems from, but loading the page on my screen with standard DPI and zoom makes the article font a hard to read (due to size) 39.2 px. Zooming out to 25% it does get to a down reasonable effective size but the calculated font size became a silly 121px at that level.

View full discussion on Hacker News

ID: 45413330Type: storyLast synced: 11/20/2025, 12:29:33 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN