Break into parts

[necolas]

Might be worth building the normalize.css file from several parts. Perhaps web components would want to import the section of styles their component needs normalized as a base.

[Melindrea]

I think that's a good idea. What kind of building system were you considering?

[porada]

This is a great idea. I can count plenty of times I used Normalize on a simple website that didn’t require table styles or forms and removed those styles manualy. Always yay for modularity.

[necolas]

@porada That's not a use case I care about. A few lines of extra CSS are a drop in the ocean. I'm thinking more about people wanting to including library code in small Web Components.

[dananichev]

@necolas
As far as i understand, you are do not want to use something like SASS, LESS and so on. I just want to ask: how are you planning to do this? I mean, SASS/LESS has build-in modular structure plus mixins/variables and so on. But CSS supports only @import. And it's pretty bad.

[crispen-smith]

As a general rule I'd always say +1 on a more modular approach. What the end user does after that is up to them, whether it becomes a normalize.scss that is only a series of import calls or a pattern that mimics the modular require.js call described here: http://www.codeproject.com/Articles/614507/Modular-Javascript-Using-Require-Js?utm_source=javascriptweekly&utm_medium=email

[pkill37]

+1

[thezoggy]

There are so many rules that bleed over.. to really make it modular would require more verbosity in defining the rules.. which in turn makes it more of a pain to maintain/update the project. I see this request doing more harm than good... plus its not like one cant just remove the things they don't want manually.

[StefanoRausch]

If Sass is used, #290 could be a viable solution.

[StevenTew]

@necolas where in the current CSS do you picture it being sliced? At each section heading or do you have something more specific in mind?

[electricessence]

https://github.com/electricessence/normalize.less (fork of normalize.css)
Broken into LeSS partial files (prefixed with _ and rendered via gulp).
I then added extended partials for forms.

[electricessence]

It's very nice to have in separate files because then each partial can be tracked individually.

[thezoggy]

I see little gain in breaking it apart... It's not that big and changes are usually minor/few lines.. This git history works fine...

-----Original Message-----
From: "electricessence" notifications@github.com
Sent: ‎3/‎2/‎2015 3:06 PM
To: "necolas/normalize.css" normalize.css@noreply.github.com
Cc: "thezoggy" thezoggy@gmail.com
Subject: Re: [normalize.css] Break into parts (#222)

https://github.com/electricessence/normalize.less
Broken into LeSS partial files (prefixed with _ and rendered via gulp).
I then added extended partials for forms.

---

Reply to this email directly or view it on GitHub:
#222 (comment)

[electricessence]

@thezoggy, I think that's a matter of preference mostly. Personally, I think it allows for a better starting point for evolving it. Pull requests become more isolated and there's less worry about if a particular category has been polluted.

[eltonmesquita]

If this is to ever happen, I think that an approach similar to the current animate.css build system would be the best option. It doesn't use any pre-processor, just separated css files that are concatenated according to the config.json file.

Grunt makes this possible and pretty straight forward.

[LukeAskew]

👍 for adopting a pre-processor, specifically Sass.

Using Sass not only gets you the partials, it would allow us to directly configure a normalized stylesheet through default variable overrides.

Something like this: http://sassmeister.com/gist/4746464753189c9ab393

This would help fulfill the project's description of a "customizable CSS file".

[electricessence]

@LukeAskew after toying with both SASS and LESS, I have to pick less for it's greater flexibility. Not that you couldn't use sass to do this, but I can also easily run gulp-less-to-scss if you still want .scss versions.
"What can LESS do that SASS can't?" You might ask? We'll there's quite a bit actually. LESS can take closures and can also concatenate class names in ways that SASS can't.
If you disagree, then look here (https://github.com/electricessence/css-helpers/blob/master/table-cells.less) and tell me how you would make this work the same in SASS without adding more code or redundancy. But let's not make this thread a SASS versus LESS debate. They both work. And if you want a .scss version, let me know.

[tbremer]

holy unqualified selectors batman. 🍻

[anEffingChamp]

How will this affect a user who just wants an agnostic CSS file?

[eltonmesquita]

@anEffingChamp That's why I'm suggesting a simple pure CSS build system. I don't think that a pre-processor will help normalize.css in any way. It'll only make it look more biased to a certain workflow. I think normalize should be as universal as possible, as this is its objective any way, so nothing better than pure CSS, right?

[anEffingChamp]

Precisely, a CSS reset is not the place to start introducing biases to a project.

On March 7, 2015 7:05:45 AM EST, Elton Mesquita notifications@github.com wrote:

@anEffingChamp That's why I'm suggesting a simple pure CSS build
system. I don't think that a pre-processor will help normalize.css in
any way. It'll only make it look more biased to a certain workflow. I
think normalize should be as universal as possible, as this is its
objective any way, so nothing better than pure CSS, right?

---

Reply to this email directly or view it on GitHub:
#222 (comment)

[AllyBaird]

@eltonmesquita @anEffingChamp agree with the both of you.

[electricessence]

Hmmmm... I would totally concede that it should be pure CSS and you could simply use a build step that combines the parts. But it seems silly if you are going to break it apart to then miss out on what pre-processors already do (combine CSS). Also, it's not uncommon for web application builders to want to include (and then compile) LeSS/SASS in their project instead of the resultant CSS.

my.opinion != 0

[jonathantneal]

I recommend separating normalize.css into two major sections: normalizations and expectations.

The normalizations section would strictly include declarations that provide missing or inconsistent styling between browsers. Here you would find most display definitions and text-level semantics.

I recommend that each rule or declaration specifically list the browser(s) and version(s) affected. This will be helpful to contributors, cross-browser testers, and every-day developers alike.

The expectations section would strictly include declarations that provide common or useful patterns in modern web developer. For example, normalize.css includes alternative text alignment for sub and sup elements because the universal defaults do not meet most designers’ line-height flow expectations. As another example, the border on images within an anchor is an obscure gotcha unique to this one kind of media. Other expectation examples include the baseline font family as sans-serif, the zero’d table border and spacing, and the hr element styles. While many developers greatly appreciate these changes, they are not true normalizations.

I also recommend that all expectations be made configurable. This would require a more serious change since native CSS yet provides this level of configuration.

Sass Variables could be used to define all the opinionated defaults at the top of the file. These values could be easily overridden inside or outside normalize.scss if the !default syntax were used.

$small-font-size: 80% !default; // used only if $small-font-size is not already specified

small {
  font-size: $small-font-size;
}

In the above example, the compiled normalize.css would remain the same, as these configurations would become hard-coded. You have objected to pre-compilers in the past, but I’m not sure if you have considered this use case.

[jonathantneal]

With tools like PostCSS, we don’t need to break this apart for someone to extract specific rules for whatever reason. And to respond to my earlier comment, all expectations in normalize.css are now labeled as opinionated defaults. Overriding opinionated defaults in normalize.css is trivial and doesn’t really necessitate adding something like a sass version, or a version with css variables.

After 2.5 years of no further input from Nicolas, I’m closing this.