CSS Unit Might Be a Combination | Hacker News Reader

CSS Unit Might Be a Combination

oddbird.net

49 pointsspeckx34 comments

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

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.

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.

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

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.

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

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?

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.

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

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

Use an img srcset and inspect currentSrc?

window.devicePixelRatio ?

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.

Parent said that's not reliable apparently.

Looks like the title-mangler mangled this title.

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

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.

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.

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

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.

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

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.

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.

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

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

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

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

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

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.

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

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

Tailwind is the solution to CSS

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.

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

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

Reply on news.ycombinator.com