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.