Writing and maintaining CSS for a small site is very different from a large site or multiple sites. How exactly we developers can and should write CSS for scale varies according to the specifics of what we’re working on.\n<\/p>\n
\nFrom my experience, what happens all too often is CSS files become an unstructured mess. Changes require new code, which gets tacked on at the end. Or somewhere in the middle. Or maybe somewhere else.\n<\/p>\n
\nIn this article, I’ll go through various methods I’ve used trying not to write too much CSS, while also generally keeping my sanity. Ideally, the methods presented here can be used to scale up your development practices in such a way that, even if you don’t need a certain method right now, you’ll have an idea what you might do to avoid losing control.<\/p>\n
The “add new styles at the end” method might be widely used but it’s not going to help you past a certain point.\n<\/p>\n
\nWhen you’ve built a site and deployed it, you’re free and can now bask in its glory. That basking will end when your team expands or the scope of your work changes.<\/p>\n
Sales: “We promised a client they can have their own colours.”\n<\/p>\n
\nYou: \ud83d\ude31\n<\/p>\n
\nSales: “Here are the PowerPoint slides.”\n<\/p>\n
\nYou: \ud83d\ude31\ud83d\ude31\n<\/p>\n
\nSales: “We’ve shown you which colours we want to change.”\n<\/p>\n
\nYou: \ud83d\ude31\ud83d\ude31\ud83d\ude31\n<\/p>\n
\nSales: “How hard can it be to set some colours?”\n<\/p>\n
\n(Note: Everyone’s job looks easy if you don’t understand it.)\n<\/p>\n
\nSales: “We showed all the other clients the customisations.”\n<\/p>\n
\nYou: \ud83d\ude31\n<\/p>\n
\nSales: “They love it”\n<\/p>\n
\nYou: \ud83d\ude31\ud83d\ude31\n<\/p>\n
\nSales: “There are ten of them”\n<\/p>\n
\nYou: \ud83d\ude31\ud83d\ude31\ud83d\ude31\n<\/p>\n
\nSales: “I think I should call an ambulance.”\n<\/p>\n
\nSales: “You seem to have passed out. Does that happen often? Should I send for help?”\n<\/p>\n
\n(Note: Playing dead might work with bears but it’s less effective with sales staff.)<\/p>\n
A 2015 poll on CSS Tricks<\/a> showed 75 percent of CSS is edited by one or two people. As with any programming language, structure and consistency become more crucial the more people are involved. Even if you are only one person who edits a project, remembering what you wrote six months ago can be as much of a challenge as working with someone else.<\/p>\n Maintaining your styles across multiple architectures is as much a branding problem as a technical problem even if the impact is technical. How exactly do you keep your look and feel consistent when one team is using React and another Jekyll?<\/p>\n A good thing about structuring your CSS is knowing that you’re not alone and many others have gone ahead of you. A bad thing is the realisation that there are many varied solutions out there, which makes it hard to know what’s right for you.<\/p>\n Plain old native CSS has structure by way of the various selectors it offers. Irrespective of what solution you choose, having a good understanding of CSS selectors will help make your life as a CSS developer significantly easier.\n<\/p>\n \nIf they’re used well, you might not need to go any further.\n<\/p>\n \nIn the modern CSS world, ID selectors<\/em> are generally considered to be too specific and, as such, are best avoided. The key problem with ID selectors is they’re really difficult to override which makes scaling all the more difficult.\n<\/p>\n \nClass selectors<\/em> can be pretty much anything, which is both good and bad. Without a clear naming scheme, classes can quickly devolve into chaos.\n<\/p>\n \nAttribute selectors<\/em> can also be pretty much anything but they do carry great semantics with them. The semantic meaning of attributes makes them extremely powerful when used carefully.\n<\/p>\n \nFinally, element selectors<\/em> are broadly useful but can also be too specific. If you set margins on a simple p, then you’ll need to override that p over and over.\n<\/p>\n \nEvery selector in CSS is defined in the global scope. That is, each selector is available to the entire rendered document at once.\n<\/p>\n \nThis core feature of CSS is often seen as a bug and several attempts have been made to “correct” it. Heydon Pickering<\/a> raised a storm discussing such CSS features in 2016 (CSS Inheritance, The Cascade And Global Scope: Your New Old Worst Best Friends<\/a>).<\/p>\n With the name Scalable and Modular Architecture for CSS<\/a>, SMACSS seems to offer everything we want to cope with scale. It’s scalable! It’s modular! Perfect!\n<\/p>\n \nSMACSS takes us beyond using one file for everything by splitting CSS files into a logical order. This improves maintainability even for small projects.\n<\/p>\n \nWhile SMACSS lists five categories of splitting CSS (base, layout, module, state and theme), I’ve taken to using a modified structure: core, blocks, components, and site, which are detailed in the File Structures section below.<\/p>\n When I first looked into the Block Element Modifier<\/a> naming method, I found it very confusing. The broad concept seems clear enough but specifics of implementation are lacking. I assume this is somewhat intentional as BEM provides a loose structure that can be used however you like.\n<\/p>\n \nThe key feature of BEM is to apply a structured definition to classes. Once you wrap your head around it, it makes writing components highly beneficial.\n<\/p>\n \nBeyond standard BEM syntax, Harry Roberts<\/a> describes adding namespacing to provide additional scope to the naming structure under the name BEMIT<\/a>.<\/p>\n What does a design system have to do with CSS? Atomic Design<\/a> provides a way of structuring designs into separate interrelated parts. The methodology makes as much sense when applied to user interface code and hence CSS.\n<\/p>\n \nThe key advantage to scalable CSS is in providing an easy-to-understand structure, which helps immensely when working in dispersed teams.<\/p>\n I’m generally reluctant to go near variations over core language features in part to reduce dependencies. It took me a long time to adopt jQuery, and I’m reluctant to go near TypeScript.\n<\/p>\n \nIn similar ways, it took considerable thought and consideration before I adopted a CSS pre-processor, in this case Sass<\/a>. The key features of variables and nesting were enough in the end to convince me, especially given Sass compiles to vanilla CSS.\n<\/p>\n \nEven having adopted Sass, I remain reluctant to push too deep into the framework to make it easier to drop it whenever the time comes.<\/p>\n Not every design pattern scales well. Here are the methodologies I’ve looked at but haven’t yet found a use for.<\/p>\n Atomic CSS<\/a> uses functional classes to control scope. However, it essentially reverts back to compact inline styles. If you want to learn more about Atomic CSS, John Polacek<\/a> wrote a great summary of the methodology, “Let\u2019s Define Exactly What Atomic CSS is<\/a>“.\n<\/p>\n \nWhile there are certainly proponents of Atomic CSS out there, I’m not one of them. I find Atomic CSS to be abstracted to the point of nonsense and overrides don’t really make sense.\n<\/p>\n \nIf you need to set a blue background, the class is easy enough for one project.<\/p>\n The problem comes in as soon as you need to change that background in a subsequent project. You\u2019re left with the difficult choice of either repurposing The first line on the JSS<\/a> site declares, “JSS is a more powerful abstraction over CSS”, which immediately prompts questions such as, “How exactly does JavaScript improve CSS?” and “Is CSS broken?<\/a>“. I’m in fair agreement with both Bruce Lawson<\/a> above and Kevin Ball’s article “CSS in JS is like replacing a broken screwdriver with your favorite hammer<\/a>“. JSS has never particularly made sense to me. It’s as if we never learned from JSSS<\/a>.<\/p>\n The global scope of CSS can become a problem when CSS scales and CSS Modules<\/a> set out to ease exactly that by providing automated prefixing.\n<\/p>\n \nCSS Modules may provide everything you need to scale CSS. Each module contains vanilla CSS (or whatever your like), which is automatically scoped by the framework. Sheer brilliance.\n<\/p>\n \nShould you ever decide to shift away from CSS Modules, the code in each module is ready to go. You would have to manually scope but that’s it \u2014 no need for a significant rewrite.\n<\/p>\n \nFor widely distributed CSS libraries, platform neutrality is essential, and it’s at this point that CSS Modules become difficult to implement. While your team may be at the cutting edge of web methodologies, the industry has a long tail. What happens when you inherit a project built with an unsupported framework? Unfortunately, the answer is you don’t use CSS Modules.<\/p>\n Relatively new in this space, CSS Blocks<\/a> aim a step further beyond the automated scoping of CSS Modules and offer build-time error catching, dead code elimination and static analysis amongst other features. This requires a very tight integration between HTML, JavaScript and CSS, which is great if you have a tight control over your environments.<\/p>\n Once again fixing the problem (or otherwise) of scope in CSS, Stylable<\/a> also has tight programmatic integration with JavaScript and HTML.\n<\/p>\n \nThe rise of CSS Modules, CSS Blocks and Stylable is somewhat reminiscent of the early days of JavaScript frameworks when MooTools, jQuery and YUI all offered variations of the same thing. While much of the power of those frameworks has been integrated into the JavaScript language and browser DOM itself, it will be interesting to see what impact these tools will have on CSS itself.<\/p>\n Putting it all together involves a combination of solutions. Not every technique is required for every project and, if you set the right patterns early, you will be able to add complexity as and when you need to.\n<\/p>\n \nYou can see a working version of everything here on GitHub<\/a>.<\/p>\n Before you get to writing any code, take the time to set up a linting tool such as Stylelint<\/a>, CSSLint<\/a> or Sass Lint<\/a> if you’re using a pre-processor. Linters ensure consistent syntax across your project and can catch errors before you get too far. It doesn’t really matter what rules you set as long as you follow them.<\/p>\n Finding names for things is notoriously difficult. However, the effort spent to get there is well worth it.<\/p>\n Sparing use of BEM syntax provides a structure to a project’s components. Rather than applying BEM naming to every element, I find it much easier to only name those elements that require it in order to scope the subsequent styles.\n<\/p>\n \nSimple components may only need blocks to be named:<\/p>\n More complex components can add BEM naming as and when required:<\/p>\n In effect, this is a BEM-light implementation, which combines the strength of the pattern with the flexibility of vanilla CSS.<\/p>\n Namespacing is used as a way of scoping in programming languages, and there’s nothing stopping us from using the method in CSS. I favour a broad three-letter namespacing method to clearly show the origin of each class name.\n<\/p>\n \nNamespacing may not be required if you only work on one project. With pre-processed nesting, it’s easy enough to add at a later date should you find it necessary.\n<\/p>\n \nFor example, in the primary<\/em> project, the namespace will be Blocks unique to an inheriting project use their own namespace:<\/p>\n When inspecting the corresponding HTML, it’s immediately clear where the source can be found. Depending on the level of customisation, the odds are you won’t need to use a secondary namespace very often.<\/p>\n Rather than one big file or several big files, there’s a lot of benefit in splitting your CSS into logical folders. The original inspiration for this came from SMACSS<\/a>. However, I’ve adapted the folders and structure over several years of practical use.\n<\/p>\n \nDepending on the complexity of the project, it may help to version each file. Implementing Semantic Versioning<\/a> allows you to make breaking changes on an individual file with ease. If you don’t think you need to reach that point yet, it’s very easy to append versions to the file names when you do.<\/p>\n The Core<\/em> folder is home to the basics for your CSS library: global styles, utilities, typography and variables. Anything that you define once and use frequently belongs here. The content of this folder isn\u2019t expected to change much once it\u2019s written.\n<\/p>\n \nWhile CSS resets<\/a> have been popular in the past, the commonality of modern browsers means you should be fine without one. Be brave and move on from that reset!\n<\/p>\n \nShift all your break points, font faces and colour palettes into a \nBase typographic sizing also lives here (see A More Modern Scale for Web Typography<\/a> for a great reference to get you going) along with any basic structures such as a common grid.<\/p>\n Home to broad constructs from which the site is built, such as header, content, and footer. Each of these is essentially an organism<\/em> following the Atomic Design<\/a> methodology and, from a CSS perspective, the organisms don’t need to know what components do underneath them limiting the amount of CSS required in each file.<\/p>\n Each encapsulated component is contained in the Components<\/em> folder. You could potentially replace this with Atomic Design\u2019s molecules<\/em> and organisms<\/em> or similar depending on the complexity you have.<\/p>\n Styles that aren’t<\/em> shared are in the all<\/em> file first, inheriting everything from core, blocks, and components.\n<\/p>\n \nFor simple themed sites, a new \nMore complex themes may require a deeper level of infrastructure, mirroring the base project as required.<\/p>\n Notice the structure doesn’t completely reflect the original project. Only the complexity required has been added.<\/p>\n It’s tempting to add legacy browser code inline or in a separate file. However, a better approach is to add the code to the base of the relevant file with as many comments as you can.<\/p>\n While the scoped class above is derived from Modernizr<\/a>, feature queries (@supports<\/a>) are a native browser method of feature detection to achieve the same concept.<\/p>\n When variables in CSS first became possible with the likes of SCSS, my first thought was to use them for themes.<\/p>\n This is great until Multiple architectures<\/h3>\n
Ingredients<\/h2>\n
Vanilla CSS<\/h3>\n
SMACSS<\/h3>\n
BEM<\/h3>\n
Atomic Design<\/h3>\n
Sass<\/h3>\n
Left on the shelf<\/h2>\n
Atomic CSS<\/h3>\n
.bgr-blue {\n Background: #00f;\n}<\/code><\/pre>\n.bgr-blue<\/code> and set another colour in the CSS or modifying your HTML.<\/p>\nCSS in JS<\/h3>\n
CSS Modules<\/h3>\n
CSS Blocks<\/h3>\n
Stylable<\/h3>\n
The recipe for scalable CSS<\/h2>\n
Code integrity<\/h3>\n
Naming<\/h3>\n
Component naming<\/h4>\n
.nav { \/* navigation component *\/\n \u2026\n\n > ul { \/* list directly under the nav *\/\n \u2026\n\n > li { \/* list item directly under the list *\/\n \u2026\n }\n }\n\n a { \/* all anchors inside the navigation block *\/\n \u2026\n }\n}<\/code><\/pre>\n.tab { \/* tab component *\/\n &__tab-list { \/* tab list *\/\n \u2026\n }\n\n &__tab { \/* tab item *\/\n \u2026\n\n a { \/* anchor inside a tab item *\/\n \u2026\n }\n }\n}<\/code><\/pre>\nNamespacing<\/h4>\n
pri-<\/code>:<\/p>\n\/* without namespacing *\/\n.tab {\n \u2026\n}\n\n\/* with namespacing *\/\n.pri-tab {\n \u2026\n}<\/code><\/pre>\n\/* secondary project *\/\n.sec-nav {\n \u2026\n}<\/code><\/pre>\nFile structures<\/h3>\n
Core<\/h4>\n
variables<\/code> file. I also set a global measure<\/code>, on which many sizes such as grid-gap, padding and margins are derived and place it here.\n<\/p>\nBlocks<\/h4>\n
Components<\/h4>\n
All<\/h4>\n
all.css<\/code> for the inheriting project will be enough with each override (typically colour) contained in there.\n<\/p>\ntertiary.css\n\/tertiary\/buttons.css\n\/tertiary\/footer.css\n\/tertiary\/header.css\n\/tertiary\/nav.css<\/code><\/pre>\nYe Olde Browsers<\/h3>\n
.pri-grid {\n \u2026\n}\n\n\/*\nNo-flex\nSupport for non-flexbox browsers. Remove this once IE10 support is no longer required.\nMinimum width fixed to 900px to make things easier\n*\/\n.no-flexbox {\n .pri-grid {\n \u2026\n }\n}<\/code><\/pre>\nTheming<\/h3>\n
button {\n color: $main-colour;\n background: $secondary-colour;\n border-color: $main-colour; \n}<\/code><\/pre>\n$secondary-color<\/code> clashes with $main-colour<\/code> when you apply a different palette.\n<\/p>\n