I think we could add selector type counts to the aggregates object. I'm thinking the more useful selector types would be:

• pseudo-elements
• pseudo-classes
• classes
• ids

feature request : get the selector associated with a rule size.
it could allow us to detect selectors that are too specialised.

very usefull lib by the way :) love it !

This should be a separate repo and package, but just keeping note here for now.

I've found the plugin will list the same color multiple times if the way it is declared is changed (short names, upper case, lower case, three digit hex, six digit hex and rgb).

Ex on http://cssstats.com/stats?url=http%3A%2F%2Fconsumerfinance.gov

• white and #fff
• black and #000
• #50a748 and #50A748
• #4d819a and #4D819A
• etc

Reducing these to single entries would highlight the more accurate divides between the total and unique declarations.

How are folks using cssstats in an automated, CI environment? I'd love to integrate this into my gulp build that gets run on Jenkins. I could get a consumable report I could point to which is always up to date, similar to our code coverage reports, ESLint statistics, etc.

But I'm not sure how to do it; every approach I can think of has some limitations.

Right now running the gulp task & generating JSON doesn't help visualize the way we'd want. The cssstats-webapp requires a node server to be running, while we'd prefer static HTML. And I don't think there are any Jenkins or other CI plugins that know how to consume the JSON report.

Are you aware of anyone who's doing this well?

Related: this issue makes it look like there's some interest in an HTML report.

Currently cssstats.com errors out on a few urls like thegrid.io. This appears to be occurring on the css-statistics level.

It’d be handy to export the number of animations in your CSS file (from @keyframes) — some stylesheets include a whole animation library and seeing the number of animations would help people remember the weight of them.

Consider adding in functions from the app's controller.

This will output a stats summary to stdout. (Default is false, of course)

@jxnblk when you get a chance could you please publish 1.2.0 or add me to the npm package?

Thank you!

I feel like it'd be useful to include an averageSpecificity metric to the returned object, as it could useful to illustrate the overall health of a project's CSS and its specificity. I also think it'd be a very worthwhile data point on cssstats.com. Thoughts?

Example Usecase: scss test.scss | cssstats