[codedokode]

The code examples are overengineered. For example, the code generator for stack uses rem units and CSS variables, while it could be written without them and have better cross browser support (and the code would be easier to read and maintain in long-term perspective). The author just wants to use modern CSS features without clear rationale for this.

Rem units can cause issues in long term. For example, imagine if a sidebar widget is coded using rems. When later the main font size is changed, margins within widget will change its size, although the font size in it is fixed and didn't change. There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it. He just uses his authority to push his personal preferences to frontend developers who tend to copy the code from tutorials without much thinking.

I recommend using pixels for projects that are going to be maintained and developed in the long term.

[dictum]

This is plain FUD, sorry.

The rem unit is remarkably well supported, going back to IE9, Android 2 and iOS 4.

It has a specific meaning: it's relative to the root element, which usually means it's relative to the font size the user set as the default font size for the browser — 16px by default in most devices. It's not just a stuffy alias for the px unit, used by sneaky developers to make maintenance harder.

It has a semantic purpose, which makes it useful for maintainability: if your body text is 1rem, when a heading should be double the size of body text, writing it as 2rem makes the sizing relationship between these two values immediately recognizable.

https://caniuse.com/#search=rem

[Tomte]

I find your counter-argument against rem units very weak.

What are cross browser concerns here? Why should he even mention the possibility that someone might "fix" an elements font-size? Sure, the author doesn't explain all of CSS and all of UX/UI in an article focussed on a single issue. That's not a mistake.

Your px recommendation is... strange. The article is one of those "newer" CSS articles that care a lot about responsiveness. You seem not to care. Fine, but I guess you're in the minority there.

Your insult against front-end developers (in both your comments!) is simply childish, and frankly, it seems you just have an axe to grind with the author(s).

[jffry]

> There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it.

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?

[codedokode]

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.

[Tomte]

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.

[meerita]

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.

[codedokode]

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.

[extrapickles]

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.

[codedokode]

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

[extrapickles]

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.

[hollerith]

In Chrome, Ctrl +/Ctrl - reflows most text.

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.

[quickthrower2]

> padding also scales if they have a increased font size due to low vision.

rem: automatic for the people

[rimliu]

IIRC the standard pixel was always divorced from the real pixel. Or at least for a very long time.

[rhizome]

>A website that is maintained in a long term will be worked on by many people, and CSS will become quite large and complicated

Non-sequitur. It could also become smaller and simpler.

[ctidd]

On the topic of rems, when using them for layout, you'd use a body font size rather than the root element's font size to control the size of text in your page.

At that point the root font size exists only as a scaling factor, decoupled from the base font size of content within the page, but allowing the user to control that scaling factor via their browser's global default font size preference. In fact, you could think of the rem as root scaling factor unit rather than root font size unit. (The use of the font size property to set the scaling factor is a quirk of the spec.)

This solves the concern you noted on maintainability, while allowing a user to globally opt into larger or smaller text and correspondingly scaled layout across the web, arguably a win for enabling an element of accessibility by default on any website.

[codedokode]

It is not as simple as just replacing pixels with rems. Do you test your markup with different root font sizes? Do you add special rules for cases when the font size is too small or too large? Unlikely. Then you better not pretend that you support scaling the fonts using browser settings.

Also, I think that changing font size in browser settings doesn't work on most sites, so people don't use it. For example, I use normal scaling (using Ctrl + +) on this site and it works good enough, and what's most important, it works everywhere. So there is no need to support changing root font size.

[ctidd]

If you build sites that can support arbitrary viewports, extrapolating to arbitrary scaling factors on a given concrete viewport does not create an explosion of scenarios to manually test -- all you need to know is that your scaling works, and if you always build your functionality responsively, the scaling and responsive layout together just work. (I'm talking about building the whole layout with rems, not just using them for font sizes. For the latter, I'd agree with you that it's brittle and falls apart quickly.)

It's fair to point out that the browser feature is not widely used, but when it is used, it's likely by users who benefit most from the small amount of effort it takes to support it. (It's really a few lines of CSS, plus simply using rems as your websites unit whenever you'd otherwise use px. It's even easier in terms of avoiding weird 16px-based rem calculations if you make your rems 10px for a default 16px browser preference by applying a straightforward conversion on the root element.)

[ww520]

Rem is great. It allows uniform scaling of all UI elements under a parent along with them font size.

[wolco]

Rem is great. px work well. Both can work and not work for different reasons. The extremes on this issue remind me of spaces vs tabs.

[codedokode]

Where is this used? If a user wants to make everything larger then they can use zoom in a browser that works with any units (except for vx, vh, vmin, vmax that break zoom).

[ww520]

Designers or developers.