Since WordPress version 3.3 it has been made a lot easier to load javascript and stylesheets mid-page.
Why would you want to do this in the first place?
Well a lot of plugins load their own CSS and Javascript files on the page and some of them do so at times when it’s not really necessary. As a plugin or theme developer if you are loading styles that only need to be loaded in certain cases (not on every single page), you want to avoid loading them when they are not needed.
If you’re not sure on which pages your scripts and styles will be needed, it presents a bit of a conundrum. This is a common problem for plugins that let a user add its functionality via a shortcode. Common examples are sliders, media players, galleries and forms.
The best way to load your scripts is to enqueue it with native functions WordPress provides. There are a number of advantages to this. For one, you can avoid scripts from being injected more than once, you can control where the script loads (in the head or in the footer) and it offers ways to deregister scripts and styles from loading altogether without resorting to hacks.
The problem with enqueueing used to be its inflexibility in relation to the load sequence of WordPress. Prior to WP 3.3 you had to enqueue your scripts and styles before the page content is constructed. While there were good methods for calling javascript mid-page and having it load in the footer, there were no palatable equivalents for loading CSS stylesheets. What you could do was:
1) Include the CSS on all pages 2) Rely on inline styles 3) Parse the page content for shortcodes before styles are enqueued and include your CSS with conditionals. 4) Use javascript to dynamically add your stylesheet to the head section
5) Set a postmeta field that is checked when a shortcode is added to a post and include a condition that loads your css if the postmeta field is present