In order to take advantage of the cascade of CSS, you should set a solid CSS base. Many web developers have been dealing with this topic for a long time. Eric Meyer released the first version of his well-known CSS reset in 2007 and updated in 2011. Meanwhile, other ways to set a CSS base have been established.
In my projects I like to use the normalize.css by Nicolas Gallagher and Jonathan Neal to remove browser differences in the rendering of standard elements at the beginning. This is what my own global styles of HTML elements are based on.
Recently I became aware of the project sanitize.css by Jonathan Neal, who now goes one step further and omits some properties (for older browsers) and introduces new constructs.
CSS reset and CSS normalization
You have to be aware of what happens during a CSS reset and what a CSS normalization wants to achieve. The greatest effect of a CSS reset is the removal of all outside and inside spaces and frames on all elements. This will actually be done at many places in the project. However, you have to explicitly reset the spacing for everything.
Example CSS-Reset (in this case not the one from Eric Meyer!)
* {
margin: 0;
padding: 0;
}
ul {
padding-left: 2rem;
}
/* Bei Annahme folgender Nutzung: <ul class="nav"> */
.nav {
padding-left: 0;
}
The typical way when using a CSS reset: First, all spacing is removed. At the same time, you want all lists in the content area to be indented, so the list is globally styled. This styling is then also applied to all lists that were actually treated with the reset.
Eric Meyer clearly emphasizes that his reset is not set in stone and should be seen as a starting point for own basic styles. So one could also leave out the ul (in case of Eric Meyer’s reset) from the long selector and format it separately (without removing the spacing).
The idea of normalization
Standard styles from the browser are a good thing, because this way every HTML document is displayed readable without any style sheet. This is exactly the point a normalization like normalize.css considers. The goal is to display the elements more consistently across browsers, but to keep User Agent Styles as consistent as possible or to standardize them according to standards.
We now have to live with the fact that the user interfaces of different operating systems or browsers are not the same. This also affects the display of some HTML elements, e.g. input fields, checkboxes, buttons, lists, tables, etc.
Instead of “turning off” the default styles with a reset, it is a good idea to try to compensate for different rendering behavior with a normalization.
This is where ready-to-use collections of normalizations like the normalize.css or sanitize.css.
presented above help.
I tend to work with a normalization rather than a (customized) CSS reset.
Differences between normalize.css and sanitize.css
In essence, sanitize.css can be seen as a further development of normalize.css, which takes a different approach to browser compatibility. While normalize.css also considers older browsers like Safari 6 or IE 8 , the browser landscape at sanitize.css in the direction of the current requirements of projects.
Normalize.css provides a super base that changes sanitize.css as follows:
- CSS inheritance is becoming more universal
- The box model is more intuitive by default
- Unification of the rendering of monospace fonts
- Text in selections has no shadow for the sake of readability
- … and others
- Introduction of a CSS reset à la * { margin: 0; padding: 0 }
- /li>
Jonathan Neal must be credited with the fact that the reset falls into the category “Opinionated“. In this, according to his opinion designed group, he classifies most of his rules. I like this open and honest way of sanitize.css especially well. This is also evident in the fact that all useful options are stored in overwritable variables, which makes sanitize.css even more likeable.
Both collections convince with a very good documentation (as comments in CSS) Each rule is justified by stating the browser (version) in question.
Conclusion for a CSS base
Since each project has different requirements for the browsers to be supported, it is not optimal to simply blindly use one of the known normalization stylesheets.
I recommend to look at the CSS rules of both collections, understand the differences and reflect this on the requirements of the project. As a result, you will automatically get a own normalization, which is well thought out.
This may seem complex at first glance. However, if you often work on similar projects, I see potential for reuse. Also, you might be able to get by with a smaller set of normalization rules, since you don’t use all HTML elements for which there is a normalization CSS.
If it has to be fast, I personally still rely on normalize.css. How do you see the topic?
Comments