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.
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.
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.
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
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.
Looks like the title-mangler mangled this title.
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.
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.
The real world units like mm and inches would be amazing in VR one day.
Auto editing rules written by subliterate YC partners made this headline completely illegible. Almost as bad as techmeme headlines.
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.
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 "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.
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.