Site relative CSS linking

[NutritioN]

when I link to a CSS stylesheet a few folders up I use the format (../../css/main.css) for example. As the current build is for prototyping and not always online, I can't link to a css online to keep all links the same.

Is there a way for the import url link to work from the top down like (./css/main.css)? Is there a magic term that makes it work down from the siteroot rather than up from the active html page?

Cheers.

 

[SiriusB]

Would it not just be easier to alter the import link as necessary for testing purposes?

I myself tend to keep the css file in the same folder as the html so it doesn't matter where the files are when I am testing them. I just alter the link when I upload the site.

 

[Augmented]

Is there a way for the import url link to work from the top down like (./css/main.css)? Is there a magic term that makes it work down from the siteroot rather than up from the active html page?
Cheers.

Just a forward slash on its own: /foo/bar.css always points to http://hostname/foo/bar.css wherever you are in the site hierarchy..

 

[NutritioN]

This is a large project with the core css file being 74Kb ~3000lines. This is well written code although some could be stripped out as it's been in production for over a year

SiriusB: The location of this file is important; (at least) hundreds of pages refer to it. Originally we used a collection of smaller prototypes and worked as you recommended but we really need to pull it all together and make it easier to bolt pages on. There's only so much Find&Replace I can take before I crack.

Cheers for that Augmented, that should help. Does it work on and offline? Will test...

 

[Augmented]

This is a large project with the core css file being 74Kb ~3000lines. This is well written code although some could be stripped out as it's been in production for over a year

If you can't optimise further (better use of selectors, avoiding duplication, shorthand CSS etc.), you might like to consider gzipping the file and compressing the text before sending it to the user.

I usually achieve >60% filesize reduction using this method.

For example, in PHP, you would set your CSS file to be parsed as PHP and then prepend to all CSS files something akin to the following code:

function compress_css($buffer) {
	$buffer = preg_replace('!/\*[^*]*\*+([^/][^*]*\*+)*/!', '', $buffer);
	$buffer = str_replace(array("\r\n", "\r", "\n", "\t", '  ', '   '), '', $buffer);
	return $buffer;
}

header('Content-type: text/css; charset: UTF-8');
header('Cache-Control: must-revalidate');
$offset = 60 * 60 * 24 * 7;
$expstr = "Expires: " .gmdate('D, d M Y H:i:s', time() + $offset).' GMT';
header($expstr);
ob_start("compress_css");

[edit - sorry completely forgot to add this]
And in a .htaccess, for the gzipping:

<Files ~ "\.js$">
 php_flag  zlib.output_compression On
 php_value zlib.output_compression_level 1
</Files>

Naturally you need to balance the benefit against the additional processing overhead.

Does it work on and offline?

Yes, assuming you're testing on a local webserver you shouldn't have any troubles. Same rule applies to any link; "/" is an absolute path to the site root.

 

[NutritioN]

I know NOTHING about php, and our resident CSS expert is not a php person either. I'm more of an artist than a coder, so is he except he's great at making solid efficient code. So that [ code ] gibberish made my head explode, so thanks I understand the logic, but surely once the 7 CSS files have been cached (total 100Kb) length isn't an issue? Or is what you're suggesting compressing it in memory speeding up every access even once it's cached locally?

And when you say local webserver, I test locally (e.g. right from a desktop file) then uploaded to a remote host for it to be accessed by the rest of the people on the project, (the remote test.)

Thanks.

 

[SiriusB]

3000 lines of CSS

That's madness! I am very new to CSS but even so, to me it sounds a little excessive. It would appear you are writing rules for pretty much everything!

Surely you can optimise it further :s

 

[Augmented]

I understand the logic, but surely once the 7 CSS files have been cached (total 100Kb) length isn't an issue?

Yes, that's right. But each user has to get to the point where they can cache 100KB of stylesheets first. This is about transporting the files to the end user in the most efficient way possible.

74KB spread over 7 stylesheets rings warning bells for me. Makes complete sense while developing, but not when delivering to the end user. You don't want a new browser sitting around waiting for the site to load (even with a majority on broadband), you want to get them viewing the site as soon as possible before they decide to click away. Plus there's a significant benefit in bandwidth reduction, e.g.

