Notice that in development mode those styles will go into a in the and Vite's latest version will even add a data-vite-dev-id attribute with the url and generated hash of the CSS file it extracts from the SFC. Of course when building your app for production, your bundler of choice will put this code into a separate .css file.

So it's that easy to create scoped styles in Vue.js. Fun fact the scoped attribute on the style tag actually comes from a W3C draft for implementing native scoping for CSS, which was unfortunately abandoned.

Working around child selectors

Now there is one small problem with this method of scoping CSS.

Let's say you have an API that delivers raw HTML text, that content editors add using the WYSIWYG editor of some CMS.

Now inserting raw HTML to Vue templates is trivial with the v-html directive, but you also want to style these tags independently, so you create a component to encapsulate their CSS.

This would all look like this:

<template>
     class="rich-text" v-html="props.text" />
template>

<script setup>
const props = defineProps({
    text: String
})
script>

<style lang="scss" scoped>
.rich-text {
    p {
        margin: 0 0 1rem 0;
    }

    ol {
        list-style-type: lower-alpha;
    }

    ul {
        list-style-type: circle;
    }

    // some more styles for all possible tags...
}
style>

Enter fullscreen mode Exit fullscreen mode

Now your component will render the following CSS.

.rich-text p[data-v-60170f23] {
  margin: 0 0 1rem 0;
}
.rich-text ol[data-v-60170f23] {
  list-style-type: lower-alpha;
}
.rich-text ul[data-v-60170f23] {
  list-style-type: circle;
}

Enter fullscreen mode Exit fullscreen mode

But the tags inserted by v-html won't receive the data-v- attributes as the other tags in your component.

You can change the CSS output so that the scoping will also work for nested elements.

<style lang="scss" scoped>
.rich-text {
    :deep(p) {
        margin: 0 0 1rem 0;
    }

    :deep(ol) {
        list-style-type: lower-alpha;
    }

    :deep(ul) {
        list-style-type: circle;
    }

    // some more styles for all possible tags...
}
style>

Enter fullscreen mode Exit fullscreen mode

Now the styles generated will look like this:

.rich-text[data-v-60170f23] p {
  margin: 0 0 1rem 0;
}
.rich-text[data-v-60170f23] ol {
  list-style-type: lower-alpha;
}
.rich-text[data-v-60170f23] ul {
  list-style-type: circle;
}

Enter fullscreen mode Exit fullscreen mode

The data-v- goes in front of the parent selector so child selectors will get applied and scoping will be maintained.

Syntax variations

If you've googled this problem before you may have found some alternate syntaxes to do the same thing, so let's clarify things a bit.

You've may seen this:

.alert ::v-deep h1 {
…
}

Enter fullscreen mode Exit fullscreen mode

Or this

.alert /deep/ h1 {
…
}

Enter fullscreen mode Exit fullscreen mode

Or even this

.alert >>> h1 {
…
}

Enter fullscreen mode Exit fullscreen mode

In Vue 3 and Vue 2.7 all of these have been deprecated, so while your code may work, the compiler will show a warning and they will stop working in some future release. So it's best to use :deep(), unless you are on Vue >2.7.

Also note that if you are using SCSS, the >>> and /deep/ syntax will throw an error in Vue 3, while the ::v-deep will still work but with a warning.

Bottom line is, just use :deep() on all newer versions of Vue.

New CSS features in Vue 3

With Vue 3 we've got two new combinators next to :deep().

Scoped styles for slots

First we have :slotted() which lets you target any HTML that's inserted to one of the slots of your component.

Let's say you want to add another slot in the component and you'd want whatever element that goes in that slot to have a specific styling defined by it.

<template>
     class="alert">
         name="header" />
         />
    

