One of the philosophies of plugin development that I believe in very strongly is that CSS should be kept simple and easy to override. Plugins are specifically built for functionality: they provide features that do not otherwise exist in WordPress (ecommerce, sliders, forums, etc). Themes are designed to control the visual appearance of WordPress websites. This, and quite a few other reasons are why I firmly believe that plugins should always limit the amount of CSS they include.
Ignoring the Functionality vs. Design debate for a moment, there are a lot of reasons to limit the amount of CSS in a plugin, and I’d like to walk through some of them.
The very first reason is that the more CSS included in a plugin, the more difficult it is to override that CSS. When plugins very tightly control the styling of their HTML elements, it is challenging for a user to modify the styling via their own CSS without completely disabling the CSS from the plugin.
I usually think of there being two main types of CSS in plugins: skeleton and pretty. The skeleton CSS simply ensures that the HTML markup of the plugin displays in the format it is supposed to. It ensures that form elements, buttons, etc, display properly. The pretty CSS, however, controls the visual aesthetics, such as gradients, shadows, font sizes, colors, etc, and it’s this “pretty” CSS that usually causes problems.
Imagine a plugin that outputs a lot of HTML and then imposes via vibrant purple colors and is used in a theme that uses much more subtle colors. You can easily see how the user may want to tone down the colors of the plugin to better match the rest of the site, but since the plugin uses very specific CSS, changing these colors is very difficult. The only way to do it well is to completely remove the CSS entirely, but then the user has a new problem: all of the skeleton CSS that controls the basic layout of the plugin’s elements is gone to, meaning the user has to rewrite all of the CSS.
The simpler the CSS, the easier it is for the user to tweak it to their needs and desires.
The second reason to write simple CSS is that it is much less likely to conflict with the styles of the theme or other active plugins. A plugin that uses simple CSS and has less rigid styling will be much more likely to adapt the styles of the theme well, whereas a plugin that tries to heavily style all of its output will have a much harder time adapting the styles of the theme.
A third reason to write simple CSS is for the developers that want to integrate support for your plugin in their themes. We all know that there are WooCommerce specific themes, themes that have built-in full support for bbPress, and themes that have included full support for many other popular plugins. The more CSS you write, the more difficult it is for developers to integrate support for your plugin in their themes.
A plugin with simple CSS can be styled relatively quickly by the theme developer, often times without evening needing to remove the default CSS. A plugin that has tons of CSS will be much more difficult for the theme developer to fully style, meaning it will take them more time and thus will be less likely to do it.
Another reason, which stems from all of the ones above, is support and ratings. A plugin that conflicts with a lot of themes due to heavy CSS will inherently receive bad ratings from users, most of the time because they assume it is the plugin’s fault (it may or may not be). Plugins with a lot of CSS will also get an exceptionally higher number of support tickets and lower ratings due to these CSS conflicts.
The question at this point is what to do about the plugins that need (or want) to include a lot of the “pretty” CSS for the users that just want a plugin-and-play solution that looks really good, regardless of the theme (assuming there aren’t conflicts)? I think the answer is very simple.
If your plugin includes a lot of CSS (only referring to the “pretty” CSS), then you should, without exception, provide an easy way for the CSS to be disabled.
Many plugins will include an option to disable the included CSS:
This option is great, but it causes a problem with plugins that provide lots of “pretty” CSS. When the CSS is disabled, it also disables all of the skeleton CSS that controls the primary layouts, meaning that the user then has to completely rewrite the base CSS as well, instead of just the pretty CSS.
The best option, if you are going to include a lot of CSS for pretty styles is to provide two options: one to disable skeleton CSS and one to disable pretty CSS.
While this is not an absolute list, here are a few guidelines I’d encourage you to follow when writing your plugin’s CSS (there are always exceptions):
- Provide only the basic CSS needed to ensure your layouts work correctly.
- Avoid writing lots of “pretty” CSS. Remember, themes are what are supposed to define the look and feel of a site.
- Never use !important declarations
- Always provide a means to disable the CSS (even if it’s just a hook in the code).
- Never define font sizes (except maybe % sizes) or font families in your plugin’s CSS.
- Always prefix your CSS classes and IDs
- Never target generic HTML elements with your CSS. Always explicitly target your plugin’s HTML.
- If you provide “pretty” CSS, always provide a way to disable it without disabling the skeleton CSS.
- Use subtle colors (gray scale are best) for generic HTML elements. These clash less with the majority of themes.
That’s a good explanation and set of guidelines.
One area where I would suggest adding a bit more CSS is called for is when a plugin displays images as decorations. It’s much nicer to place images as CSS backgrounds on an element than to place them with just HTML. That way the site can override those graphics easily with CSS only. I’m dealing with this now with a plugin that displays a set of credit card logos as an HTML img tag. In this case, the image doesn’t fit the needs of the site and can’t be easily overridden without altering the plugin.
As with your other suggestions, it all comes down to thinking about how the user might want to override what you’ve done and make that easy.
That’s a perfect example of an exception.
***** Never use !important declarations ***** PLEASE, for the love of all that is good and holy, do not use !important!!!!!!!!!!!!!!!!!!!!!
You nailed it: plugins are meant to add functionality, not style. I agree that sometimes plugins like to add some styling for things to make sense, but the absolute best option in my opinion (as a full-time web designer) is to make it easy for the user to not use the plugin stylesheet at all.
For example, a WordPress plugin that by default adds a preset stylesheet but allows the user to simply turn it off via the plugin’s options page.
I know I would rather sort through Dev Tools/Firebug and style things exactly how I want from there.
Gravity Forms are one of those plugins where the CSS is pretty hard to overwrite without using !important
It does provide a way to not load CSS but then you have to style every little detail. It also reveals fields that are supposed to be hidden which is weird
That’s a perfect example of a plugin that should have the skeleton and pretty disable options.
We’ve battled that line with Ninja Forms. In our first version we had far to much CSS and in the newest iteration we have just the essentials. Of course then if people have poorly designed themes we get a little grief for not have enough. Forms are one of those things that you just can’t account for every possibility. We opted to create an extension that helps people style their forms if they want.
I’ve linked to this to maybe help explain why made the decision for lighter CSS.
I really like the idea of doing base CSS and then providing extensions that make it pretty. Great idea!
Another option with plugin CSS is use add theme support
so you can wrap your CSS enqueue/admin stuff with
if(! current_theme_supports('my-cool-plugin')){
//load scripts
}
then all the theme author would have do is add a snippet like
function prefix_theme_support(){
add_theme_support('my-cool-plugni');
}
add_action('after_setup_theme', 'prefix_theme_support');
Thats actually something I’m surprised more authors of large plugins don’t use, theres also a required_if theme_supports function etc
That is a pretty slick idea, I like it
Hi Pippin, with regards to CSS, why is the option to disable CSS needed when you can override the EDD plugin CSS via overriding in your theme? https://easydigitaldownloads.com/docs/customizing-the-plugin-css/
It’s primarily for when people want to get rid of all of it.
I like the setup of the Contact Form 7 plugin in that there is a way to disable the includes stylesheet. Contact forms can then make use of form styles specified in the current theme’s stylesheet. It’s also possible to add CF7-specific styling, though I like having the same form styles throughout.