Standards for writing CSS

[mcmire]

I want a place where we can have discussions about the kinds of standards we want to follow when working on projects and have a place to codify those standards. At my last job we had a guides repo that we used for this very purpose, and I think that would be a good idea to have here.

So, since we have more frontend people than backend people, I thought I would start by talking about how we write CSS.

• What languages do we want to use? (We already use Sass so this might be an easy answer.)
• What frameworks do we want to use? (Some people have mentioned Bourbon and Neat already.)
• Perhaps more importantly, is there an architecture (methodology, organizational approach) that you've read about or used in past projects that you think would be helpful to use in the future?
• Are there any best practices or guidelines that you've followed in past projects that you think would be helpful to follow in the future?

[phillipkova]

I agree that we should have standard practice for the how we write code.

• I think scss or sass are obvious ones. I think it would cool if we started using sass, instead of scss.
• The Bourbon sweet sounds like a good idea to me! I have been using bootstrap since i've started coding and it gets pretty messy as the project gets large. Bootstrap is good for quick little projects where speed is the name of the game.
• I've been following the ITCSS architecture flow for a while now. I'm down to give BEM a try if everyone is for it.

[simplyjerett]

I generally have gotten use to how middlelman sets things up. Where you have your Stylesheets as
Base
Bourbon
Common
Layouts
Modules
Pages
Etc

But i think middleman is mainly for front facing work and not so much for backend - full blown apps.

[mcmire]

@phillipkova Are there things you like about ITCSS? Are there things you dislike? Why does BEM appeal to you?

Cool. @simplyjerett What's a module in this case?

@coreymade Do you have thoughts on any of this?

[phillipkova]

ITCSS has a similar to layout what Jerett pointed out, So not to much would change if we did switch to ITCSS or stuck the structure Jerett showed. One thing I do like about BEM is that you know exactly what is going on with the styles and were are they are coming from simply by the name of the class.

Ex:

• .form__input: This is the style of the input
• .form__input--large: Large version of the input
• .form__input--error: Error input
• .form__input--icon: This input has an icon inside of it

I think the benefit of using BEM is that both the backend and front-end developers know exactly whats happening simply by looking at the class name. Also it is incredibly easy to organize BEM architecture. The downside is that there is a bit of a learning curve, which honestly I don't think its hard to learn BEM, its fairly straight forward

[simplyjerett]

Mine is more geared towards front facing I think but basically -

Modules would be anything you added into the the site layouts - so css for js etc...
Layouts/Views would be css specifically for those pages
General/Common would house anything that is used across the board - so buttons etc...
Layout is the grid settings etc.

[mcmire]

@phillipkova Cool! That makes a whole lot of sense.

So I made a new Trello board for "experiments" -- new things we're trying out on projects. Do you want to add a card for BEM and try it out on your next project? Obviously this goes hand in hand with using Bourbon/Neat.

[simplyjerett]

i will say that what we did with stylesheets on pva is a mess :( not a fan of searching through 3 or 4 different stylesheets for items associated with a page. :( makes the process so much longer ....

[mcmire]

Sure, I totally understand. I think proves why it's important for us to come up with a basic philosophy we can all agree on. It's super easy to cast blame in these kinds of situations.

I think if we can start with agreeing on where to put CSS files, that would go a long way in easing some frustration.

It seems like to me that we can all agree that any given project will have at least these things:

• Settings (base/_variables.scss)
  • Fonts
  • Colors
  • Breakpoints
  • Grid settings
  • Vertical rhythm (base vertical spacing)
• Global styles (base/)
  • Typography: body/header text font family, font size, line height
  • Styles for elements (body, headers, paragraphs, forms, tables, lists, etc.)
  • Global box model settings (box-sizing: border-box)
  • Helper mixins (transitions, animations, .hidden, .invisible, whatever you want)
  • Keyframes?

In fact, if you use Bitters, then you'll get this structure already (and you can add to it if you want).

Now, I realize past this point there are a zillion ways to proceed, because there's this spectrum of how often a portion of CSS is used, from "stuff I use only once" to "stuff I use multiple places, but only on one page" to "stuff I use on multiple pages". I get the sense that you, @simplyjerett, and @coreymade both code similarly, where you start with placing CSS in specific locations and then move it up the ladder to more global places as the need arises. Would that be accurate?

If that's true, then it seems like you could definitely have two more folders:

• Layout-specific styles (layouts/)
  • Each file here corresponds to the name of a layout (e.g. views/layouts/user.html.haml goes with stylesheets/layouts/_user.scss)
• Page-specific styles (pages/)
  • Each file corresponds to the name of a page (e.g. views/pages/dashboard.html.haml goes with stylesheets/pages/_dashboard.scss)

So now the question is, if you have some CSS and you want to re-use that CSS across multiple pages, where would you put it? Or to put it another way, where would you expect to find that CSS? (Examples would be: form styles, button styles, modal styles, notification message styles, etc.) (@phillipkova the question is open to you too)

[mcmire]

Someone posted this to lobste.rs today and I thought it had some really good ideas on how to write maintainable CSS: http://maintainablecss.com/. I thought the chapter on Reuse was especially interesting -- basically, he's saying, prefer duplicating CSS instead of building composable pieces from the start. I encourage you guys to skim through this and let me know what you think. I think I am going to borrow these ideas to form a set of guidelines for CSS (but of course I'll make a PR first).