menu

Pros and Cons of Using ExpressionEngine's Default Stylesheet Parser

May 09, 2011 by Brian Yuen

Tips

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 <code>&#123;path&#125; include variable, but EE <a href="http://expressionengine.com/user_guide/templates/globals/stylesheet.html">recommends</a> not using <code>{path} for stylesheets. The main reason&ndash; a very valid one&ndash; is that EE will attempt to read and parse any template included with the <code>&#123;path&#125; variable in order to see if there are any EE-specific tags that need rendering. The <code>{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&#39;t use it. There are several useful minimizing Add-Ons out there (we love <a href="http://johndwells.com/software/minimee">Minimee</a> 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 <code>&#123;stylesheet&#125; tag is appropriate, versus just a typical <code><link> include? Well, there&#39;s several things you might not know about the <code>&#123;stylesheet&#125; 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?

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 news 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"&#10;          type="text/css"&#10;          href="http://example.com/?css=site/site_css.v.1284506823"&#10;/>

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 <em>do</em> use <code>&#123;path&#125;, 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:

&#123;assign_variable:bcw_blue="#18a29b"&#125;

Then elsewhere in your stylesheet:

h2 &#123;&#10;   color: &#123;bcw_blue&#125;&#10;&#125;

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!