Best way to include CSS in plugins

Question

Some plugins include the CSS as a separate file whereas some output in head_css. Which one should be preferred? I think this should be given as a suggestion so that plugins are made better.

Answer 1

There is no black or white here. However, these are some general guidelines, which could be overridden in some contexts:

• For dynamically built CSS, add it to the head. You won't be able to use a reference to a file in these cases (well, it is actually possible, but in general, I'd say it doesn't make much sense and doesn't help readability and makes changing the file more complex).
• For long static CSS use a separate file. You might want the browser to cache the file.
• To ease edition of the CSS by non-developers (which represents 99% of the plugin users) having a separate file is a must. Anyway, the file can be added inline programatically, particularly, if the file is small (following the previous guideline).
• Prioritize performance decisions when it comes to CSS displayed to basic users. CSS displayed to admin users shouldn't be a big deal.
• Extending the previous guideline, splitting user/admin CSS, usually, makes sense.

Comments

Thanks pupi for the points. Since most of the plugins have a few lines of CSS, having a CSS text field in the plugin options and adding them to the head by overriding the head_css seems the best way, right?

---

Yes I'd agree that's the best way.

Another option: in some of my plugins I added an option whether to output the CSS at all, with the idea being you could copy the plugin CSS into your main CSS file so you don't need inline CSS on every page load, or a separate small CSS file.

---

Thanks Scott. That really helps.

---

> having a CSS text field in the plugin options and adding them to the head by overriding the head_css seems the best way

Actually, I'm kind of against of adding CSS through text fields. This is because:

  1. Code is getting mixed with data (OK, this is not a strong argument, I know, but I'd prefer to keep things separate)
  2. Related to the previous item, if I see there is an issue in how something is displayed, now it is not enough for me to look at the code but also I will need to review the options (of each plugin)
  3. In order to take advantage of an editor I would have to copy/paste the text to another more specialized editor (OK, this not a big deal, and probably it is even faster than uploading a file via FTP)
  4. You save one row per plugin in the invaluable ^options table. This not only (minimally) increases performance but also reduces memory usage as the CSS doesn't have to be read into the ^options array in each request
  5. You are not limited by the size of the content field of the ^options table which I believe has an 8k character limit just because of the CSS files

Most of the arguments are arguable or minor. Still, I couldn't find really strong arguments in favor of using the text field rather than saving time by not uploading files through FTP.

> I added an option whether to output the CSS at all

That's an interesting approach. A couple of years ago I thought on the 2.0 version of that approach :) Here goes the overcomplicated approach:
 * Creating a Performance module (or whatever you want to call it) that will have a single method that returns plain CSS or CSS file references.
 * The core would have a setting to merge CSS into one file (needing write access on the server, sadly)
 * Each plugin developer would register the CSS that can be merged by implementing the needed methods of the Performance module
 * The core will, in an on-demand basis (or when a plugin is enabled/disabled), re-merge all CSS if the setting is enabled
 * Plugins will have to check if the setting is enabled to decide if they output CSS or not
 * This could apply to JS as well. Or even taken a (long) step further with sprite images.

> commented 3 hours ago by Scott

Nice to see you again :)

---

Thanks Pupi for the valuable suggestions. Interestingly I was also thinking on the lines of your version 2.0 approach. I think that has a lot of scope and might be simple to implement too. I was thinking like adding all css to a MySQL table and another cronjob or MySQL event to update a common css file based on this. Not a nice approach in core but can be an easy plugin.

For your other points, I agree it is not friendly for the developer. But the downside of having seperate css files is the extra http request each user has to make and this has a high impact on page speed scores. That's the main concern in removing the extra css file per plugin.

---

My bad, I misread the “CSS text field” thing. Having it inside the options isn’t a good idea. If you need some user customisation then some limited options is fine (e.g. text colour) but a full CSS file is not very efficient.

You can have a regular CSS file then read the contents in PHP and output it. I do it in my chat plugin here: https://github.com/svivian/q2a-chat-room/blob/master/qa-chat-layer.php

---

Thanks Scott. That makes sense. But some plugins are really heavy in qa_options. Can you please tell a good upper limit for number of entries there which won't affect the performance?