A website that is maintained in a long term will be worked on by many people, and CSS will become quite large and complicated. So using the simple constructs like pixel units is better than using rems that create implicit dependence on main font size. This way there are less chances to break something in one place when editing code in other place.
The same is about CSS variables. An example with one variable might look nice. But what if your code has hundreds of variables? It would take more time to understand how they are related and how do I change the size of this button without breaking something on another page.
If you hard-code everything in pixels, you have the same implicit dependency as with rem. It's a design, after all! Things have to "fit together". You're not changing every element's font size to an individual value and on a whim.
But now you have to keep all those relevant "main font sizes" in your head and do constant divisions. rem units give you the ratio directly.
Correct me, but I can tell what 16px is, not 1rem. 1rem can be 16px, 18px, 2000px. When you see tons of relative units, you need to doble check what it's going on. With pixels you see explicit values, so no double checkings.
Yes, but a typical change request would be something like "make this menu font size larger", and in this case having menu independent from other parts of the page is better. Also, if you build a framework with variables, dependence on root font size, it would be complicated and most devs won't like to spend time learning it and thinking how to solve their task within it. Simple is better here.
If you code everything in pixels, your site only will look good on your particular screen. This has become so much of a problem that browsers now use a ‘standard’ pixel that is divorced from an actual pixel. I also find sites that do everything in rem/em more assessable as the padding also scales if they have a increased font size due to low vision.
Also, hardcoding things instead of using variables makes things harder to maintain. If someone didn’t use variables randomly, it’s easy to update the CSS to match. Ideally, you have one css (less, etc) file that defines that variables and their relationships, just like a .h file in C, so you can quickly grasp what each variable does.
> I also find sites that do everything in rem/em more assessable as the padding also scales if they have a increased font size due to low vision.
If you use Ctrl +/Ctrl - for zoom, then everything scales proportionally regardless of whether you use pixels or rems. You are trying to solve the problem that has been already solved by Opera, and later by other browsers more than 10 years ago.
> Also, hardcoding things instead of using variables makes things harder to maintain.
In my experience, it is the opposite: simple code without implicit dependencies is better. Because the typical task would be to change one part of the page without affecting other parts. With a simple code, I would use DevTools to change the CSS rules and then I would move the changes manually into CSS file. But if the site uses some complicated framework with variables and rems, I will have to spend time learning it, see where is a variable defined, what can be affected if I change it, etc. It just takes more time and nobody of the devs will want to learn your custom-made CSS framework.
Using Zoom for reading is less ideal for long term use as it generally forces you to horizontally scroll, where as increasing font size reflows the page, so only vertical scrolling is needed.
Like most things on the modern web, it is complicated. There seems to be a way, which I never noticed before HTML5 hit, for the web page to specify that certain text will not wrap, but rather will just run off the right edge of the viewport if the viewport is too narrow, but it is not in common use.
and
> I recommend using pixels for projects that are going to be maintained and developed in the long term.
Directly after lambasting the author for failing to elaborate, perhaps you could go into more depth yourself?