Practical Example of Using CSS Layer

Let’s say we are developing a component library. 

Let’s say we are using React. 

Let’s say it has a button component.

Conventionally, it will look like this:

// CustomButton.js

import './CustomButton.css'

const CustomButton = ({ children, className = '' }) => {
	const customClass = 'CustomButton' + className;
	return <button className={customClass}>{children}</button>
}

And the styles will look like this:

/* CustomButton.css */

.CustomButton {
	background: aquamarine;
	padding: 4px 12px;
	border: none;
}

Here, the developers come to us and say: “The button is great, but we need a link in the form of a button!” No problem! Let’s add a property:

// CustomButton.js

import './CustomButton.css'

const CustomButton = ({ children, Component = 'button', className = '' }) => {
	const customClass = 'CustomButton' + className;
	return <Component className={customClass}>{children}</Component>
}

Example of use:

const linkCustomButton = (
	<CustomButton Component="a" href="https://google.com">
		Google.com
	</CustomButton>
);

Oops, "a" is an inline element. What’s the matter, you ask? The button looks the way it did. Not exactly! Imagine that users want to add space above the button:

// App.js

<CustomButton className="myCustomButton">Click it!</CustomButton>

/* App.css */

.myCustomButton {
	margin-top: 10px;
}

The inline element will ignore this margin.

That’s okay! We’ve been in worse jams than this. Let’s change the style of the button:

/* CustomButton.css */

.CustomButton {
	background: aquamarine;
	padding: 4px 12px;
	border: none;
	display: inline-block;
}

No, there is another problem, much more vile and intractable. Watch the hands! Imagine the following way of using a button in a project. Let’s say there is some kind of loading state, and if it is true, the button needs to be hidden:

// App.js

<CustomButton className={loading ? 'hidden' : ''} />

The problem is that .hidden and .CustomButton have the same weight, and they both claim the display property. This means that the CSS parser will have to figure out the winner while being guided by the order. The order is the last tier of the cascade. When your CSS files are broken into modules, you cannot rely on their specific order of appearance in the final bundle. As a result, this will lead to situations in which one or another selector wins. So, what do you do?

Layer to the Rescue

The cascade Layer is located exactly before the Specificity and Order:

1. Importance
2. Context
3. Layer (hi)
4. Specificity
5. Order

Layer allows you to flexibly set different levels of your style sheets. In our example, there may be three such levels (or maybe more):

1. A reset style sheet 
2. A library-style sheet 
3. An application-style sheet

Let’s set these levels.

@layer reset, library;

/* CustomButton.css */

@layer reset {
	.CustomButton {
		display: inline-block;
	}
}

@layer library {
	.CustomButton {
		background: aquamarine;
		padding: 4px 12px;
		border: none;
	}
}

But wait: we wanted to set three levels, yet we set only two. This is specific to the layer cascade. Anything defined outside of any level automatically becomes the highest priority. We don’t need library, too, but I used it for clarity.

It’s cool that all non-level styles win because users don’t have to wrap their overriding styles in some @layer app.

That is, this style will eventually override the one in @layer reset.

/* App.css */

.hidden {
	display: none;
}

Is it convenient? I think it’s just fantastic, largely because browsers still don’t have this cascade :-( 

Yet.