I've been looking into this kind of tool for a while, but none of them are quite right for my purpose. I don't want a tool that spits out just-the-CSS-that-is-used, I want a tool that shows me blocks of CSS that it thinks are NOT used - ideally after I've loaded a number of different pages in a browser.
My use-case is for analyzing a large, existing website that has many years of accumulating CSS, and getting a feel for which blocks of code can be safely eliminated.
I'm pretty sure what I'm after needs a full-blown DOM to work effectively - either with something like PhantomJS or even running as a Chrome Extension. So far I haven't seen anything that fits the bill.
I honestly think this needs to be a part of Chrome Dev Tools's profiler. Already it's able to record sessions that persist across page loads, and tracks what CSS selectors are applied and which properties are overridden. I don't think it's much of a stretch to add a feature like this.
I have used a Firefox extension called Dust-Me Selectors[1] which does this. It breaks your css into used and unused selectors, it can spider the site for you, or you can leave it running as you browse the site and it will work automatically. Definitely slows things down though while you're using it.
I built something like this at my old company. Scrape every tag on the current page, subtract this array of used tags against all the tags in the CSS. Didn't take too long to build.
The problem with the PurifyCSS approach, like so many before it, is that you cannot really do this accurately from the server. It has to be done in the browser.
Helium is a dev tool. It takes a list of sample urls from the developer because its presumed the engineer will be able to make the best choice as to pages that represent all the aspects of their site.
It will work in any web page regardless of framework, because ultimately its all just web pages.
Helium will find the actual style sheets loaded into each page, then at the end of the scan give you an accurate and realistic report of the css selectors that were not found anywhere in your site.
There are some minor limitations, such as the inability to test for user-interactions with pseudo selectors like :active, :focus, :hover, etc.
As a designer that would love this tool for the speed and cleanliness factor it would give, i have a few other Qs:
1. Does it spit out a css file or multiple css file I can use immediately? Can i actually amend a local document with it, or do I have to copy paste?
2. Does it give any critique on poor selector methods? Definitely have a few foolish ways of doing things that could be improved with a little bit of "hey...stop that" feedback, in my work
3. ??? PROFIIT
4. Can it give me a few stats on the css to benchmark it? You're already showing me the unused ccs selectors, can you present other data that you could present to your boss and say hey...look at this, this is why it's worth doing this stuff
5. Known browser issues highlighted. "Hey! In IE8...that div ACTUALLY does this". Also, heres how to fix it. Insta–contextual documentation. As I say that I realise I'm asking for Clippy back in a way so I shall bow out. Responsive design? worth thinking about...anyway!
Really interesting project! I'm going it use it this weekend and see how it goes :)
For many reasons, namely that we've already solved most of these "problems" years ago with simple concepts like OOCSS, SMACSS, and BEM. I suggest taking a look at this rebuttal.
http://keithjgrant.com/posts/against-css-in-js.html
The reasons people are running into problems with global css scope is because they don't understand the basics of how to write effective and maintainable CSS. Seems like many front end devs nowadays grew up with css hand-holding libraries like bootstrap, and can't seem to wrap their heads around completely necessary things like taking account for CSS specificity and how the cascade works and how to use it to your advantage.
Inline styles are great, but they don't support basic features such as pseudo classes/elements, so even implementing simple components like buttons was cumbersome.
With latest version of webpack's css loader you get css scoping (you no longer need to add lengthy prefixes to all selectors) and you can also use additional loaders for post-processing your styles (we use a lot of postcss plugins such as autoprefixer).
Nice. But from the description, it apparently doesn't work if you construct class names by string manipulation (like "item_" + (selected ? "selected" : "")). Maybe you shouldn't do that anyway, though.
Linking some string hanging off some runtime object to its CSS class usage quickly runs into halting problem issues.
There are certainly some arguments to keeping class names as opaque magic strings, but given certain levels of dynamic complexity and the lack of tools like CSS class inheritance, naming policy is sometimes far cleaner and more manageable.
Also, there is a minor concern about false positives. If you have a class called "name" or something generic like that, the odds of that string appearing in non-CSS usage your source code is fairly high.
Yes! that is a great library. Unfortunately, that library does not automatically detect the classes used in JS. So we thought we could give it a try to make one that would detect classes used in JS by default
I _think_ it shouldn't be too much code.
For my rails project, I wrote a simple shell script[1] to get all unused css classes and remove it my hand in final step, to make sure i will not remove css classes that actually used (e.g pre-define and use in future, overriding of third party css class)
The script basically does:
1. Use REGEX match all css classes, `cat` into one place
2. Read the class line by line and search in html,js files to see if this css is used (even support #addClass from js)
2.1 it also supports several class adding styles e.g. class="abc", class: "abc", :class=> 'abc' or even "xxx" class in this: class="abc xxx ijk"
2.2 People even do this in js: $modal.append($('<div class="modal-close-icon"></div>')); and the REGEX can also detect this lol.
This setup is ideal IMO. Keep your existing files, like bootstrap, intact in case you ever DO use them but integrate this into your deploy process to do compression and minification prior to getting out to your server.
How do you do this for JavaScript?
In Java I used a mixture of static analysis[1] and code coverage[2] with great success. For JavaScript there seem to be many (dead) coverage tools but nothing comparable to UCDetector.
What is the actual performance advantage gained in contrast to a simple minifier?
Given today's CPU speeds, I think the only thing you can save with this tool is bandwidth on mobile and even with this, the effort is not always worth the resulting speed gains as mobile networks get faster and faster.
[+] [-] simonw|10 years ago|reply
My use-case is for analyzing a large, existing website that has many years of accumulating CSS, and getting a feel for which blocks of code can be safely eliminated.
I'm pretty sure what I'm after needs a full-blown DOM to work effectively - either with something like PhantomJS or even running as a Chrome Extension. So far I haven't seen anything that fits the bill.
[+] [-] Zikes|10 years ago|reply
[+] [-] thousande|10 years ago|reply
https://developer.mozilla.org/en-US/docs/Tools/CSS_Coverage
[+] [-] geuis|10 years ago|reply
[+] [-] bjterry|10 years ago|reply
1: https://addons.mozilla.org/en-US/firefox/addon/dust-me-selec...
[+] [-] miniatureape|10 years ago|reply
It's fairly easy to roll your own version of this and do analysis.
[+] [-] Existenceblinks|10 years ago|reply
[+] [-] Sir_Cmpwn|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] tlrobinson|10 years ago|reply
[+] [-] EC1|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] geuis|10 years ago|reply
The problem with the PurifyCSS approach, like so many before it, is that you cannot really do this accurately from the server. It has to be done in the browser.
Helium is a dev tool. It takes a list of sample urls from the developer because its presumed the engineer will be able to make the best choice as to pages that represent all the aspects of their site.
It will work in any web page regardless of framework, because ultimately its all just web pages.
Helium will find the actual style sheets loaded into each page, then at the end of the scan give you an accurate and realistic report of the css selectors that were not found anywhere in your site.
There are some minor limitations, such as the inability to test for user-interactions with pseudo selectors like :active, :focus, :hover, etc.
[+] [-] jamesdelaneyie|10 years ago|reply
1. Does it spit out a css file or multiple css file I can use immediately? Can i actually amend a local document with it, or do I have to copy paste?
2. Does it give any critique on poor selector methods? Definitely have a few foolish ways of doing things that could be improved with a little bit of "hey...stop that" feedback, in my work
3. ??? PROFIIT
4. Can it give me a few stats on the css to benchmark it? You're already showing me the unused ccs selectors, can you present other data that you could present to your boss and say hey...look at this, this is why it's worth doing this stuff
5. Known browser issues highlighted. "Hey! In IE8...that div ACTUALLY does this". Also, heres how to fix it. Insta–contextual documentation. As I say that I realise I'm asking for Clippy back in a way so I shall bow out. Responsive design? worth thinking about...anyway!
Really interesting project! I'm going it use it this weekend and see how it goes :)
[+] [-] namuol|10 years ago|reply
Rather than "blob" all your CSS together, and then "de-blob" it, why not build your CSS dynamically based on what components your app is using?
[1] I strongly encourage you to watch this talk: https://vimeo.com/116209150
[+] [-] emitstop|10 years ago|reply
The reasons people are running into problems with global css scope is because they don't understand the basics of how to write effective and maintainable CSS. Seems like many front end devs nowadays grew up with css hand-holding libraries like bootstrap, and can't seem to wrap their heads around completely necessary things like taking account for CSS specificity and how the cascade works and how to use it to your advantage.
[+] [-] moretti|10 years ago|reply
https://github.com/css-modules/css-modules
https://medium.com/seek-ui-engineering/the-end-of-global-css...
Inline styles are great, but they don't support basic features such as pseudo classes/elements, so even implementing simple components like buttons was cumbersome.
With latest version of webpack's css loader you get css scoping (you no longer need to add lengthy prefixes to all selectors) and you can also use additional loaders for post-processing your styles (we use a lot of postcss plugins such as autoprefixer).
Have a look at this example:
https://github.com/css-modules/webpack-demo
And here's a great comparison of the main CSS in JS techniques:
https://github.com/MicheleBertoli/css-in-js
[+] [-] bpicolo|10 years ago|reply
Edit: I see we're referring to inline styles instead of requirecss. In that case, it's because code reusability becomes a pita and you bloat your JS.
[+] [-] frandroid|10 years ago|reply
[+] [-] emitstop|10 years ago|reply
[+] [-] inostia|10 years ago|reply
[+] [-] gpvos|10 years ago|reply
[+] [-] white-flame|10 years ago|reply
There are certainly some arguments to keeping class names as opaque magic strings, but given certain levels of dynamic complexity and the lack of tools like CSS class inheritance, naming policy is sometimes far cleaner and more manageable.
Also, there is a minor concern about false positives. If you have a class called "name" or something generic like that, the odds of that string appearing in non-CSS usage your source code is fairly high.
[+] [-] k8t|10 years ago|reply
[+] [-] Brajeshwar|10 years ago|reply
[+] [-] k8t|10 years ago|reply
[+] [-] Existenceblinks|10 years ago|reply
The script basically does:
1. Use REGEX match all css classes, `cat` into one place
2. Read the class line by line and search in html,js files to see if this css is used (even support #addClass from js)
2.1 it also supports several class adding styles e.g. class="abc", class: "abc", :class=> 'abc' or even "xxx" class in this: class="abc xxx ijk"
2.2 People even do this in js: $modal.append($('<div class="modal-close-icon"></div>')); and the REGEX can also detect this lol.
[1] https://gist.github.com/50kudos/3028fac585eda85aea9a
You can adapt my REGEX, and custom your directory where those css files are in.
Simply copy the code and save into your filename.sh, and can run safely because my script don't write any file of your project.
[+] [-] peterbe|10 years ago|reply
Go to http://www.peterbe.com/plog/mincss and click to view source. 120Kb of bootstrap excess baby!
[+] [-] brightball|10 years ago|reply
Workflow wise, this is a huge win.
[+] [-] joeyspn|10 years ago|reply
(just in case you were also wondering) =)
[+] [-] cblock811|10 years ago|reply
[+] [-] mkagenius|10 years ago|reply
[+] [-] weinzierl|10 years ago|reply
[1] http://www.ucdetector.org/
[2] http://www.eclemma.org/jacoco/trunk/doc/
[+] [-] mschuster91|10 years ago|reply
Given today's CPU speeds, I think the only thing you can save with this tool is bandwidth on mobile and even with this, the effort is not always worth the resulting speed gains as mobile networks get faster and faster.
[+] [-] brokentone|10 years ago|reply
[+] [-] JuanSoto|10 years ago|reply
Awesome! I worked with a tool like this that did not have dynamically loaded classes in mind.
For people not sure on how to use this, I personally use tools like these when working with a CSS framework.
[+] [-] prayerslayer|10 years ago|reply
The auto-remove part you would have to code yourself though.
[+] [-] kanakiyajay|10 years ago|reply
[+] [-] Cengkaruk|10 years ago|reply
[0] https://github.com/giakki/uncss
[+] [-] Spidy88|10 years ago|reply
[+] [-] welder|10 years ago|reply