Time is passing by

CSS selectors all exist within the same global scope. Anyone who has worked with CSS long enough has had to come to terms with its aggressively global nature — a model clearly designed in the age of documents, now struggling to offer a sane working environment for today’s modern web applications. Every selector has the potential to have unintended side effects by targeting unwanted elements or clashing with other selectors. More surprisingly, our selectors may even lose out in the global specificity war, ultimately having little or no effect on the page at all.

Any time we make a change to a CSS file, we need to carefully consider the global environment in which our styles will sit. No other front end technology requires so much discipline just to keep the code at a minimum level of maintainability. But it doesn’t have to be this way. It’s time to leave the era of global style sheets behind.

It’s time for local CSS.

In other languages, it’s accepted that modifying the global environment is something to be done rarely, if ever.

In the JavaScript community, thanks to tools like Browserify, Webpack and JSPM, it’s now expected that our code will consist of small modules, each encapsulating their explicit dependencies, exporting a minimal API.

Yet, somehow, CSS still seems to be getting a free pass.

Many of us — myself included, until recently — have been working with CSS so long that we don’t see the lack of local scope as a problem that we can solve without significant help from browser vendors. Even then, we’d still need to wait for the majority of our users to be using a browser with proper Shadow DOM support.

We’ve worked around the issues of global scope with a series of naming conventions like OOCSS, SMACSS, BEM and SUIT, each providing a way for us to avoid naming collisions and emulate sane scoping rules.

We no longer need to add lengthy prefixes to all of our selectors to simulate scoping. More components could define their own foo and bar identifiers which — unlike the traditional global selector model—wouldn’t produce any naming collisions.

import styles from './MyComponent.css';
import React, { Component } from 'react';
export default class MyComponent extends Component {
 render() {
    return (
      <div>
        <div className={styles.foo}>Foo</div>
        <div className={styles.bar}>Bar</div>
      </div>
    );
  }

The benefits of global CSS — style re-use between components via utility classes, etc. — are still achievable with this model. The key difference is that, just like when we work in other technologies, we need to explicitly import the classes that we depend on. Our code can’t make many, if any, assumptions about the global environment.

Writing maintainable CSS is now encouraged, not by careful adherence to a naming convention, but by style encapsulation during development.

Once you’ve tried working with local CSS, there’s really no going back. Experiencing true local scope in our style sheets — in a way that works across all browsers— is not something to be easily ignored.

Introducing local scope has had a significant ripple effect on how we approach our CSS. Naming conventions, patterns of re-use, and the potential extraction of styles into separate packages are all directly affected by this shift, and we’re only at the beginning of this new era of local CSS.

process.env.NODE_ENV === 'development' ?
    '[name]__[local]___[hash:base64:5]' :
    '[hash:base64:5]'
)

Understanding the ramifications of this shift is something that we’re still working through. With your valuable input and experimentation, I’m hoping that this is a conversation we can have together as a larger community.

Note: Automatically optimising style re-use between components would be an amazing step forward, but it definitely requires help from people a lot smarter than me.


Stumbled the concept

If you’re not sure how much time you are actually spending on various tasks, use a tool like Rescue Time (their free version is excellent!) which runs in the background and tracks where your time is being spent. It can even send you weekly reports so you know exactly how much time you wasted on Facebook, or spent in your email inbox! You can assign different websites or programs/applications on a scale of very distracting to very productive, so you can see at a glance things like: which days of the week you’re most productive, which times of the day you’re most productive, and the sites on which you’re spending the most distracting time. I stumbled upon the concept of margin while reading a post by Michael Hyatt, which led me to design my ideal week.

Richard Swenson, M.D. (who wrote the book: Margin: Restoring Emotional, Physical, Financial, and Time Reserves to Overloaded Lives) describes margin like this:

Last year I wrote about why booking too far in advance can be dangerous for your business, and this concept of margin so eloquently captures what I had recognized had been my problem: I was so booked up with clients that I wasn’t leaving any margin for error, growth, planning, or reflection. I wasn’t really growing my business in a sustainable way; I was just booking one client after the next. At the time this seemed like a good thing: doesn’t growing my business mean getting more clients?

What if instead of booking up to 100% capacity (which more often than not ends up being closer to 120%), we only booked up to an 80% capacity?

What if we left more room for growth (personal or professional) and stopped being one with “busy-ness”?
I spent nearly a year turning down every new project (and even getting rid of old ones) so that I could reduce my workload, build in more margin, and create what is now Digital Strategy School. It takes time to build margin into your schedule.

What could you accomplish with 20% more time?

Write a book. Create a program. Update your contracts and proposals (which has been on your to-do list for how long..?) Spend more time with your family. Go above and beyond for a client. Learn something new. Actually follow through on the things that have been nagging at you for a long time.

When you design your ideal week, you start to see that the time you think you have is often not in alignment with how much time you actually have.

After designing my ideal week, I had a much clearer idea of how to create a framework for my week that would empower me to feel more focused by theming days of the week, and even parts of the day. SO simple, I know. Some of you have been doing this for ages and you’re already a pro, and some of you who saw my schedule said “woah, that’s so rigid, I need more flexibility!”

Structure enables flexibility.

If you’re not sure how much time you are actually spending on various tasks, use a tool like Rescue Time (their free version is excellent!) which runs in the background and tracks where your time is being spent. It can even send you weekly reports so you know exactly how much time you wasted on Facebook, or spent in your email inbox! You can assign different websites or programs/applications on a scale of very distracting to very productive, so you can see at a glance things like: which days of the week you’re most productive, which times of the day you’re most productive, and the sites on which you’re spending the most distracting time. Turns out I’m consistently “in the zone” around 3pm in the afternoon; so instead of trying to tackle highly creative work first thing in the morning (when my brain is barely functioning), I handle it in the afternoon, when I know I’m at my peak!

Creating more margin has been game-changing for my business.
What would be possible for yours?