Do block themes still need style.css? - WP Development Courses

The style.css file has been a cornerstone of WordPress theme development. Traditionally, this is the stylesheet where you place all the styling rules for the theme.

But with the introduction of block themes, the role of style.css has changed:

Twenty-One was the last default theme built using classic theme development approaches. Its main stylesheet contains close to 6,000 lines of CSS.
The Twenty Twenty-Two theme was the first block-based default theme, and its style.css file contains less than 200 lines.
The Twenty Twenty-Three and more recent block themes have no CSS in style.css anymore.

This evolution prompts a crucial question: do WordPress block themes still need style.css?

In this article, we’re going to look at:

style.css is not only for styles
The downsides of legacy CSS styling approaches
Modern styling alternatives combining CSS and theme.json
- Implementing site-wide styles
- Implementing bock specific styles
Conclusion

`style.css` is not only for styles

Even though modern block themes don’t use style.css for styling anymore, they still need it. This is because WordPress uses this file to store crucial theme information that it relies on.

So, the file is still present in the theme. However, it is empty except for the theme headers. The file is also not queued on the front end or the back end. As long as it is present in the theme directory, WordPress can find it and extract the necessary information.

The downsides of legacy CSS styling approaches

A major advantage of block themes is their efficiency in delivering the relevant CSS styles optimally—all without any additional effort on the developer’s end. These themes represent the styling practices of the modern web.

style.css, on the other hand, represents the best practices of the days past. Let’s look at these and why they are no longer adequate.

The first issue with style.css is that it contains the CSS for the entire theme. And this file is enqueued on every single page.

This was because back in the day to best practice was to minimize the number of requests. So it was considered optimal to take all styles, and put it in one big file. This file, once loaded, was then cached by the browser.

However, modern browsers are much more efficient at handling external resources like stylesheets or JavaScript files. So, the best practice is still to load as few files as possible, of course, keeping those files as small as possible.

Putting everything into one main stylesheet can lead to two performance issues. The first is loading unused CSS, and the second is chaining critical requests.

This brings us to issue number two, which is how the style.css file is included. If you use the wp_enqueue_style function, this will add the external stylesheet to the <head>of the document.

Stylesheets added this way are render-blocking. A browser parses HTML from the first to the last line. Whenever it encounters <link> tags referencing CSS files, it must fetch and parse these CSS files before it can continue constructing the render tree, which is necessary for painting the visual content on the screen.

During this process, the browser pauses the rendering of the webpage until the CSS files are fully downloaded and parsed. This is because CSS rules can affect the layout and style of the page, so the browser needs to know these rules before it can render the content correctly.

This has a negative impact not only on user perception, as they might perceive the site as slow to load. But also on key performance metrics for SEO rankings like First Contentful Paint and Largest Contentful Paint. Therefore, removing render-blocking resources is one of the key performance improvements you can make.

The third and last issue concerns the editor’s user experience. The style.css only styles the user-facing part of the website. Therefore, default themes have traditionally needed dedicated stylesheets for the editor.

Since these were separate, standalone stylesheets, having any or even a good editor style on custom websites was rare. But between the limited capabilities of the TinyMCE text editor and the meta box-heavy building approaches, that didn’t matter.

In today’s WordPress, the editor looks like the front end. Our clients expect this, and it’s also a requirement. Any styling done in style.css also needs to work in the editor.

While WordPress’s editor style injection through add_editor_style() can achieve decent results, it will never be perfect. This leads to having to enqueue additional styles on top. And we’re back to maintaining different stylesheets, one for the frontend and one for the backend. A work-intensive approach that can result in both experiences drifting apart.

Modern styling alternatives combining CSS and theme.json

The best method of styling blocks is the Global Settings and Styles feature. Not only can you create most of these styles using the builtin Styles interface. But WordPress also ensures that the correct CSS are generated and injected in the most efficient way. Both on the frontend and the backend.

This is not only the case for default block styles. Block style variations, more commonly known as block styles, are now also part of the theme.json feature set. Implementing block styles was a common use case for CSS in block themes.

But what if you still need CSS? There are two use cases.

Implementing site-wide styles

Site-wide CSS applies site-wide to every page and every editor. In this case, you have two options.

First, you can use the enqueue_block_assets hook. This hook fires both on the front end and in admin on screens that use the block editor, allowing the sharing of styles between the front and back end.

Unfortunately the stylesheets enqueued this way are still render-blocking. So, in terms of performance, it’s still not optimal. That being said, you should be able to keep CSS in this file to a minimum and, therefore, need to have too much of a performance hit.

The other aspect is that the CSS enqueued this way should be standalone. Avoid using this stylesheet as a dependency or adding dependencies to it.

So, the second approach is to use theme.json. This avoids having to load an external stylesheet.

{
	"version": 3,
	"styles": {
		"css": "..."
	}
}Code language: JSON / JSON with Comments (json)

Since the CSS is all in one string, this only applies to minimal styles. These styles are added to the frontend of the website in a <style> tag.

Implementing bock specific styles

Styles that apply to a specific block type can be implemented in two ways.

The first is using the css key we saw before, but scope to a block selector. You can see this in use in the Twenty Twenty-Four theme:

"core/query-title": {
    "css": "& span {font-style: italic;}"
}Code language: JavaScript (javascript)

Again this only makes sense for small snippets.

The other option is to use wp_enqueue_block_style. This function has two key differences to other enqueueing functions:

First it only loads the stylesheets for blocks that are displayed on the page.
Second, WordPress inlines CSS files below a specific size.

This way you can both avoid serving unused CSS, and remove the need to load an external stylesheet.

Conclusion

Block themes are more than just about editors. They are WordPress’ response to the modern challenges of web performance.

But block themes speed up not only your website but also your building process. Many of the things we needed to do in the past are not needed anymore. So say goodbye to needing a CSS build process, or having to maintain separate editor stylesheets.

And if you are interested in a high-performing WordPress website, don’t forget to optimize your images for block themes.

Table of Contents

style.css is not only for styles