100,000 uniques/mo @ 74KB = ~7GB transferred
100,000 uniques/mo @ ~20KB = ~2GB transferred

As I say, you need to balance the benefit against the additional processing overhead. If bandwidth and load-times aren't an issue, then it's not something that needs taking into consideration .

 

[SiriusB]

Surely having such a massive Style Sheet would cause its own problems down the road. Some software isn't that big!

As Augmented has said loading times are very important. If someone has to wait, even for a short time, they are very likely to just click the Back button and move on.

 

[xiphrex]

If you can't optimise further (better use of selectors, avoiding duplication, shorthand CSS etc.), you might like to consider gzipping the file and compressing the text before sending it to the user.

I usually achieve >60% filesize reduction using this method.

For example, in PHP, you would set your CSS file to be parsed as PHP and then prepend to all CSS files something akin to the following code:

function compress_css($buffer) {
	$buffer = preg_replace('!/\*[^*]*\*+([^/][^*]*\*+)*/!', '', $buffer);
	$buffer = str_replace(array("\r\n", "\r", "\n", "\t", '  ', '   '), '', $buffer);
	return $buffer;
}

header('Content-type: text/css; charset: UTF-8');
header('Cache-Control: must-revalidate');
$offset = 60 * 60 * 24 * 7;
$expstr = "Expires: " .gmdate('D, d M Y H:i:s', time() + $offset).' GMT';
header($expstr);
ob_start("compress_css");

Naturally you need to balance the benefit against the additional processing overhead.


Yes, assuming you're testing on a local webserver you shouldn't have any troubles. Same rule applies to any link; "/" is an absolute path to the site root.

So this compresses the css file before sending it to the user? Is it still readable if you access it directly?

 

[Augmented]

So this compresses the css file before sending it to the user?

Yes. It compresses in two different ways. The first is to strip out all extraneous whitespace (1 space character = 1 byte etc.) and comments, so:

/* Style for #foo */
#foo {
color: #fff;
background-color: red;}

#foo.bar {
color: red;}

is output like:

#foo {color: #fff;background-color: red;}#foo.bar {color:red;}

And then it sends it using gzip compression if the browser supports it (most do). This is what provides most of the actual compression.

Is it still readable if you access it directly?

Yes, just it'll all be squashed together on one line as above. If you don't want that, remove the ob_start("compress_css"); line.

 

[NutritioN]

100,000 uniques/mo @ 74KB = ~7GB transferred
100,000 uniques/mo @ ~20KB = ~2GB transferred

Interesting :0

To be honest I'm not sure what form the CSS will take when it's released. It's 7 files now, two can be disregarded as they are for test templates, two others are IE fixes, one extra IE7 fix file but the core two are the main one and a print one. So they will get combined and reduced in the future.

Thing is it's a large government website (that doesn't exist yet) to have 10s if not 100s of thousands of pages of content. The CSS is built up of the definitions for 40 components and everything has to be specified for every eventuality. When there's 24 lines just for the footer (empty lines taken out) you can the scale of the code. I think. The file is expanded and easy to read at the moment, maybe that's why it's huge... Is there a program that formats css for small file sizes without php?

#footer {
	background: #fff url(../images/bg.gif) repeat-x left top ;
	padding: 6px 0 30px 0 ;
	height: 1% ;
	margin: 5px 0 10px 0 ;
}
#footer a {
	font: 0.65em/1.1 Tahoma, Arial, Helvetica, sans-serif ;
	color: #2559b0 ;
	text-decoration: none ;
	display: block ;
	padding: 1px 5px ;
	border-right: 1px solid #c8c8c8 ;
}
#footer a:hover {
	background: #F4EA94 ;
}
#footer ul {
	list-style: none ;
}
#footer li {
	float: left ;
}
#footer li.last a {
	border: none ;
}

 

[NutritioN]

Back to the CSS linking

What Augmented suggested works online, on a server; but it won't work offline on an operating system. Or does it? Where does it go back to? to the root of the harddrive? Where's that on a Mac?

Think I might stick to variations of url(../../../../../css) etc Hope this site still works when it gets built dynamically by the database.