template> <style scoped> .alert { --base-gutter: 0.4rem; padding: calc(var(--base-gutter) * 2); border: 1px solid #ffea2a; background-color: #fff48d; border-radius: var(--base-gutter); } h1 { font-size: 1.8rem; border-bottom: 1px solid rgba(0, 0, 0, 0.2); margin-bottom: calc(var(--base-gutter) * 2); margin-top: 0; padding-bottom: calc(var(--base-gutter) * 2) } style>

Enter fullscreen mode Exit fullscreen mode

    <template #header>
      
Hi there!
    template>
    This is some warning for the user from the system.

Enter fullscreen mode Exit fullscreen mode

This of course won't work. If you look at what CSS was generated, you'll find this selector.

h1[data-v-3f4a8ec2] {
   // our h1 styles
}

Enter fullscreen mode Exit fullscreen mode

This would work if we would have the

tag in our component and only its text content coming in via a props, but for whatever reason we don't want to do that.

To make this work we can change our component's CSS like so:

:slotted(h1) {
    font-size: 1.8rem;
    border-bottom: 1px solid rgba(0, 0, 0, 0.2);
    margin-bottom: calc(var(--base-gutter) * 2);
    margin-top: 0;
    padding-bottom: calc(var(--base-gutter) * 2)
}

Enter fullscreen mode Exit fullscreen mode

Now it works! And what's even cooler is, if that you add another style block to the ...

h1 {
    color: red
}

Enter fullscreen mode Exit fullscreen mode

...and a this line of code to the template.

I'm hard coded in the component

Enter fullscreen mode Exit fullscreen mode

You'll see that the

we pass through the #header slot doesn't get red, while it's rules won't affect the "hard-coded"

.

If you are wondering how Vue.js does this, it's very easy. The difference in the rendered output is literally one character.

h1[data-v-3f4a8ec2] {
  // styles for the tag inside the component
}

Enter fullscreen mode Exit fullscreen mode

h1[data-v-3f4a8ec2-s] {
  // styles for the tag coming from the slot
}

Enter fullscreen mode Exit fullscreen mode

The generated :scoped() selector gets an extra -s appended to the file name hash that's used to scope elements inside the components.

Global styles

The :global() combinator provides an escape hatch from the scoped styles. A good use case for this would be if you have some page identifier class on the main tag, which is normally out of scope of your Vue application, but you want to keep your styles that hook into these classes inside your page components.

<style scoped>
.App {
  color: #000;
}

:global(body.home-page) {
  background-color: antiquewhite;
}
style>

Enter fullscreen mode Exit fullscreen mode

Also note that this could be achieved by adding two </code> tags in your SFC, one with the <code>scoped</code> attribute and one without it.<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight vue"><code><span class="nt"><</span><span class="k">style</span><span class="nt">></span> <span class="nt">body</span><span class="nc">.home-page</span> <span class="p">{</span> <span class="nl">background-color</span><span class="p">:</span> <span class="no">antiquewhite</span><span class="p">;</span> <span class="p">}</span> <span class="nt"></</span><span class="k">style</span><span class="nt">></span> <span class="nt"><</span><span class="k">style</span> <span class="na">scoped</span><span class="nt">></span> <span class="nc">.App</span> <span class="p">{</span> <span class="nl">color</span><span class="p">:</span> <span class="m">#000</span><span class="p">;</span> <span class="p">}</span> <span class="nt"></</span><span class="k">style</span><span class="nt">></span> </code></pre> <div class="highlight__panel js-actions-panel"> <div class="highlight__panel-action js-fullscreen-code-action"> <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewbox="0 0 24 24" class="highlight-action crayons-icon highlight-action--fullscreen-on"><title>Enter fullscreen mode</title> <path d="M16 3h6v6h-2V5h-4V3zM2 3h6v2H4v4H2V3zm18 16v-4h2v6h-6v-2h4zM4 19h4v2H2v-6h2v4z"></path> </svg> <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewbox="0 0 24 24" class="highlight-action crayons-icon highlight-action--fullscreen-off"><title>Exit fullscreen mode</title> <path d="M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z"></path> </svg> </div> </div> </div> <h3> <a name="jsincss-the-vue-way" href="#jsincss-the-vue-way"> </a> JS-in-CSS the Vue way </h3> <p>This last one is the most exciting and solves a lot of the use cases for which you would have had to turn to CSS-in-JS libraries like <a href="https://github.com/egoist/vue-emotion">vue-emotion</a> in the past.</p> <p>You can use the v-bind directive as a CSS value and extrapolate any JS value inside the <code><style></code> tag of the SFC just as you would in your <code><template></code>.</p> <p>This is great for every use case where you want your styles to react directly to some user input or state change without having to write a bunch of predefined classes.</p> <p>To demonstrate how powerful this feature is, I've added a small demo with a color picker.</p> <p><iframe src="https://stackblitz.com/edit/vitejs-vite-va5yn3?embed=1&file=src/App.vue" width="100%" height="500" scrolling="no" frameborder="no" allowfullscreen allowtransparency="true" loading="lazy"> </iframe> </p> <p>If you look at the rendered code you'll see that Vue.js is generating CSS custom properties that are inserted into inline styles and then they cascade down the component.<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight html"><code><span class="nt"><div</span> <span class="na">data-v-45e5ffe2</span> <span class="na">style=</span><span class="s">"--45e5ffe2-color:rgb(230, 74, 25);"</span><span class="nt">></span> <span class="nt"><div</span> <span class="na">data-v-45e5ffe2</span><span class="nt">></span> <span class="nt"><div</span> <span class="na">class=</span><span class="s">"vc-color-wrap transparent"</span> <span class="na">data-v-11bd4fe5=</span><span class="s">""</span><span class="nt">></span> <span class="nt"><div</span> <span class="na">class=</span><span class="s">"current-color"</span> <span class="na">data-v-11bd4fe5</span> <span class="na">style=</span><span class="s">"background: rgb(230, 74, 25);"</span><span class="nt">></div></span> <span class="nt"></div></span> <span class="nt"></div></span> <span class="nt"><p</span> <span class="na">class=</span><span class="s">"example"</span> <span class="na">data-v-45e5ffe2</span><span class="nt">></span>Click on the square to select a color!<span class="nt"></p></span> <span class="nt"></div></span> </code></pre> <div class="highlight__panel js-actions-panel"> <div class="highlight__panel-action js-fullscreen-code-action"> <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewbox="0 0 24 24" class="highlight-action crayons-icon highlight-action--fullscreen-on"><title>Enter fullscreen mode</title> <path d="M16 3h6v6h-2V5h-4V3zM2 3h6v2H4v4H2V3zm18 16v-4h2v6h-6v-2h4zM4 19h4v2H2v-6h2v4z"></path> </svg> <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewbox="0 0 24 24" class="highlight-action crayons-icon highlight-action--fullscreen-off"><title>Exit fullscreen mode</title> <path d="M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z"></path> </svg> </div> </div> </div> <div class="highlight js-code-highlight"> <pre class="highlight css"><code><span class="nc">.example</span><span class="o">[</span><span class="nt">data-v-45e5ffe2</span><span class="o">]</span> <span class="p">{</span> <span class="nl">color</span><span class="p">:</span> <span class="n">var</span><span class="p">(</span><span class="n">--45e5ffe2-color</span><span class="p">);</span> <span class="p">}</span> </code></pre> <div class="highlight__panel js-actions-panel"> <div class="highlight__panel-action js-fullscreen-code-action"> <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewbox="0 0 24 24" class="highlight-action crayons-icon highlight-action--fullscreen-on"><title>Enter fullscreen mode</title> <path d="M16 3h6v6h-2V5h-4V3zM2 3h6v2H4v4H2V3zm18 16v-4h2v6h-6v-2h4zM4 19h4v2H2v-6h2v4z"></path> </svg> <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewbox="0 0 24 24" class="highlight-action crayons-icon highlight-action--fullscreen-off"><title>Exit fullscreen mode</title> <path d="M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z"></path> </svg> </div> </div> </div> <p>I hope you've found this post useful and it will help you write CSS more effectively in your next Vue.js project!</p>

Besides of styled-components library, there are also other CSS-in-JS libraries usable for Vue.js, for example Emotion through vue-emotion package.

KumaUI : Another relatively new contender, Kuma uses zero runtime CSS-in-JS to create headless UI components which allows a lot of flexibility. It was heavily inspired by other zero runtime CSS-in-JS solutions such as PandaCSS, Vanilla Extract, and Linaria, as well as by Styled System, ChakraUI, and Native Base. ### Vue

Then we started using Chakra, which has style props based on Styled System. I'm quite happy with them after about a year.

Your repo still links to styled-system.com, are you planning on hosting your own docs?

But yeah, Tailwind fanboys do hate it, because Chakra needs some initial time to research and understand how it works under the hood. And then it gets super easy and intuitive to use. It's an implementation of a general concept abstraction called styled-system, I advise anyone to start their learning about Chakra from there: https://styled-system.com/

Note how each class in the atomic version maps to just a single CSS property and value. In fact, if I hadn’t included the second block, I bet you’d have had no problem determining each class’ effect from the markup alone! This is a hallmark of atomic CSS — the effect of a class is typically self evident from its name alone, whereas the specifics of a class name like media are more ambiguous.

For anyone familiar with atomic CSS today, the example above will likely appear unremarkable. The transition towards this approach was anything but, however — and on some corners of the web today, debate still rages about whether atomic CSS has been the best or worst thing to happen to styling on the web since CSS.

There was, however, clearly an appetite for this approach amongst a non-trivial swath of web developers: the year 2014 saw the release of both Adam Morse’s Tachyons and Brent Jackson’s Basscss, the first two frameworks to go all-in on atomic CSS. These frameworks were instrumental in writing the blueprints for the atomic CSS methodology and turning the status quo on its head — and indeed, the shift was so monumental that, within a number of years, ‘utility-first’ CSS frameworks started becoming multimillion dollar businesses.

The atomization of CSS had officially begun.

Atomic CSS: successes and perceived failures

In order to understand the success of atomic CSS (even if that success remains a point of debate in some circles), we should first examine its principles, and the goals those principles seek to achieve. Many of these principles are derived from functional programming, hence the alternative name ‘functional CSS’. Additional inspiration came from the Unix philosophy.

The most fundamental principles of atomic CSS are:

Classes should have a single purpose.

Classes should do one thing, and they should do it well. This makes each class more reusable. A class that applies a margin, and only a margin, is more reusable than a class that applies and margin and a text colour.

A class’ effect should be self evident.

There should be no mystery about the effect of using a class — clarity should always trump cleverness. The effect of a class named flex which sets the display property to flex is self evident. The effect of a class named media which may set any number of property values is ambiguous.

Classes should be composable.

Complex styles should be achieved by composing multiple single purpose classes together, rather than by writing new, complex, and less reusable classes.

Classes should be immutable and free of side effects.

For example, the underline class should only ever apply an underline style. It should never not apply the underline, or apply another style, or change any other property of any other element. Under no circumstances should it change the effect of another class.

It’s important to note that these principles were not devised for their own sake — each plays an important role in authoring performant, maintainable, robust styles:

• Single purpose classes are more reusable and composable than multipurpose classes. Thus, single purpose classes provide greater flexibility as well as reduced CSS file sizes, both at the outset of new projects and throughout their lifecycle (as fewer styles need to be added to deliver iterations and additions to UI).

• Classes with singular, self evident effects reduce cognitive overhead for developers; the resultant styling systems are thus easier to learn, and this in turn helps frontend teams scale their efforts across people and time.

• Classes which are immutable and free of side effects result in fewer bugs — and where bugs occur, easier debugging and resolution follows.

In these ways and in others, I have always felt that the nature of atomic CSS flows very much with the grain of CSS itself. Remember that CSS was designed to be independent of markup, and atomic CSS is by design untethered to any particular markup structure or content based semantics. Atomic CSS also honors CSS’ specificity algorithm rather than attempting to game it — it does not concern itself with optimized selector ranking or scope, since every class is of single purpose and equal specificity. This also means CSS’ inheritance model becomes an advantage as it was originally intended: compositions can be built up with inheritance in mind, over several layers of markup.

There are, however, many common objections raised against the atomic CSS methodology. In general, these tend to be:

’It’s not semantic.’

We’ve touched on this already, but it’s worth repeating: semantics, accessibility, and clarity do matter, but with all due respect to Zeldman, there is nothing inherently unsemantic, inaccessible, or unclear about ‘visual class names’, nor is there a reason for CSS to map to the same semantics as HTML.

‘This is inline styles all over again.’

Nope. Inline styles are defined in HTML; atomic classes are defined in a style sheet. Inline styles do not permit media queries, pseudo elements, or pseudo classes; atomic classes do. Inline styles have a specificity ranking of 1-0-0-0, which can only be outranked by !important; atomic classes have a specificity of 0-0-1-0, the same as any single class. An inline style’s source of truth is its own singular invocation on a given element; an atomic class’ source of truth is a style sheet. There is a lexical resemblance between class='red' and style='color: red'; this is where the similarities end.

‘Putting so many classes on my elements looks ugly/is hard to read.’

Admittedly, doesn’t read like poetry (and yes, that snippet is taken from this very page as of this writing). However, something that is a delight is being able to rapidly iterate on this composition — from the logical origin of that composition (the markup), whether in the browser or my editor — to explore different combinatorial spaces within the bounds of a design system. Iterating in this fashion simply cannot be matched when using other methodologies.

‘This is so not DRY.’

It’s true, atomic CSS can lead to repeating declarations of various styling rules — but I vastly prefer repeating declarations to repeating definitions (which, in my experience, are much harder to maintain). Also, remember that every time you repeat a class name, that’s one more addition you didn’t have to make to your style sheet! Ultimately, this is a matter of choosing what kind of repetition you want, not one of avoiding repetition altogether.

‘Atomic CSS is at odds with modern component modeling.’

‘Thinking in React’ is one of those articles that changed the way I thought about web development when it was published, and there’s no denying that building frontends on the web has become a component centric process. However, it’s important to differentiate the process of thinking in components and the process of styling components. A conceptual abstraction does not require an equivalent material abstraction, and the fact of a component’s existence does not necessitate a dedicated CSS class.

‘This still doesn’t solve the problem of global scope or one off styles.’

It doesn’t, and in fact atomic CSS is not designed for this. For scoped or one off styles, a different approach is absolutely required.

Atomic CSS can provide a fantastic foundation that covers the vast majority of styling needs for a given website and its constituent components, and it can deliver those styles in a fraction of the file size and complexity of other methodologies. To be clear, these claims are not theoretical: this has been my experience both as a contributor and leader of frontend teams over the past 8 years, and the same has been true for many others both within and outside of my professional circle. But as we’ve noted, atomic CSS doesn’t cover every use case: scoped and one off styles are not part of its wheelhouse. So what’s to be done when a need for these sorts of styles emerges?

Going bespoke

Photo by Chris Ralston on Unsplash

Where one off styles are needed, or where we want to ensure certain styles are scoped to a given component, additional measures beyond an atomic CSS methodology will be required. There are several techniques that can be used to address these concerns, with a few notable examples having become more popular in recent years:

CSS in JS

The obvious contender in this list. I used CSS in JS for many years myself, and have to say the developer ergonomics are pretty impressive, as is the ability to leverage both repeatable and bespoke, scoped styles (especially when using libraries like Styled System or Theme UI). Unfortunately, great developer ergonomics and scoping are not enough. CSS in JS can add significant weight to client side bundles, along with increased setup complexity (especially when server side rendering is involved). Some solutions can also lock you in to certain frontend frameworks, limiting the portability of your styles. There are some solutions emerging to address these concerns (e.g. Vanilla Extract), but at the end of the day, I admit I’m growing tired of learning abstractions of CSS — there are so many more valuable things I could be doing with my time. This isn’t necessarily a popular opinion, but I think CSS is actually pretty amazing on its own, and the closer to the metal I can stay, the happier I am.

CSS Modules

The name may suggest that CSS Modules are part of the CSS spec, but this is not the case. CSS Modules allow authors to extract styles from a vanilla .css file and into a JavaScript file containing markup; at build time, these extracted styles are then regenerated as locally scoped styles wherever they are used. This seems to offer some of the benefits of CSS in JS, but without the ergonomics of colocating styles, content, and behavior within a given component.

Shadow DOM

Shadow DOM is a web standards specification which is designed to provide encapsulation of content, styles, and behavior — but it has a number of hard to swallow caveats. For one, Shadow DOM roots need to be initialized in JavaScript (though Declarative Shadow DOM should address this in the future.) Further, styling encapsulation doesn’t work quite like you think it does, and this can cause some headaches. I believe the Shadow DOM holds promise, but for many use cases, it can end up being more trouble than it’s worth.

Fortunately, a compelling solution for dealing with scoped and one off styles exists in the form of HTML custom elements, which are part of the web components spec along with Shadow DOM and HTML templates. I may be biased, but I think the best way to work with custom elements right now is with Enhance (though to be fair, I got a sneak peak at Enhance before joining Begin in 2022, and was just as enthusiastic at that time).

Using Enhance to author custom elements in the form of Single File Components (SFCs) has a number of huge benefits:

1. Custom elements are expanded on the server, providing great performance and an excellent baseline for progressive enhancement on the client.

2. Locally scoped, one off styles can be authored simply by including a </code> block in your SFC. When your component is expanded on the server, these style blocks will be hoisted into the document head, with all of that style block’s selectors scoped to your custom element. This allows for one off styles to be encapsulated and scoped to the component they’re authored in, without needing to touch the Shadow DOM. Scoped styles written within an SFC are also a great place to leverage strategies like <a href="https://css-tricks.com/are-we-in-a-new-era-of-web-design-what-do-we-call-it/">intrinsic design</a>, which can happily coexist alongside a global, atomic class system.</p></li> <li><p>If you don’t need to write client side behavior, <strong>you never have to interface with JavaScript classes or the <a href="https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry">Custom Elements Registry</a></strong>. This is particularly handy for engineers (or designers) who might excel at HTML and CSS but lack experience in JavaScript. Although SFCs are authored as JavaScript functions, the bulk of the authored code is written in HTML and CSS, as seen below:<br> </p></li> </ol> <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code><span class="c1">// my-button.mjs</span> <span class="k">export</span> <span class="k">default</span> <span class="kd">function</span> <span class="nx">MyButton</span><span class="p">({</span> <span class="nx">html</span> <span class="p">})</span> <span class="p">{</span> <span class="k">return</span> <span class="nx">html</span><span class="s2">` <style> /* One off styles applied only to button elements rendered by MyButton. */ /* Any button outside this component will not be affected. */ button { appearance: none; box-shadow: 0 2px 4px rgba(0,0,0,0.1); } ` } // index.html <my-button>Click Me!</my-button>

I find css-as-props is better than a huge string of classes, as it much more readable and statically analyzable. I wonder if anyone is working on a successor to styled-system (though it works fine).

[1] https://styled-system.com/

My goal was to try a few new libraries and get experience under my belt (cause isn’t that what dev blogs are for?). I’d swap out Gatsby for **Astro,** and Styled Components + Styled System for **Vanilla Extract**. I was interested in trying Astro as it just hit 1.0, and I’ve been experimenting for a while with Vanilla Extract as a way to write Typescript powered styles and export to CSS.

I'm a huge fain of Tailwind but if you're using react you can also consider styled-system:

https://styled-system.com

It seems to have a lot of the benefits of Tailwind but better integration with Typescript.

Our app is a little odd. It's a very specialized version of something like Wix or Squarespace for use in a particular niche. The majority of our front end code is our own component library, really, and we use styled-components along with what will soon be a custom fork of this now sadly abandoned project: https://styled-system.com/. Styled system is great for us because it allows our users to do extensive, responsive theming in ways we define and keep from being ugly when touched by non-coders on a component by component basis.

Restyle is my personal favorite. It’s strongly inspired by the amazing, albeit a bit outdated, styled-system for web, but is fully type-safe and has amazing customization options.