Avoiding inline CSS at all costs

inline-css-birds

Whether it’s through a WordPress theme option or a JavaScript function, front-end developers occasionally have to implement dynamic CSS code to a page.

For example, let’s say a clicking a menu toggle button switches a menu list between display: none; to display: block; states.

Or you want to automatically adjust WordPress theme column layouts based on widget area usage or have flexible footer widget columns.

While there’s always more than one way to skin a cat, that way should never involve inline CSS.

Clarification on terminology

There are three ways to include CSS on a web page: external CSS, internal CSS, and inline CSS.

External CSS

External CSS happens is when a stylesheet file is referenced in the head of the document. For example:


<link rel='stylesheet' href='https://themetry.com/wp-content/themes/markov/style.css' type='text/css' />

Internal CSS

This is when you include page-specific CSS directly in the head of the document. For example:


<style>
body:before {
	content: "I have some valid use cases, that Leland will discuss later in the article. :)";
}
</style>

Inline CSS (the bad one that you should never use)

This is when you apply CSS directly to the HTML element. For example:


<div style="font-size: 300%; color: red">This CSS can't be overridden without a hacky !important flag. ¯\_(ツ)_/¯</div>

Contrary to what you would expect considering the name of the function, wp_add_inline_style actually facilitates adding internal CSS to the page, not inline CSS.

Why not inline CSS?

1. No way to manipulate pseudoclasses.
2. Need an important flag to override.
3. If an !important flag is used inline, you need JavaScript to override. Barf.

While it technically works, there’s a reason why websites include the bulk of their CSS styles in external files and not inline CSS. Inline CSS is just not very flexible, even in very small doses.

Common “inline” use cases, and how to avoid

In almost every case, adding a body class is the best way to add dynamic styles. In others, especially when a “featured image” or custom color is involved, internal CSS is the logical choice.

The Menu Toggle

I can’t tell you how many times I’ve seen jQuery code written like this:


$( ".menu-toggle" ).click(function() {
  $( ".menu" ).toggle();
});

The jQuery toggle function essentially toggles the selected element between inline display: block; and display: none; states.

The problem with limiting the toggle functionality to a simple show/hide state goes back to flexibility. What if you want to do something else besides show/hide the menu? Would you add every toggled CSS style to the jQuery function? What if you’re making a WordPress theme and want to make sure your users can easily add their own menu toggle styles without writing JavaScript?

Toggling a body class instead would be vastly superior:


$( ".menu-toggle" ).click(function() {
  $( "body" ).toggleClass( "menu-toggled" );
});

From there you could write the following accompanying CSS to toggle the menu display:


.menu-toggled .menu {
	display: block;
}

Let’s say you also wanted to change the body background color to yellow. Just add the following:


.menu-toggled {
	background: yellow;
}

A totally random case, sure, but it demonstrates the flexibility of the technique. For both you and your theme users.

The Scroll Down Pop In

Have you ever scrolled down a page, and noticed different sections of the page seem to slide in from off screen?

If you peeked into your browser’s web development tools, you’ll probably notice there’s JavaScript manipulating the horizontal positioning in real time.

This too, is unnecessary.

Instead, set the initial positioning of the div off-page in your stylesheet, then trigger a class on the div once the user has scrolled to the trigger point. The trigger class will then set the position of the div to the desired point, using CSS transitions to mimic JavaScript live manipulating the positioning with inline CSS.

You may also want to provide a fallback so those that have JavaScript disabled can actually see things as if they were always in the “scrolled in” state, but that’s a whole other debate.

Featured Images and Header Background Images

This one I’m a bit more forgiving on, because when a user sets a featured image as a singular post’s header background image, it’s safe to assume they want to…use that image as a CSS background image.

Even still, there’s a better alternative, thanks to wp_add_inline_style().

An interesting example can be found in the Twenty Fifteen theme, which utilizes Featured Images in single post navigation.

Wrapping Up

To reiterate, there’s never a case for inline CSS.

You give me (what you think is) a surefire use case for inline CSS in WordPress themes, and I’ll give you a much more flexible alternative with either external or internal CSS.