Propose styles folder structure and file naming conventions

[jschroed91]

No description provided.

[beckkramer]

Here's what I'm trying to accomplish here:
1.) Make it very clear what-goes-where as far as partials are concerned
2.) Create a folder structure that encourages the mindful creation of patterns and their contexts
3.) Create a spot for third party SCSS files (/vendor) as needed (though ideally we should pull them in via npm or yarn if possible)

Current suggestions:

Option 1:

• /patterns
  • /atoms
  • /molecules
  • /organisms
  • /layouts
  • /pages*
• /utilities
  • /variables
  • /mixins
• /vendor
• screen.scss
• print.scss
• dev.scss*

Option 2:

• /patterns
  • /base
  • /containers
  • /layouts
  • /pages*
• /utilities
  • /variables
  • /mixins
• /vendor
• screen.scss
• print.scss
• dev.scss*

Items marked with a * are optional/may not always be needed. /pages is only needed if you have one-off CSS, which we should try to avoid whenever possible.

Option 1 would require a lot of diligence to identify what kind of pattern is what, and where it should go. While academically I think it's a good idea, it could just lead to things being hard to find.

Option 2 is closest to what I use now. It assumes our CSS is one of four things:

• a base html element like an anchor or form input
• a container organizing/grouping base elements
• a layout system to organize/group our containers
• a page-specific override to change a rule we made earlier

Both options leverage the idea that patterns should be focused and go from a general-to-specific order inside the patterns folder, and that layout/positioning concerns be removed altogether from those elements' files. That is, a form should never care about where/how it's being positioned. We should have other CSS in the layout file(s) that takes care of that.

[beckkramer]

Regarding naming conventions, I'm going to go to bat for BEM. I think it dovetails well with atomic design, it makes it very clear what CSS is responsible for what, and I think it takes the guesswork out of what a class name should be. All of these things are invaluable for team-based CSS creation.

• Why BEM?
• Getting your head around BEM syntax

[jschroed91]

@beckkramer I see your point about Option 1 requiring a lot of diligence to identify where patterns should go, and then also causing some confusion when trying to find a pattern... I was originally on board for Option 1 but when considering that, Option 2 might be the way to go.