> Bump that body copy to render close to 16px or more

also known as the default font size in browsers, don't you dare override the user's preferred font size for body copy, scale everything else in units of rem instead.

> don't you dare override the user's preferred font size for body copy

I’d bet you that 98+% of users don’t even know you can change the browser font size. For that overwhelming majority of users the size reported by their preferences and their actual preferences do not necessarily align. This is not a defence of setting smaller-than-16px font sizes, but it is a defence of setting larger sizes if testing shows it improves user experience.

> I’d bet you that 98+% of users don’t even know you can change the browser font size.

The users that need that to be able to read (e.g. vision problems) definitely do know that. It's about accessibility

I disagree, I field a lot of reasonable adjustment requests and a staggering number of people don't know about basic functionality. They are also not interested in them.

I’m not going to re-solve problems for users that already have a solution but refuse to use it.

> This is not a defence of setting smaller-than-16px font sizes

See: HN, that sets a "10pt" font size, otherwise known as 13px.

At least they have a reason and it fits for me. :)

On the contrary, I've always found HN's font size to be one of the worst parts about the UI. I actually have a userstyle set to override it

  body {
      font-size: larger;
  }
  
  .comment, .default, .comhead {
      font-size: 14px;
  }
  
  .subtext, .pagetop {
      font-size: 13px;
  }
  
  .title {
      font-size: 16px;
  }

It's not the prettiest CSS or the most well done, but it works and it's better than the defaults imo.

I do use HackerNews at 150% because otherwise it's unreadable

They do on mobile.

Don't scale everything in units of rem; we want "zoom text only" to continue to do what it says on the tin. Only scale the things that need to be text-sized.

Things like border-radius are especially fun to watch then they're sized in rem.

What was a regular border, eventually becomes a half-circle.

Also spacing/padding increases to much that then at some point you only have like 1 word per line, and the screen is half blank space

Is there a reason for certain CSS frameworks like Tailwind to scale absolutely everything in units of rem and ignore px like the plague? Or is that just too far?

I did mean font sizes though. :)

Incompetence, and thus obedience to a mistakenly-generalised caricature of "good practice", is my guess. I used to use em everywhere for exactly this reason. (The only reason I didn't shift to "rem everywhere", "flexbox everywhere", "web fonts everywhere", etc. was obedience to some different caricature of "good practice".)

I've never seen a CSS framework that's good. (Unless you count https://simplecss.org/, but that's of very narrow usefulness.) They're all made by the kinds of people who don't understand web technologies, and seek to hide them behind a layer of abstraction so they don't have to think about them any more. Unfortunately for them, there's a reason the web's how it is. Some of it's backwards-compatibility, but most of it is that a large group of very clever people failed to find a way to make it any simpler without breaking something important; and so, the framework people tend to break important things.

If you find yourself reaching for something like Tailwind or Bootstrap, just use inline style attributes. It's easier for everyone involved.

Good luck using pseudoclasses, pseudoelements or media queries in inline styles.

Wrt Tailwind I still have not used it enough to decide whether it is good™ but it is not that different from writing inline styles.

Apart from optional plugins it is more like a CSS preprocessor than a framework (every class expands to one or few CSS declaration)

The most frameworky features it has is that it predefines CSS variables to allow further customization

If you need any of those things, you should be using a proper stylesheet. Use <style scoped='scoped'> in the <body>, if you really must.

A crude "not that different from writing inline styles" classy framework just makes it harder to refactor your CSS in future, because it's all tucked away under incomprehensibly-named CSS classes, and there are otherwise-useless <div>s all through the HTML.

I should clarify that I primarily touch html via React, so the unit of reusability is not CSS but rather components.

For handwritten html I believe that tailwind has significant downsides (unless you abuse @apply), but that the case I focus on.

I should have mentioned that I believe tailwind to be applicable only if you have some strong templating support

> Use <style scoped='scoped'> in the <body>

This seems to have been removed from everywhere since at least 2017

Joke's on you: I avoid inline CSS like the plague whenever I can. Which is to say, I use it as intended.

This does not suprise me, inline CSS is very unwieldy

Everyone jumped on the only-use-rem train when mobile started dominating because it provides relative units that scale better rather than absolute pixels.

In practice it doesn't really mean much outside of blog-like text so when doing layouts it's more of just a standard everyone agrees on using everywhere because it's easier to stick to one for consistencies sake and it does the job. I don't think many frontend devs ever test zooming text using a browser anyway, their main concern is variations in screen sizes, basically device variation not manually zooming text. But I get the arguments to limit it to text.

Modern browsers zoom by increasing the CSS pixel size, so now all units are relative

Zoom can use different algorithms, it's a setting.

text-align: justify ruins the readability of the text. Won't ever work until browsers become much better at hyphenation.

Uh, hyphenation ruins readability much worse than justified text.

If you’re interested in sites loading quickly in more… practical scenarios, read this:

https://community.qbix.com/t/qbix-websites-loading-quickly/2...