-
Notifications
You must be signed in to change notification settings - Fork 242
Modular CSS (by @growdigital)
I'm dumping this here because I keep on having to search the slack history for it. - Simon
Modular CSS abstracts CSS functionality into re-usable classes. It also plays nicely with folder structure and style guide.
Only use classes, not IDs, when defining styles.
Keep the specificity as flat as possible, by which I mean that you should not specify the element type in addition to the class unless this is necessary. For example, if you style a button with:
.Button { border-radius: 3px; }
.Button--primary { background-color: blue; }
You can then use these styles on a variety of button-like elements without regard to their HTML element type, for example:
<input class="Button" type="submit">
<button class="Button">PushMe</button>
<a class="Button" href="somewhereovertherainbow.html">I Am A Button</a>
For a label plus the accompanying input field, you’d have a file called TextField.scss
. This would style all text fields, along with their labels.
- A class name for a component looks like .componentName, for example:
.TextField
- A class name for a component modifier looks like .componentName--modifier, for example:
.TextField--special
- A class name for a component descendant looks like .componentName-descendentName, for example:
.TextField-label
:
.TextField { background-color: yellow; }
.TextField--special { outline: 10px dotted red; }
.TextField-label { display: inline-block; margin-right: 3px; }
.TextField-input { display: inline-block; }
An example of HTML containing such components would look something like this:
<div class="TextField TextField--special">
<label class="TextField-label">Name</label>
<input class="TextField-input" type="text">
</div>
By using Sass globbing you can organize the individual CSS modules in some sensible way. Currently, I divide up modules into Components
(big blocks that are made up of other modules), Graphics
(the “look and feel” elements), Objects
(the layout and positioning parts) and UI
(form elements, buttons, navigation, widgety things).
── modules
├── Components
│ └── Header
│ └── Header.scss
├── Graphics
│ └── Branding
│ └── Branding.scss
│ └── Icon
│ ├── Icon.scss
│ └── menu.svg
├── Objects
│ └── Media
│ └── Media.scss
├── UI
│ └── forms
│ └── TextField
│ └── TextField.scss
└── app.scss
The beauty of this method is that it makes it easy for you to find stuff. Do you want to style a new button style? Button.scss
in your favourite text editor.
This also means that is a relative breeze to generate a style guide app from the directory structure itself. It also means that if the directory structure doesn’t fit, you can move and rename directories with relative impunity.
About OpenFarm
Development
- How to Contribute to OpenFarm
- Code of Conduct
- How to Install & Run OpenFarm on an OS X system and on an Ubuntu System
- Troubleshooting Common Issues
- How to Set Up an Amazon S3 Bucket for Use with OpenFarm
- Modular CSS
- The OpenFarm API and API Documentation
- How to Use Docker and Fig
Deployment
Reference