Tell me more ×
WordPress Answers is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.
up vote 13 down vote favorite
1

Normally in a plugin I would add styles using wp_enqueue_style. However, I am currently creating a plugin that only needs a few lines of CSS and I am wondering if it might be better to serve the styles inline to save a request. Obviously there are many advantages to using wp_enqueue_style, but are they worth the extra request for such a small piece of CSS? Is there any accepted 'best practice' in this area?

share|improve this question

2 Answers

up vote 13 down vote accepted

TL;DR; Enqueue

Using external stylesheet

  • PRO: All your styles are in one spot.
  • PRO: Reduces web page coding.
  • PRO: Easier to maintain the plugin.
  • PRO: Can use hooks to alter location of the file.
  • PRO: Can use hooks to unqueue the file.
  • PRO: Can use minify styles automatically.
  • CON: Might add extra HTPP request (can be overcome).

Using inline styles

  • PRO: Can directly see the style applied.
  • PRO: No extra HTTP requests.
  • CON: Can not use hooks to alter the styles.
  • CON: Can not use hooks to unqueue the styles.
  • CON: Can not minify styles at all.
  • CON: Need !important to override style

Normally I would say: Sure, if you are the only one using it, go ahead and do it inline. But you are talking about a plugin which means the code will be public so aim for extendibility. Right now you only have a few lines of styling:

  • CON: What if that few become more?
  • CON: What if someone extends your plugin?
  • CON: What if someone wants to alter it?
  • CON: What if someone searches for it in css files?
  • CON: What if someone wants to minify it automatically?

Therefore, enqueue. (Preferably Conditionally only if the plugin needs it.) The same applies to JavaScript. (But that should be included in the footer if possible.)

share|improve this answer
Is it okay to use inline styles on the backend? – bungeshea Jan 16 at 0:55
@bungeshea If someone is going to change your plugin, they might want to change the backend too right ;) Just make sure you only enqueue the script when on the backend. For example: function _your_enqueue( $hook ) can test $hook to see if your on your options page. Alternatively you can use current_screen() for simpler properties. The thing is, you ARE allowed to do this, but the general use is a plugin consists of a .php file for serverside code and may or may not have images, .js and .css files. – Derk-Jan Jan 16 at 1:07
1  
You note that the extra http request can be overcome - can you clarify this? – Dustin Jan 16 at 2:06
1  
You can't, but the user of the plugin can. There are several plugins and functions written to, just before the page is outputted, get ALL the enqueued styles and add them to a minified, combined file. No matter how many CSS files you add, the viewer will only see one. Same for javascript. However, this is in your case not your 'problem'. It's optimization that is not needed and imho, the extra HTTP request kinda falls short against all the PRO's. – Derk-Jan Jan 16 at 2:21
1  
About the last sentence - AFAIK styles should be output in the header not the footer – Mark Kaplun Jan 16 at 5:07
show 3 more comments
up vote 2 down vote

This is hard to answer and I am really not sure if there is an official answer.

I understand the sentiment about saving a request but inline style pretty much always wins. A theme or end user will have a hard time altering your CSS.

With that in mind, I think I'd do this in a publicly released plugin...

  1. if the CSS is absolutely critical to the functioning of the plugin, as is the case with slideshows, for example.

  2. Or, if I also included a filter in the plugin that allows the inline CSS to be altered or removed.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.