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.
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.
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?
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.
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.
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 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?
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)?
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.
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.
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.
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
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...
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.
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
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?
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.
Use an img srcset and inspect currentSrc?
window.devicePixelRatio ?
Parent said that's not reliable apparently.
Looks like the title-mangler mangled this title.
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 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.
After 70 years of programming languages, we're still debating what is the best language to use.
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.
[dead]
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.
Auto editing rules written by subliterate YC partners made this headline completely illegible. Almost as bad as techmeme headlines.
The real world units like mm and inches would be amazing in VR one day.