There are bugs with some unitless 0.

For example, here are two examples with times (check in Chrome and Firefox to see differences)

http://jsbin.com/ledeb/2/edit
http://dabblet.com/gist/3746116

I think sand ms unit should be preserved, even with 0?

Trying to run cssshrink throws the following error:

Error: Cannot find module '/usr/lib/node_modules/cssshrink/node_modules/csscolormin/index'. Please verify that the package.json has a valid "main" entry

Any idea of what is going awry?

cssshrink, both cli and lib crashes if the CSS input is empty

$ touch emptyfile.css

$ cssshrink emptyfile.css

/usr/local/lib/node_modules/cssshrink/lib/shrink.js:51
  var len = JSON.stringify(ast).length;
                               ^
TypeError: Cannot read property 'length' of undefined
    at traverseAST (/usr/local/lib/node_modules/cssshrink/lib/shrink.js:51:32)
    at Object.shrink (/usr/local/lib/node_modules/cssshrink/lib/shrink.js:66:9)
    at Object.<anonymous> (/usr/local/lib/node_modules/cssshrink/bin/cli.js:8:23)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:906:3

See https://mathiasbynens.be/notes/unquoted-font-family.

The font name in x { font-family: 'lol serif'; } should remain quoted, because serif is a keyword (same goes for other sans-serif, etc.: https://mothereff.in/font-family#0lol%20serif

Hey @stoyan and thanks for this awesome project!

I found a small issue with prefixed pseudo-classes such as ::-webkit-input-placeholder.

They wont work if they are stacked after each other like this:

::-webkit-input-placeholder, :-moz-placeholder, ::-moz-placeholder, :-ms-input-placeholder {
  color: red;
}

So instead they need to be broken down like this:

::-webkit-input-placeholder {
  color: red;
}
:-moz-placeholder {
  color: red;
}
::-moz-placeholder {
  color: red;
}
:-ms-input-placeholder {
  color: red;
}

Unfortunately I’m not so node-savy yet so i couldn't make a pull-request. But here’s a jsfiddle with the issue.
This is also the issue with ::selection but that’s not a CSS standard yet.

It seems this tool demonstrates more or less the same parsing bug as oldIE (IE 6/7).

It replaces these 2 rules:

body {
    background: aliceblue;
}
body,{
    background: indianred;
    _background: teal;
}

with this one:

body {
    background: #f0f8ff;
    background: #cd5c5c;
    _background: teal;
}

Which makes all modern browsers see the IE7 declaration.
Note that if there is white space between , and { then the rules are properly minified (meaning the rule is not dropped but written as-is.)

This is a test page that shows this parsing bug.

Firstly, I'd like to commend you on creating this useful tool.

I did however notice some possible optimizations. For example, when I have multiple declarations of the same type, it should be possible to remove the previous declarations?

a { color: #ff0000; }
a { color: red; }
/* currently results in ... */
a{color:red;color:red}
/* ... but it should be ... */
a{color:red;}

Also, if multiple overriding declarations of the same type exists, only the last one need to stay?

a { color: red; color: blue; }
/* currently results in ... */
a{color:red;color:blue}
/* ... but it should be ... */
a{color:blue;}

input:

h1 {
    border: 1px solid red;
    background-color: red;
    background-position: 50% 100%;
}

h1 {
    border: 1px #f00 solid;
    background-color: #f00;
    background-position: center bottom;
}

h1 {
    border: solid 1px rgb(255, 0, 0);
}

output:

h1 {
    border: 1px solid red;
    background-color: red;
    background-position: 50% 100%;
}

foo[a = 'b'] > .bar {color: red}

foo[ a="b"]>.bar {color: blue}

https://www.npmjs.org/package/normalize-selector

Turn this:

a{ color:red; opacity:1; background:blue; }
b{ color:red; opacity:1; background:blue; height:10px; }

To this:

a,b{ color:red; opacity:1; background:blue; }
b{ height:10px; }

But only if it's "worth it" meaning, bytes were saved. in some situations the selector might be too long and not worth it:

a{ color:red; opacity:1; background:blue; }
.this_is_a_very > .long_selector ~ ul.drop_down_selector > li.list_item b{ color:red; opacity:1; background:blue; }

in the above example it's not worth repeating that long selector again, just to merge it's properties with a selector. it would result in a larger output.

This would eliminate the need to use extend methods in pre-processors manually and ease the workflow.

It would be really good if CSSShrink could figure out the `@media' rules in this snippet and merge them together. It seems to have an issue when they are in this order but if you put both the 768's together then it picks up on it (I am testing on http://cssshrink.com/ )

header {
  color: red;
}
@media only screen and (min-width: 768px) {
  header {
    color: green;
  }
}
@media only screen and (min-width: 1024px) {
  header {
    color: blue;
  }
}

section {
  color: green;
}
@media only screen and (min-width: 768px) {
  section {
    color: blue;
  }
}
@media only screen and (min-width: 1024px) {
  section {
    color: red;
  }
}

CSS transparent is considered as black transparent, eg rgba(0,0,0,0). So it shouldn't be used for each transparent color.

For example:

.e {
  background: linear-gradient(rgba(255,255,255,.1), rgba(255,255,255,0));
}

gives:

.e {
  background: linear-gradient(rgba(255,255,255,.1), transparent);
}

And that is not the same thing. ;)

I've tried to shrink some css code, but error.

div{
filter: progid:DXImageTransform.Microsoft.gradient( GradientType = 0,startColorstr = '#80000000',endColorstr = '#80000000')\9;
}

Should cssshrink remove duplicates?

It does when the duplicates are adjacent siblings:

@media print {b {color: #fff;}}
@media print {a {color: #000;}}
@media print {b {color: #fff;}}

Out:

@media print{b{color:#fff}a{color:#000}}

But not when they aren't:

@media print {b {color: #fff;}}
@media print {a {color: #000;}}
@media print {b {color: #fff;}}

Out:

@media print{b{color:#fff}a{color:#000}b{color:#fff}}

Resolve if works as expected. =)

Hello,

I wonder why only the adjacent selectors / Media Queries / keyframes are packed.

Would it be possible to add an option (a checkbox labelled "great power / great responsibility") which allows packing of non-adjacent stuff ?

Input

body {
  background-position: center center;
}

Output

body{background-position:center center}

this could be shortened to

body{background-position:50% 50%}

if file path has quote, cssshrink reports error. for example,
a{background:url('a'.png)}

I have wrong font-family value: font-family:13px, and cssshrink CLI gets:

/usr/local/lib/node_modules/cssshrink/lib/visitors/font-family-generic.js:28
      var value = node[2][i][1].toLowerCase();
                                ^
TypeError: Object number,13 has no method 'toLowerCase'
    at Object.module.exports.process (/usr/local/lib/node_modules/cssshrink/lib/visitors/font-family-generic.js:28:33)
    at tree (/usr/local/lib/node_modules/cssshrink/node_modules/gonzales-ast/lib/traverse.js:7:20)
    at tree (/usr/local/lib/node_modules/cssshrink/node_modules/gonzales-ast/lib/traverse.js:15:13)
    at tree (/usr/local/lib/node_modules/cssshrink/node_modules/gonzales-ast/lib/traverse.js:15:13)
    at tree (/usr/local/lib/node_modules/cssshrink/node_modules/gonzales-ast/lib/traverse.js:15:13)
    at /usr/local/lib/node_modules/cssshrink/node_modules/gonzales-ast/lib/traverse.js:24:11
    at Array.forEach (native)
    at Object.traverse (/usr/local/lib/node_modules/cssshrink/node_modules/gonzales-ast/lib/traverse.js:23:12)
    at traverseAST (/usr/local/lib/node_modules/cssshrink/lib/shrink.js:50:15)
    at Object.shrink (/usr/local/lib/node_modules/cssshrink/lib/shrink.js:66:9)

It took a while to find out that CSS was invalid. It would be great to log a bit more humanized error messages.

I'm encountering a bug where the ::selection and ::moz-selection selectors have to be defined as separate rules in order to work. So, the following code will run correctly in Chrome:

::selection {
  background: #f42;
  color: #fff;
}

::-moz-selection {
  background: #f42;
  color: #fff;
}

But this will not:

::-moz-selection,
::selection {
  background: #f42;
  color: #fff;
}

The same is true for ::placeholder and similar selectors. This is the only thing preventing me from using cssshrink in production.

EDIT
This is a duplicate of #14

Hello,

When some operators (such as , or and) are mixed in a media query, the parser doesn't guess when 2 MQ are the same.

For exemple :

@media print, screen {a {color: #f00}}
@media screen, print {a {color: #f00;}}

Should output :

@media print,screen{a{color:red}}

But the result is :

@media print,screen{a{color:red}}@media screen,print{a{color:red}}

When gonzales-ast throw some errors, the error info seems not right.

files.forEach(function(file, index) {
 fs.readFile(file, READ_OPTION, function(err, data) {
   if (err) {
    throw err;
   };

   if (data.trim().length > 0) {
    var compressed = cssshrink.shrink(data);
....

As code above, when there's some parsing error at index > 0, the line-number will be "right_line_number + sum_of_prev_file_line_numbers".

This issue appear at http://cssshrink.com/ too, you need to F5 to get the right line number.

Someone?

+1

::selection selector is out of work when using with gulp-autoprefixer.

Please provide scss support.

Hello guys,

Not a bad idea, thats kinda feature that I'm using in SASS but I think those code could have been shrinked more.

I've just tried, the web demo and it told me to check my code from the 3340# line where theres only this:

filter: alpha(opacity=(30));

The test cases failed during parse the "@import.css"

OH NOES! Trouble in @import.css

Debugging ....

It seems that was a windows '\r\n' pitfall:

expected.length == 172
after.length == 166

I'd love to see this as a gulp plugin!

Somewhat similar tasks such as Autoprefixer are able to create or update sourcemaps, wouldn't it be neat if this was able to do so as well?

In the given example, a{color: #ff0000;} got compiled, and became a{color:red}. This is not always the case. In some browsers, the color red is not #ff0000.