The purpose of modularizing our CSS is to help it become much more flexible and scalable, but also to help make it easier to read and easier to maintain.
Focusing on creating healthy front-end modules instead of complete pages can help break complex page layouts into reusable solutions.
— Dave Rupert
Dave Rupert says it best when he says that we should focus on creating front-end modules as reusable solutions for complex pages.
This isn’t the “homepage” of Apple.
It's a complex page fit together with front-end modules. It's a collection of reusable style patterns.
independent portable Modular CSS is all about learning to think about your CSS in terms of individual pieces. Each Module should be designed to exist as a standalone component. In doing so, the page will be more flexible. If done right, Modules can easily be moved to different parts of the layout without breaking. Breaking your CSS down into smaller chunks will ultimately result in more maintainable code.
Navigation, Tabs, Tables, Accordions, Lists, Dropdowns
Pagination, Buttons, Labels, Inputs, Breadcrumbs, etc. Examples of reusable pieces are [read slide] If this seems familiar, it should…
Dave Rupert refers to these reusable modules as tiny bootstraps.
Module, Pattern, Component, etc.
BTW, I will use the words module, pattern, and component interchangeably; they all refer to a set of self-contained styles.
MVCSS, BEM, OOCSS, Suit, intuit.css
There are lots of different methodologies that can help you accomplish this. But the one I use and love is [next]
The basic concept of SMACSS is to categorize styles into 5 categories:
The basic concept of SMACSS is to categorize styles into 5 categories: Base, layout, modules, states & themes. Each category comes with a set of more or less loosely defined naming conventions and usage rules. [next]
CSS resets, default styles (ex. html, body, h1, ul, etc) Base rules are the defaults. They are almost exclusively single ele- ment selectors but it could include attribute selectors, pseudo-class selectors, child selectors or sibling selectors. Essentially, a base style says that wherever this element is on the page, it should look like this.
grid, major components ex. header, sidebar, nav Layout rules divide the page into sections. Layouts hold one or more modules together.Wrappers, rows, columns and any grid-based styles can go here. Also major semantic areas as well, such as header, content and footer. - When defining a layout rule make sure you don’t mix presentation rules such as fonts, colors, backgrounds or borders. - Layout rules should only contain box-model properties like margins, padding, positioning, width, height, etc.,
Let’s look go back to Apple. A quick analysis of the home page, you can see some defined areas.
content patterns (ex. search-box, navigation, content-box) Modules are the reusable, modular parts of our design. They are the callouts, the sidebar sections, the product lists and so on.
The amount of abstraction you use is up to you, but the point is to break you layout down in to as many reusable components as possible.
module in various states (ex. hover, disabled, collapsed vs expanded) State rules are ways to describe how our modules or layouts will look when in a particular state. Is it hidden or expanded? Is it active or inactive? How does it look on different devices? I like to add print styles into this category as well.
module in various contexts Theme Rules describe the appearance of modules, i.e., colors, images, etc, by way of visual themes. I’ve never needed to use them, but some context examples might be: user-selected skin for an application, client branding for a hosted site, holiday or seasonal themes.
In Sass you can easily chop your stylesheet into partials by using the @import rule. This allows us to easily organize and maintain our files similar like this: [next]
In Sass you can easily chop your stylesheet into partials by using the @import rule. This allows us to easily organize and maintain our files similar like this: [read slide] [next]
Variables, mixins, functions, etc. Basically anything that doesn’t output CSS by itself.
Third-party libraries such as Susy, Font Awesome, Pesticide, and other plugins.
For JS plugins that require CSS files, just change the extension to .scss and import it into your stylesheet.
CSS resets, Normalize, element styles
Grid styles, major layout components (e.g. header, footer, sidebar, etc)
Individual modules, such as buttons, navigation, menus, etc.
Describe states of being, ex: active, collapsed or hidden
Web fonts imports & declarations
If you’re hosting web fonts on your own server, this is where you would define those fonts. [next]
Because I consider print to be a different state, I placed it under the state folder. However, I don’t want to include print styles until the towards the end of my stylesheet. If you like, you can even omit this partial and create a separate print css file. [pause]
We all know that, no matter how hard we may try, sometimes we do need to use quick fixes, hacks and questionable techniques in our code. It happens, whether we like to admit it or not. While this isn’t ideal, we have to do it from time to time; all of us. [next]
And when we do, we feel shame. The real problem, though, is that we rarely go back and tidy these things up. They slip through the cracks, get ignored, go unnoticed, and stay for good. This we do not have to do. What is needed is a way of allowing these hacks when necessary, but making sure that they don’t go unnoticed and unresolved.
_shame. scss Use a separate file to hide all our shameful hacks.
Because Harry Roberts is the man.
because hacks happen
Create a partial and import it at the end of your main Sass file. Do not leave it there. Go back and refactor when you have the time.
Small & Readable
I know it’s a lot of files, but the idea is to keep everything small and readable. [next]