Pros and Cons for Using ExpressionEngine’s Default Stylesheet Parser
If you reference the official User Guide while building an ExpressionEngine site, you will probably end up using the {stylesheet} tag to include a reference to your CSS file in the page head. The tag functions very similar to the {path} include variable, but EE recommends not using {path} for stylesheets. The main reason– a very valid one– is that EE will attempt to read and parse any template included with the {path} variable in order to see if there are any EE-specific tags that need rendering. The {stylesheet} variable bypasses this extra parsing, thus saving time when loading your page as it doesn't have to read through your code.
But that's where the documentation ends. There is no other explanation of how the {stylesheet} tag works, or why you would or wouldn't use it. There are several useful minimizing Add-Ons out there (we love Minimee here) which can save precious bandwidth and load times by stripping out comments & whitespace from your nicely formatted stylesheet. What are the times when the {stylesheet} tag is appropriate, versus just a typical <link> include? Well, there's several things you might not know about the {stylesheet} tag, and they can help you decide the best way to reference your CSS.
Do you really trust your client to edit live CSS code?
The whole point of using ExpressionEngine, or any CMS, is to let the client edit their content. It's great to use something like Structure to comb out the editable stuff from the technical gibberish for non-tech-savvy clients. But the "default" use case of EE allows you to place all types of files that make a website run into an editable form.
You'll notice when you create a new template that you can define several different file types other than HTML. CSS is one of those, as is JavaScript, RSS, XML, etc. The idea here is that if you keep all your files in the scope of EE's template framework, the client can access all of them and will be able to edit them in-browser from any computer.
That's great if your client has a dedicated developer who will be managing the site, as they can monkey around with the scripts and styles to make changes in the future, and you don't have to necessarily give site root access to the users (in the event you are hosting the site yourself on a shared environment). However, with that benefit comes a risk... someone other than you is monkeying around with live JavaScripts and styles that make the site work.
So that's one pro (and one con) to using EE's {stylesheet} tag... keeping a CSS file in the EE template framework lets you grant EE members access to edit it, whether they have (S)FTP access to the site or not.
The cold, hard cache
One issue that can be frustrating is busting your CSS out of the browser cache when making style changes. Web browsers by default like to cache CSS and JS files in order to improve load times. The original thinking behind this is a stylesheet or script file will usually be applied globally sitewide, and changes much less often than the content does. Therefore, if the browser can download and save those files the first time it visits the site, it doesn't have to re-ask the server for the file each time it visits.
The downside to this is obviously when you have made changes to the stylesheet. You actually want the browser to re-download the file since there's a new version, but if the filename hasn't changed (it's still style.css or something similar), the browser assumes it's the old version it already has, and will instead apply its cached version instead.
Most developers have learned to circumvent this by doing a hard refresh while previewing changes, which means the browser asks the server for a new copy of the stylesheet regardless of filename and page cache. But your average client probably won't do this; you might have fixed a CSS issue, but when asking them to view it, they still see a problem because they haven't downloaded the latest version.
There is a simple fix... append a unique string (usually a timestamp) to the stylesheet path. And guess what? EE's native parser does just that.
<link rel="stylesheet"
type="text/css"
href="http://example.com/?css=site/site_css.v.1284506823"
/>
Chalk another one up to EE's stylesheet parser. You can always do this yourself fairly easily with a basic knowledge of php, but it's a very nice out of the box feature of EE. It's too bad they don't advertise this feature more prominently.
In ur CSS, parsing ur variables
Earlier it was mentioned that EE doesn't recommend using the {path} tag for stylesheets because it takes time to read and parse the file. The flip side to this is that if you do use {path}, EE will parse your stylesheet, and therefore you can use EE variables! How many times have you wished you could create some global arguments that you could pepper throughout your styles (*cough...HEX codes...cough*)? There are some proprietary CSS languages out there that do just that, but they come with their own learning curve and development process. You already (hopefully) know EE, so why not just set some global variables to re-use inside your stylesheet? It's easy:
{assign_variable:bcw_blue="#18a29b"}
Then elsewhere in your stylesheet:
h2 {
color: {bcw_blue}
}
Remember, just like any EE tag, this will add some load times to your pages, so you don't want to go too crazy. However, it can be a great time saver, and can make long tedious changes much faster.
Above all, size matters
All of the above benefits can be nice during site development and changes, but once your CSS is up and running in a working environment, that stuff doesn't matter as much, and you want the file size as small as possible. At BCW, we've tried many different methods of embedding our CSS, but we always seem to fall back into keeping our CSS and JavaScripts outside the EE environment, and then run Minimee to cache & compress the heck out of them on our page. This means we can keep and maintain a nicely formatted & commented stylesheet (that we don't have to export to a mimizer for every tiny change), and organize our script includes in the header on separate lines for keeping tabs on the firing order and ease of editing.
We don't typically launch a site by making everything editable, handing over the keys, and running away, so dividing up the "content" of the page for EE members to manage and then the guts of the site managed by an (S)FTP user is our preferred method. The techies don't need to muddle around in ExpressionEngine to make a code change, and click-happy content managers don't need to worry about blowing away any vital organs of the site.
You'll find a method that works best for your projects, and based on some of the above points, hopefully there's a little more light shed on that mysterious {stylesheet} tag. Knowledge is the best web development skill of all, so use what's best for your use case and clients!
Here's what other people had to say
If they’re not a qualified dev, I’m sorry but they are not getting access to the templates or most of the admin. Or, at the very least a stern warning that if they go into the templates and screw it up I’m doubling my price to fix it 
There’s definitely a bit (okay, a lot) of trust when granting certain privileges to EE client editors… I think I do sleep a little better at night knowing the content is the only thing that’s easily accessible and editable.
When I give a client a superAdmin type membership I make it clear it’s only to be used in case of emergency and if they can’t find me. Only by someone that knows EE, even if they have to call EllisLab to find someone.
PXLated, do you manage hosting for client sites? Have you ever received any resistance from clients for delivering “restricted” accounts? Do you typically maintain sites post-launch? Just curious!
I set them up with hosting (usually EngineHosting) but I wouldn’t describe it as managing hosting - Could you clarify that? Or, in cases where they have a tech dept., they might host their own but then, they have geeks.
I’ve never had any resistance to restricted accounts for normal use. But, as I mentioned, I may give them a superAdmin account/password for emergency use - Like if I got run over by the garbage truck. But if I do set that up it’s with stern warnings and no explanation of what they will find if they log into that account. It’s so they can give that to another EE dev to take over.
I try to set up sites so the client can run them themselves without me involved unless they want to add something entirely new. I try to set them up so they’re bullet-proof and can’t be screwed up. I try to not even incorporate a WYSIWYG editor if at all possible.
Thanks for the info… always nice to hear other EE developer practices in terms of passing off the site to a client.
May 10, 2011 3:07 pm
I also try to use all native code - limited add-ons - whenever possible. Agree with Boyink on this—http://boyink.com/write/on-using-expressionengine-add-ons/
May 11, 2011 3:28 am
thanks for the post Ryan, I must admit it’s refreshing to hear such honest feedback, I know it can be difficult at time sto get the balance right between access rights and damage limitation.
By the way, the timestamp string that the {stylesheet} tag appends to the CSS path isn’t the current server timestamp or anything as simplistic; it’s the timestamp when that CSS template was last modified. I wish there was some way use the last modified timestamp of a template along with the {path} method… *sigh*
June 26, 2011 11:29 am
fantastic site:)
October 13, 2011 8:57 pm
Great coommn sense here. Wish I’d thought of that.
Hi, i am an EE newbie, and therefore my knowledge is a bit shallow, i am having a problem, i am trying create a page with rotating background images, in my markup i have something like this
<ul id="backgrounds">
<li id="background1"></li>
<li id="background2"></li>
<li id="background3"></li>
</ul>
now my question is, is there a way i can lets say use the swith tag to list them? if yes how do i do it? another problem is since those list ids are all declared in my css which looks like this
/* background rotating images on the homepage */
#background-1 {background:url(images/slides/slide1.jpg) no-repeat 50% 0; z-index:-2999}
#background-2 {background:url(images/slides/slide2.jpg) no-repeat 50% 0; z-index:-2998}
#background-3 {background:url(images/slides/slide3.jpg) no-repeat 50% 0; z-index:-2997}
/*ends here */
is there a way i can use EE tags to declare these css classes/ids? Please help
Zachariah: You should ask on the EE forums; you’re far more likely to get help there. 
May 16, 2012 7:42 pm
I’m not comfortable with having ExpressionEngine’s client editors having full access to anything that significant that’ll take a big swerve of the site if mishandled horribly. But EE has done a marvelous job for my site.
