To compile ConciseCSS files with Pug files as well.

This is just an idea, it looks interesting but might have unintended consequences.

UPDATE: This might be part of the new Concise CSS Preprocessor. Not in the current Concise CSS framework.

UPDATE 2: See first comment.

Normalization styles consume unnecessary space in stylesheets of simple websites. For example, the current minified file of Concise CSS (v4.0.1) weights 12.4 KB, and a big part of those styles are to normalize form elements; Most of the time, simple websites don't have forms on them, so the form normalization styles are unnecessary.

The usual way to prevent the pollution of stylesheets is to include just the files that we need, but often, a single file contains already several unnecessary rules.

This idea brings a new option. Instead of including a normalization file, a normalization property is used, providing a target normalization as a value.

Benefits:

• Since the normalization rules are now provided by the compiler, the developer won't need to install the concise.css library. And as a consequence, they won't require to include any file. Writing just the project styles will do the job.
• Lightweight stylesheets.

Possible problems:

• Confusion.
• Increased complexity when defining normalization rules in the compiler.
• Nested selectors might have problems. The normalization styles should only apply to a single element.

Considerations:

• Since the user will probably want to override the normalization rules, the compiler will need to delete duplicates inside each rule. Where the user defined rules have priority over the normalization ones.

Example 1:

The following example might work, but there is repetition between the selector and the property value.

input {
  normalize: input;
  // My styles here
}

h1, h2, h3, h4, h5, h6 {
  normalize: heading;
  // My styles here
}

h3 {
  normalize: h3;
  // My styles here
}

Example 2:

The following example includes a different approach using a pseudo-selector:

input:normalize {
  // My custom styles here
}

h1, h2, h3, h4, h5, h6 {
  &:normalize {
    // My custom styles here
  }
}

h3:normalize {
  // My custom styles here
}

In both cases the custom rules and the normalization rules would be merged and duplicated removed.

Example:

.smaller {
    // Smaller size in the scale
    font-size: 1;
}

.heading {
    // Bigger size in the scale
    font-size: 4;
}

Problems:
How we should define the ratio that will generate the scale.

It would be more flexible for custom features and probably more efficient to completely replace Sass with Post CSS plugins.

Add a -w flag to watch for files, by default, it should watch **/*.scss files, but it should accept a different value too.

While we use Sass there is no necessity for custom media queries.

This should replace the use of the getColor() function.

Could be something like:

@custom-color primary #abcdef

p { 
  color: primary;
}

Inspired in the syntax of https://github.com/postcss/postcss-custom-media

• concise init
• concise init addon

It's useless.

The pr unit is easy to implement, but the pe will probably require setting manually the parent font-size.

Probably something like 24/16pe where 24 is the size in pixels and 16 the font-size of the parent. 24pe will assume the font-size of the parent as the same of the root element.