Should I customize the normalize.css file? - css

Question

When starting a new project it is always the question which tools, frameworks and libraries to use. I often included the Eric Meyer CSS Reset, but this time I will switch to Normalize.css. I understand it as a customisable starting point rather than a library. I suggest to include the normalize.css file and overwrite specific parts of it. But i am not really sure, if this is the correct way. It would be hard to update the normalize.css file than. It seems Normalize.css is not sure either.
From the documentation at github.com
Normalize.css is a customisable CSS file that […]
README.md, Line 3
It is recommended that you include the normalize.css file as untouched library code.
README.md, Line 21
What would you suggest?

Answer 1

I am guessing this will get closed as it is a question open for debate. However, I would still like to add something to the discussion.
As normalize.css (or any reset css file that I know of) is distributed as a plugin package file, there should be no fault in altering it to your needs. It can be compared to the search for the right break-points for media queries. The truth is, there is no one-way street to follow, it's a delta: every one has to adapt to their project. This also means every developer has to write project specific code. One project might need the first breakpoint to be at 480 px, whereas another project doesn't take mobile devices into account any way, but it does provide very high-resolution displays. Every project is unique, and your code should reflect that.
That being said, exceptions can be made. Libraries, plugins and particular snippets can be used over and over again without any modification. In the case of libraries and plugins, there is some freedom in use per project by means of arguments passed to call to the library or function. For instance, when using jQuery, I will not always write the same code in my scripts file, of course not. That's because a library is only a means to an end, and not a stand-alone package that provides functionality in itself. A plugin (in the wide context) such as, for instance, Modernizr, is another beast all together.(1) The question then arises, what is a CSS reset in this respect? Most will say it's a plugin, and I agree. But should plugins be edited?
I think they can.
Take for example Wordpress plugins. Loads of topics are to be found on the internet concerned this discussion: should they be edited or not. Many peeps advise against it. I don't, and never will. For the simple blogger that wants to add functionality to his or her blog, a plugin in itself should suffice. But we, as web developers, might want more options (or less, to optimise the experience or speed). As long as the dev in question takes updates into account, altering a plugin has no consequence. Why should it?
The same goes for a CSS reset. As I said before, every project has (a) specific stylesheet(s), often one overwriting values in the other. But what good have you on a rule such as this:
/* normalize.css */
h1 {
font-size: 2em;
margin: 0.67em 0;
}
which you then overwrite by your own rules:
/* your-stylesheet.css */
h1 {
font-size: 1.8em;
margin: 0 0 0.8em;
line-height: 1.24;
}
This is ridiculous, doesn't it seem so? I would then advise to edit normalize.css.
However...
Everything I have written down so far (quite a lot, I admit) considers a single project. But what if you often build your own websites, or if you have many sub-sites to a main site and so on? And how should you organise your workspace (directory structure in this case) accordingly?
In the case of sub-sites (for instance websites or projects running on a sub-domain which use the same ftp source but that use a different styling guide) I would advise to use the unaltered normalizer. By doing so, every project has to be modified by rules that have been defined in normalize.css but it keeps you from having duplicate (yet different! for you have edited them per project) normalize.css files spread across your ftp server. Your folder structure would then look like this
- root
-- /index.html
-- /css
--- /normalize.css
-- /project-name-1/
--- /index.html
--- /css
---- /style.css
-- /project-name-2/
--- /index.html
--- /css
---- /style.css
-- /project-name-3/
--- /index.html
--- /css
---- /style.css
This means that index.html in the root shares the same reset (normalize.css, un-edited) as all the (sub-)projects.
To summarise: in an individual project that stands completely alone I'd edit the normalize file and simply see it as a base file to get started with. It's a good guideline, but some things just don't fit a project's needs (for example the heading declaration I mentioned earlier). I myself SCSS-ified and edited normalize.css to fit my needs, and use that as a base file for all my websites. Just keep one copy of it somewhere, and when you get a new project: copy it, edit it, and use it.
1: I am aware that not everyone would agree with me on this distinction. It is based on DOM manipulation: jQuery, for instance, allows functionality, i.e. the possibility to execute functions. You cannot call jQuery which would then trigger an action or manipulation. The basic function of Modernizr, for example, is different. When called, it executes functions and checks functionality of the browser (and adds classes to the DOM).

Answer 2

I decided to use Normalize.css and Reset.css to write my own defaults.

Answer 3

I don't think it's necessary to customize Normalize besides the default font-family, font-size, line-height and some other optional things.
I created Initialize.css, a collection of best practices like normalize and made it configurable with SASS (scss) (there is a css version as well). In this case, you could use normalize and set you own default font-familty, font-size and line-height and if you need some margins to elements like paragraphs and headings. You don't start with CSS overwrites, and that's awesome! :-)
http://jeroenoomsnl.github.io/initialize-css/