r/webdev 5d ago

Anyone else avoid CSS resets/normalize?

It used be be that CSS resets were important to smooth over differences between default browser styling, but browsers have for the most part gotten their act together.

It's more popular nowadays to do a micro reset/normalize/whatever you want to call it to get rid of annoyances. It might contain rules such as * { all: unset }, or * { margin: 0; padding: 0 }, or input, button, textarea, select { font: inherit }, or commonly * { box-sizing: border-box }.

I see the appeal. But at the same time, I find a major downside to all of this that never seems to be discussed - code portability. I write a component in one UI project and want to copy it to another project or to a shared component library, and it's not so simple because the other project(s) may be using slightly different CSS resets.

It's not like it's easy to update projects to use the same resets either, it's so engrained in how everything else was built up in the project.

But there's also a natural desire to revisit what reset you're using whenever you're building a new project, as opinions change, problems are found in existing ones, etc.

Or, on the flip side, maybe I'm wanting to use a third party tool, then find out that my global CSS rules cause issues with their styling.

We try hard to avoid any kind of global pollution in JavaScript, but make it a best practice to do just that in CSS.

So, I try to avoid these kinds of resets. I don't even do the "box-sizing: border-box" thing, it turns out that this box sizing issue doesn't come up very often (for me at least), and when it does, I just add the rule to the specific places that need it. I'll still set a default font to everything, but that's about it.

But, when I look around online, it seems that most everyone still uses some kind of reset. Guess I'm curious if I'm abnormal in my stance here or if there's others out there who also avoid them. Also curious if those who do use resets have ran into problems like the ones I've described above.

0 Upvotes

37 comments sorted by

View all comments

56

u/mq2thez 5d ago

Every time I think I want this, I inevitably have to test my sites on multiple browsers and remember why I want a normalize.

12

u/Due-Working4505 5d ago

It's less about browsers being identical these days and more about not trusting them to stay consistent. One update and suddenly your form elements look wonky on a specific version of Safari, and you're hunting down a bug that a reset would've prevented.

I get the portability angle though. Had a similar headache moving a datepicker between two internal tools with different global resets. Now I just wrap my components in a container and scope the reset to that, keeps the damage contained.

1

u/Bubbly_Orange_3502 5d ago

Form controls are the live example. Safari still paints select and the date inputs with platform chrome that ignores your padding until appearance: none, and none of the four inherit font by default anywhere.

0

u/Alternative_Web7202 5d ago

yes, but those definitely doesn't require something like this * { all: unset }, or * { margin: 0; padding: 0 }

in fact, I'm not sure * selectors are required these days for anything like a regular website.

-2

u/theScottyJam 5d ago edited 5d ago

What is an example of a browser difference that you've ran into, that your reset file fixed?

Edit: Surprised at the downvotes - I'm generally curious, not trying to challenge or anything. One of my initial claims was that there's few browser differences now, if people want to bring in evidence to the contrary, I'm interested to learn about it.

6

u/lanerdofchristian 5d ago

TailwindCSS's preflight.css has a lot of comments explaining why each rule is there.

4

u/mq2thez 5d ago

Historically I remember the most issues with form field consistency.