The CSS Reset Contradiction

For two decades, the web and front-end development field has been using CSS reset (for simplicity, "restart" and "standardization" are included here). I say "about" because Tantek Çelik seems to have started all this in 2004 (you can find me there too), but other authors may have used similar techniques earlier.

Basic premises

CSS reset is based on three premises:

1. There are differences in the way user agents present web pages, i.e. their default styles vary.
2. These differences affect a given website.
3. These differences are important and need to be dealt with.

It is obvious that if—or once—all user agents handle CSS the same way, then there is no need for a CSS reset.

It is also obvious that if the difference does not apply, a CSS reset is not required. For example, form style differences do not matter on formless sites.

And—many arguments have unnecessary arguments about this—it also means that if the difference is not considered important enough, a CSS reset is not required.

I believe that over the past 20 years we have seen not all authors focus on whether style differences between user agents affect them and whether those differences really matter.

However, there are other problems.

Reality

For CSS reset users, the reality is that they feel they need to use CSS reset. CSS reset users may (or may) not think that they either use it because they have to use CSS reset or they feel it is safer to use it. However, from a practical point of view, using CSS reset is also part of their reality.

CSS reset users ignore another reality, namely the reality of developers and website owners who use CSS reset. This can be explained by the premise outlined above, but it has two reasons to note.

In the context of CSS reset, there are almost never discussions on the existence of websites and applications that do not use CSS reset and work properly without CSS reset.

1. The positions we observe in practice ultimately lead to contradictions when we take extreme positions that always need and never need CSS reset. P & ¬P. *
2. ^{While the premise allows for reconciliation of contradictions, the problem remains: In our discussion on CSS reset, no one seems to admit that there is a website that works without a reset—which fundamentally challenges and refutes CSS’s fundamentals The view that the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology of the ideology This is neither correct nor helpful.}
Is this all? No:

Convenience

CSS reset has become a product form. There are a lot of CSS resets (the search shows more kinds than the best sets I can find) and they are baked into some HTML/CSS and even JS frameworks.

This makes it easy for developers to forget the premise and assume that CSS reset is generally required.

So we could observe a long time ago that people stopped questioning their use of resets, even if they might not work. ^†

Consequences

Similar to the effect of publishing invalid and fictional HTML, all of which are eroding the craft of front-end development.

What are our choices?

First of all, we need to clarify the premises behind CSS reset and incorporate these premises into our discussion. This will make the discussion less hot and make better decisions.

Secondly, we need to conduct a reality check. There are a lot of websites and applications that don't use CSS reset and work fine in all user agents. This is part of our reality, and given the performance and maintenance footprint of some CSS resets, it's a reality worth watching.

Thirdly, we need to challenge each other, and perhaps more importantly, challenge ourselves. It seems natural to seek convenience, but it is important to clarify the consequences - convenience can easily lead to complacency, dogma, and ultimately ignorance. It is useful to make our developer life a little harder.

When we do all this, we should be at a place we could get to 20 years ago—a place we very selectively use custom resets, most likely only in high-tech Used in environments with great variability in complexity or developer qualifications. But this is just speculation, about the status quo we don't have.

*The title is intentionally left incomplete.

Thanks a lot to Miriam Suzanne and Jad Joubran for reviewing this article.

^* Contradiction is especially fascinating if you think in formal logic, contradictions allow any conclusion to be drawn.

† This is why the "CSS reset first rule" is lost: After setting up a website with reset, you must test at least once if you don't use reset.

The above is the detailed content of The CSS Reset Contradiction. For more information, please follow other related articles on the PHP Chinese website!