I'm making this a separate post so we don't keep threadjacking this thread here.

Code-tard is just discovering the advantages of external stylesheets, so I thought it might be useful to folks if I explained the advantages. I'm also going to explain my conclusions and reasoning for sitebuilding, since I know a lot of my heavy handed authoritative statements confuse people.

If nothing else someone might find my rambling useful.

I'm putting this in HTML because I'm going to end up touching on that as well, and to be frank CSS is only as good as the markup it's applied to... and generally speaking, this first post is going to be about the STYLE tag, STYLE attribute, and LINK attribute. THOSE ARE HTML, even if you are providing CSS with them!

You are going to find me using terms like "generally speaking" and "rule of thumb" -- this is because while the below may be good practice, you have to allow for exceptions; at the same time because there are exceptions that doesn't mean you should ignore good practices on everything else... and when I DO mean the rule is in concrete, I'll bloody well say so.


When it comes to the application of CSS, the advantages of an external stylesheet are simple:

1) It's separation of presentation from content. Keeping what things are SEPARATE from what they look like. What things look like as a rule of thumb has no business in the markup. As I often say, if you choose your tags based on your default appearance, you're choosing the wrong tags for the wrong reason.

This separation also means that you can edit things side-by-side. Even at the earliest development stages having your markup and your style separate in separate editor windows makes development faster and easier -- and it saves you the time of trying to extract it later; which a lot of people who use the style attribute CLAIM they are going to do, but never actually do it.

2) Multiple presentations -- by including differnent files using the MEDIA attribute, you can target different devices. This is why using a stylesheet LINK without the MEDIA attribute is stupid, and using the "all" value is even dumber. There are all sorts of targets for media, and most often the one you want is SCREEN, PROJECTION and TV -- Screen is your normal devices you think of when you design, some kiosks and browsers in full-screen operation ignore screen using projection, or will use a mix of the two; and sadly, there are still some devices that report themselves as TV, and if you don't say TV they'll override your settings with their own. (The version of Opera on the Wii is a great example, as is the now semi-defunct MSN-TV).

Naturally this is the point where some jacktard will say "who cares about those" -- when it's basically including an extra 15 characters to support them, are you really such a lazy foxtrot you can't be bothered? Whiskey tango foxtrot!

Ask yourself this, does your for screen layout and design elements make ANY sense to be sent to print? How about Aural? Media targets exist to customize appearance for targets AND to prevent values that are just screwy from being sent to the wrong devices.

Now ask this -- how exactly do you do that with the STYLE attribute. How do you put a media attribute on another attribute? So much for STYLE as an attribute.

These first two reasons also combine that you can easily have multiple appearances off the same markup; meaning SKINS -- reskin an entire site without even touching the markup? Oorah!

3) Caching. Even if it's just a single page, what if people visit it more than once? You really want return visitors re-downloading the same data over and over again for no reason? This more than any other reason is why the STYLE tag is pointless.

The laugh is things like Google pagespeed are suggesting putting some style back in the markup -- the only situation that would pay ANY benefits in speed or efficiency is if your traffic is all bounce -- a situation I thought we were supposed to be avoiding -- much less that if you're going to have an external sheet anyways, what difference does it make if it's in that or the HTML apart from the HTML not being cached. That's just stupid advice on the part of Google Pagespeed.

4) pre-caching -- if you put the CSS of sub-pages in the same monolithic file for each media target, you are effectively pre-loading the appearance of those pages -- so those sub-pages load AND render faster. Now, the peanut gallery will chime in with "doesn't that make the first-load take longer" -- really if you have enough CSS for all your pages that doing this results in any noticeable difference, you don't know how you use CSS properly.

Generally speaking in all but the rarest of cases, UNCOMPRESSED there is no excuse for even the largest of site templates -- like those of a forums -- to break 48k (and a third that gzipped) other than developer ineptitude, a failure to grasp how to use selectors or HTML, or just plain code bloat garbage like frameworks.

This is another area where people screw up -- first by trying to use tools to "remove unused CSS" that often removes CSS used by subpages just because it's not used on the main page. Then they run around like chickens with their heads cut off that the subpages are screwed up.

Likewise they blindly trust tools like Google Pagespeed when it *****es about "unused css" when their tool doesn't go deep enough into the site for it to even know. More than once I've had to clean up after site owners who blinding followed the advice of tools like that, and gone and completely boned things like forum softwares.


All the above reasons are why (and this is set in concrete) I see no legitimate reason to EVER use the STYLE tag, even in testing. PERIOD. It's just sloppy coding and making more work for yourself later if you take the time to clean things up. It's why whenever I see it in someones markup, I generally conclude they don't know what they are doing.

The STYLE attribute on the other hand there are a handful of corner cases where it does serve a purpose -- and those cases are for when you are actually using style to convey content. Not using the STYLE attribute is one of those 'rules of thumb' -- there ARE legitimate reasons to use it.

Now you might be thinking, "how can style convey content?" -- what about a tag cloud? Sure you could set several levels of classes and set it by class, but that's as big a waste of code on 'font sizes' that likely aren't even going to be static from page to page.

Another great example might be a bar graph. Czech this out:

<div class="graphBar">
	<span><b style="width:60%"></b></span>
<!-- .graphBar --></div>

<div class="graphBar">
	<span><b style="width:30%"></b></span>

<div class="graphBar">
	<span><b style="width:80%"></b></span>
with this CSS:

.graphBar {

.graphBar span {
	border:0.15em solid #008;

.graphBar b {
That uses width to convey content. NOTE I still use a text equivalent as you should NEVER rely on visual appearance to convey content unless that's what the content IS (like an image or a video)... still doesn't mean it's no useful to do it -- just have a backup plan.

But unless you're doing something along those lines, just say no to using the STYLE attribute. It's a crutch at worst, disastrously inefficient at best for the majority of usage scenarios.

That's why 99% of the CSS people make, should be included thus:

... and NOT in the markup! EVEN during testing and construction.

Not putting it in the markup can pay other benefits -- like faster running server side code. Now, you might be thinking, how can not having style in the markup make the server code faster?

Simple: it's less code for the server to process. If style is in a static file, you don't have to process it in your server-side language -- like in your PHP. ANYTHING you put in PHP -- even stuff outside <?php ?> still has to be parsed by the PHP engine, a waste of time, and waste of memory. Smaller markup == less work for your server side code. It also makes it easier to maintain your server side code as there will be less of it as a result... Playing to a rule I learned decades ago about programming:

The less code you use, the less there is to break!

It also means that if need be, you can alleviate the server load by offloading static files to a 'lightweight' server process on a subdomain, a dedicated separate static server, or even a CDN. You can't offload what's in your PHP/ASP/PERL/whatever to another server or domain!

I'm going to write up a follow up post to this one explaining a number of other things about HTML and CSS and practicing things like separation of presentation from content, progressive enhancement, semantic markup and so forth. There's a lot of disinformation and outright lies being spread about those, mostly as lame excuses by the people who don't practice them... Time to shoot those excuses full of holes.

Though if you're interested in seeing some of the classic lame excuses shot down, I highly recommend this article:

Seven years old, and just as applicable today as it was then!