Hacker News new | comments | show | ask | jobs | submit login

I've been using this technique with great success. http://viget.com/inspire/extending-paul-irishs-comprehensive...

You still have to load in all your js but at least you can execute exactly what you want per controller and action and have it documented all in one place.

That's the so-called Garber-Irish technique that I briefly mention in the article. I want to investigate it further. I'm not sure whether to use classes or ids in the body tag or try the data-* attributes he suggests.

Also I'm a bit reluctant to use page-specific CSS selectors. It seems to be accepted practice (Modernizr and other libraries) but still seems like a hack. After all, there is never more than one body tag so it seems inconsistent with the HTML spec to apply a class or id to it.

The data attributes work great. They can fool you when you're not looking out for specific sitatuons. Like a typical error page will be show create or update action and not edit or new.

The killer feature for me is being able to organize my coffeescript code into various classes and execute it all on one page. Makes it much easier to get other developers up to speed on the javascript code.

I'm still looking for a way not to load specific javascript files from the asset pipeline and not litter my views with content_for :head. It's better all in one place.

CSS selectors should describe visual design, not content. Selector chains like .landing-page #buy-button are a CSS code smell. Unfortunately this seems to be more common than not, in my experience.

What? IDs and classes are part of the HTML, not the CSS, and as such, they should specify semantics, not presentation. If a class or ID specifies presentation, like .red-button, you have to change the HTML when the design changes, not just the CSS.

Sorry, just generally ranting, not in your direction. :)

My personal (strong) preference is to use semantic IDs as JS hooks (or just for markup readability), and keep all class names content-agnostic. Obviously there will be cases where you need to use (CSS) classes in your JS as well, so a good practice is to prefix them with js- and not base any style definitions on them. Separation of concerns and all that. You should be able to refactor your CSS, markup, and JS independently and not have anything break.

Additionally, you should be able to copy paste a chunk of markup and have it look identical no matter where you put it, which definitely won't be the case if you are using long, content-referencing selector chains. Keeping your CSS flat, low level, and generic increases reusability and prevents CSS bloat, which can quickly get out of hand even in a medium sized app. Of course, all this is probably overkill if you are making small, static sites.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact