At some point, while working on the MontageJS framework, the question came up what CSS naming convention we should start using. After a long discussion we settled on using the BEM methodology, but changed the syntax a bit. To keep this post short, I won’t go into detail why using BEM is a good idea, but rather explain why we chose a different syntax. Here some examples:

.digit-Progress          /* org-Component */
.digit-Progress-bar      /* org-Component-childElement */
.digit-Progress--small   /* org-Component--variation */

Note: The org- (digit-) prefix is used as a name-space so it wouldn’t conflict with other packages/libraries/frameworks.

Now let’s take a look at the reasons for choosing such a syntax.

Hyphens (-)

The main reason why we’re using a hyphen (-) instead of underscores (_), has to do with the fact that their behavior is different when double-clicking to select text. Try for yourself:

component__element /* underscores */
component-element  /* hyphen */

See how when you’re using underscores it selects the part before and after, in this case the whole component__element. But with hyphens it let’s you select only the part you double-clicked. component OR element. This let’s you quickly edit only the parts you want:

camelCase

Now, what if the component or child element consists of multiple words? We could use underscores like component_name-element_name. It would still be double-clickable, but readability suffers since it’s harder to see what belongs together. Better to use camelCase which groups each part visually: componentName-elementName.

MainComponent

OK, I think we’re getting closer. As a last rule, for the “main” component we use PascalCase. The reason for it is to add emphasis and make it easier to distinguish the main component from a child element. Also when using a namespace, the component moves to the second position, which makes it even more important to have it stick out: org-Component-childElement

–variation

We kept the more commonly used double hyphens (–) for variations. digit-Progress--small. It makes sense, because it pulls the variation (–small) visually more apart and makes it look like it’s something “different” than the default component.

So that’s about it. For more details about this naming convention, take a look at the SUIT framework, which also started to use the same syntax and documented it really well.

In the end, whatever Shade of BEM you choose to cook with probably depends on your personal taste, but thinking about a great UX by improving usability and readability won’t hurt either.

At this year’s CSSConf in Melbourne (AU) I gave a talk called “Styling with STRINGS”. The talk is about how we can use Flexbox, currentColor and __EM__s inside components to quickly style entire Web Apps straight in the browser.

In case of tl:dw here some of the main points:

Layout

When creating mobile “App” layouts, where not the whole page is scrollable, but instead only certain parts. And you have anchored areas like header/footer and a main area that should fill out the available space, then the easiest way is to use Flexbox.

This lets you easily drag around components that are set as flex items and they always position nicely. Using flex: 1; on components makes them stretch out and fill the available space. A good use case is a search input or a title.

Color

If you don’t specify the border-color (initial value) it will be the same value as color.

Furthermore there is a color value called currentColor. As the name indicates, it’s also mapped to the current color value. We can use it as background-color for example. Not that useful when the text should be readable, since now text and background are the same color, but for some components without text it can be quite useful. Like in the example below with the slider thumb.

If a component set should look similar to the “iOS 7” style then currentColor works great. Below all components have no color values at all and only use currentColor. This let’s us change everything by only changing the color value in the root html element.

Size

In a similar way, EMs are mapped to font-size. So if we use EMs to define only the proportions of a component, we can use font-size to scale it up/down. And if we inherit the font-size we could also control everything at once with just a single property in the root or in groups if we go deeper down the DOM tree.

REMs work the same except that they are tied to the root html element only. We could use it to control the spacing of the components by using REMs for margin/padding.

I wrote about this in more detail in the Sizing (Web) Components post.

All together

Now if we combine this all and test it in an example application, we can easily design many variations right from the DevTools/inspector in a quick and easy way.

Feel free to play around with the CSSConf App yourself or check out the source on GitHub.

How to save?

You might wonder how you can save the changes made in the DevTools/inspector without having to manually copy them over into your CSS file. In Chrome there is a feature called Workspaces. It let’s you map a URL to a local folder. Once that is setup, all CSS changes will automatically be saved to your local disc. Here a post that explains how to setup Workspaces. It’s advised to use version control like Git, so that you can always discard all changes if you went too far and wanna start over.

Conclusion

Admittedly it is somewhat in between of being useful for production and just a “hack”. Especially the currentColor. But the main point of the talk is best told by this quote:

“Creators need an immediate connection” — Bret Victor

The examples I used are just the closest I could get using CSS alone and still keep code clean. I hope we keep that principle alive and improve on it.

ps. Artist of the puppet master illustration: Unknown.

pss. Here all the other videos from CSSConf.

Something I’ve been wanting for a long time, define different regions like a footer section, or side bar and not have to deal with all the contextual styling hassle. A.k.a. “Now that this button is used on a dark background, the button needs to change its colors too. Where should the styles live?”. Here an old post about struggling with contextual styling.

So then the other day I was doing some experiments with using custom properties for Atom’s UI. Turns out, using custom properties might make contextual styling a bit easier. For the rest of the post, let’s switch to a more simple example. A page where the main area is light, but then has a dark hero and footer section. Like this:

In the past, I probably would’ve created variations like Button--dark or overwrote it with header .Button {…}. Depends a bit on the project. Here another approach: Create themes with a set of variables, then apply the theme to the different areas.

1. Default theme

First let’s define our default theme with a bunch of variables.

[data-theme="default"] {
  --fg:         hsl(0,0%,25%);
  --border:     hsl(0,0%,75%);
  
  --bg:         hsl(0,0%,95%);
  --button-bg:  hsl(0,0%,99%);
  --input-bg:   hsl(0,0%,90%);
}

Then we create some components where we use the variables defined above.

[data-theme] {
  color: var(--fg);
  background-color: var(--bg);
}

.Button {
  color: var(--fg);
  border: 1px solid var(--border);
  background-color: var(--button-bg);
}

.Input {
  color: var(--fg);
  border: 1px solid var(--border);
  background-color: var(--input-bg);
}

And lastly we add the [data-theme="default"] attribute on the body so that our components will pick up the variables.

<body data-theme="default">

If you wonder why use data-theme attributes over classes? Well, no specific reason. Maybe with attributes, it’s a hint that only one theme should be used per element and is more separated from your other classes.

At this point we get this:

See the Pen Contextual styling with custom properties (1/3) by simurai (@simurai) on CodePen.

2. Dark theme

But our designer wants the hero and footer to be dark. Alright, let’s define another theme region.

[data-theme="dark"] {
  --fg:         hsl(0,10%,70%);
  --border:     hsl(0,10%,10%);
  
  --bg:         hsl(0,0%,20%);
  --button-bg:  hsl(0,0%,25%);
  --input-bg:   hsl(0,0%,15%);
}

And add the theme attribute to the header and footer.

<header data-theme="dark">
<footer data-theme="dark">

Which gives us this:

See the Pen Contextual styling with custom properties (2/3) by simurai (@simurai) on CodePen.

The reason why this works is that custom properties cascade and can be overridden on nested elements, just like normal properties.

3. Hero theme

A few months pass and our designer comes back with a redesigned hero section. “To make it look fresh” with a splash of color.

No problem! Just like with the dark theme, we define a new “hero” theme.

[data-theme="hero"] {
  --fg:         hsl(240,50%,90%);
  --border:     hsl(240,50%,10%);
  
  --bg:         hsl(240,33%,30%);
  --button-bg:  hsl(240,33%,40%);
  --input-bg:   hsl(240,33%,20%);
}

<header data-theme="hero">

And here is that fresh hero:

See the Pen Contextual styling with custom properties (3/3) by simurai (@simurai) on CodePen.

It’s also not limited to colors only, could be used for sizes, fonts or anything that makes sense to define as variables.

Benefits

Using these theme “regions” lets your components stay context un-aware and you can use them in multiple themes. Even on the same page.

• Developers can add components, move components around, without having to know about in what context (theme) they live. The markup for the components stays the same.
• Design systems authors can create new components without worrying about where they get used, the variables used in components stay the same.
• Designers can define new theme regions, or change existing ones, without having to make changes to a component’s HTML or CSS, it stays the same.

Less time to talk about who, how and where, more time to talk about the weather. ☔️????

Concerns

Yeah, right. The big question: But does it scale? Can this be used for all use cases.

Ok, I’m pretty sure it doesn’t fit all situations. There are just too many to find a single solution for them all. And I’m actually not sure how well it scales. I guess it works great in these simple demos, but I have yet to find a larger project to test it on. So if you have used (or plan to use) this approach, I’m curious to know how it went.

A concern I can imagine is that the list of variables might grow quickly if themes have totally different characteristics. Like not just a bit darker or lighter backgrounds. Then you might need to have foreground and border colors for each component (or group of components) and can’t just use the general --fg and --border variables. Naming these variables is probably the hardest part.

Update I

@giuseppegurgone made an interesting comment:

in suitcss projects I used to define component level custom props, theme variables and then create themes by mapping the former to the latter suitcss-toolkit

So if I understood it correctly, by mapping theme variables to component variables, you could avoid your theme variables from growing too much and you can decide for each component how to use these theme variables.

Update II

If it’s too early to use custom properties in your project, @szalonna posted an example how to do something similar in SCSS.

Teamstack is a password manager for your whole team. Running in the cloud it allows you to manage your tools and resources, and seamlessly scale your teams’ access, from a single, easy-to-use control panel. Teamstack is powerful, and secure with multi-factor authentication, single sign-in, SAML and form-based authentication. It works with desktop and mobile apps, […]

Rotch Library - TR184.B75 2018

Rotch Library - N8219.L5 J64 2019

Rotch Library - N6260.K87 2019

Rotch Library - N6888.B745 A4 2018

Rotch Library - TR647.P37 2018

Rotch Library - NX512.C36 A4 2018

Rotch Library - N6488.I8 V433 2019 E3

Rotch Library - TR647.H42 2018

Rotch Library - N7267.N45 2019

Rotch Library - N6537.C663 A4 2018

Barker Library - NC975.5.K78 A2 2018

Rotch Library - TR350.P53 2018

Dewey Library - TR268.W582 2019

Rotch Library - N8354.A3513 2019

Rotch Library - N7280.B47 2019