Neat and all, but why is this written in JS? CSS selector support is great in html parsers (nokogiri, for instance.) Seems like a hassle to add the script tag, onload, etc. just for a run-once-and-only-in-dev kind of script.
I upvoted because this is a good question that other folks will have, and I wanted to provide my motivations.
Finding the unused css selectors among several stylesheets among dozens of pages is tough. Before I wrote Helium, I tried many other attempts. This included:
Google Pagespeed exports: There's a cool feature of this Firefox extension that lets you export a json-encoded file showing all kinds of stats about the page. This includes a section of unused css selectors. The problem is that there is no way(currently) to pass it a list of urls to load, check, and produce a final report. At one point, I exported over 40 individual reports and struggled for several days to write a Python script to parse the results out. While this was a perfectly valid way to solve the problem, one of the big issues I found was the amount of time it took to generate the reports. It was a vary manual process.
Cross-browser support: There were only 2 projects that I found that came close to the kind of data exports that I needed, Pagespeed and DustMe Selectors. They were both Firefox-only tools, and don't help when trying to analyze any other browsers. It will only take a minimal amount of work and testing to get it running in IE8, so that's next. It will eventually also work in older IE versions, but that is going to take more work.
Existing solutions just don't work(at least for me): In particular, I'm talking about DustMe Selectors. I monkeyed with this tool for 2 full days and could never get it to work correctly. The absolutely vital component I needed was the ability to get reports on many different pages. Once I figured out how to get it to read a sitemap XML formatted file of my links, I could never get it to finish a full report. I let it run all night and came back the next day and it was just hung up. I spent a 2nd day and each test would just hang, no matter what I did. I really wish it had worked as advertised, because it would have saved me a lot of time.
Client-side tool: I thought about this problem for a long time. Yes, there are server-side tools like the ones you mentioned. However, to be truly accurate a tool like this needs to be able to analyze pages as they are actually rendered in the browser.
So these are the main reasons that I built Helium.
Its incredibly important to web developers to be able to test IE, too. Helium needs a lot of extra work to support the older Internet Explorer browsers to patch around the missing features required. It will get done.
I cannot see why you should develop this for IE. This tool is no going to be used by end users. Developers are going to have Chrome/Safari or Firefox installed in their machines. Are there so many IE CSS hacks used in websites?
Because IE has "special needs". Very often different stylesheets or even different markup is served for IE. This could be circumvented by faking IE with the user-agent string but ideally it would just support IE out of the box.
What would be really awesome if this tool could run in the background somehow and log selector usage. The reason for that is that on dynamic pages, the original HTML served doesn't really reflect all the selectors that are actually used on the page.
What about those of us that use add CSS classes dynamically, based off user events?
I could definitely use a tool like this, my CSS sheets get long very fast.
13 comments
[ 4.3 ms ] story [ 45.1 ms ] threadI already do that with Firebug Lite, to make IE suck less.
Finding the unused css selectors among several stylesheets among dozens of pages is tough. Before I wrote Helium, I tried many other attempts. This included:
Google Pagespeed exports: There's a cool feature of this Firefox extension that lets you export a json-encoded file showing all kinds of stats about the page. This includes a section of unused css selectors. The problem is that there is no way(currently) to pass it a list of urls to load, check, and produce a final report. At one point, I exported over 40 individual reports and struggled for several days to write a Python script to parse the results out. While this was a perfectly valid way to solve the problem, one of the big issues I found was the amount of time it took to generate the reports. It was a vary manual process.
Cross-browser support: There were only 2 projects that I found that came close to the kind of data exports that I needed, Pagespeed and DustMe Selectors. They were both Firefox-only tools, and don't help when trying to analyze any other browsers. It will only take a minimal amount of work and testing to get it running in IE8, so that's next. It will eventually also work in older IE versions, but that is going to take more work.
Existing solutions just don't work(at least for me): In particular, I'm talking about DustMe Selectors. I monkeyed with this tool for 2 full days and could never get it to work correctly. The absolutely vital component I needed was the ability to get reports on many different pages. Once I figured out how to get it to read a sitemap XML formatted file of my links, I could never get it to finish a full report. I let it run all night and came back the next day and it was just hung up. I spent a 2nd day and each test would just hang, no matter what I did. I really wish it had worked as advertised, because it would have saved me a lot of time.
Client-side tool: I thought about this problem for a long time. Yes, there are server-side tools like the ones you mentioned. However, to be truly accurate a tool like this needs to be able to analyze pages as they are actually rendered in the browser.
So these are the main reasons that I built Helium.
I cannot see why you should develop this for IE. This tool is no going to be used by end users. Developers are going to have Chrome/Safari or Firefox installed in their machines. Are there so many IE CSS hacks used in websites?
I kept expecting someone to make this extension as part of Firebug.
http://rdoc.info/projects/aanand/deadweight