A different and almost cleaner way of accomplishing what the original article on gzipping your CSS set out to do.

The "official line" on this topic is being archived and updated here.

Alun Bestor mentioned in the comments of Organizing and Optimizing Your CSS - Some ideas something that, after a little testing, was worth a post of it's own.

Background information on this topic can be found in the original article, and subsequent articles [1], [2].

A more transparent gzip

With the goal of eliminating the need for placing PHP in a CSS file, Alun suggested using PHP's Zlib compression functions in combination with a little .htaccess file magic to clean things up. The following is lifted pretty much straight from his comment.

Note: Zlib support in PHP is not enabled by default, and this method assumes you keep all of your CSS files in one css-specific directory, and that PHP is installed as a module on your server.

Htaccess

The following code needs to be inserted into an htaccess file in the directory containing your CSS:

AddHandler application/x-httpd-php .css
php_flag zlib.output_compression On
php_value default_mimetype "text/css"

• The first line tells Apache to send all .css files to the PHP script handler.
• The second line tells PHP to use its built-in negotiated output compression automatically for every page it parses (No futzing around with manually starting output buffering).
• The third line tells PHP that it should send the files as text/css by default, NOT text/html (which it usually will.)

That's really about it. At this point you should, in theory, be sitting pretty, as they say. Doing it this way, you avoid having to have PHP code in your CSS file and having to name your CSS file with a PHP extension, both of which were necessary with the original method. This method is more - "Do it once, and forget about it".

But unfortunately there is a drawback.

Does it cache?

For some strange unknown reason, the method outlined above seems to prevent browsers from caching CSS files.

We tested on several local testing servers and a live server, and found that browsers consistently requested the CSS files for each page visited (and we learnt some useless yet interesting things about browsers and CSS file requests, which will be reported in a future post).

The solution

The solution, unfortunately, means sticking some PHP back into your css, more specifically the caching instructions:

<?php
header("Cache-Control:must-revalidate");
$offset = 60 * 60;
$ExpStr = "Expires:" . 
gmdate("D,d M Y H:i:s",time() + $offset) . " GMT";
header($ExpStr);
?>

Pop that in the top of your CSS and 'yer laughing.

Advantages/disadvantages

The major bonus of doing things this way is that your CSS file is delivered as a CSS file, extension and all.

If it weren't for the caching issue, this method would be sleek and simple, as you wouldn't even have to think about compressing the file, nor would you see any extra code hanging about in your CSS. If anyone can shed some light on a way around this caching problem, then please share! We're not too worried about it just yet, as we do use PHP in our CSS for other things, such as hiding longer comments in our CSS, however there will come a time when this isn't necessary, and the 'fire and forget' method would be handy.

Check out the blog categories for older content

• 9 Rules
• Application Programming Interfaces
• Blogging
• Contingency Design
• CSS
• Fiftyfoureleven
• General
• Link Wrap
• Marketing
• News, Rants and Ephemera
• Programming and Scripts
• Search Engines
• Web Development
• Widgets that Work
• Working on the Web

The latest from my personal website,
Mike Papageorge.com