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

> 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?