Class "clear", pros/cons?

[YuriKolovsky]

Today I was told by a client that my method of writing HTML & CSS is very complicated, and that he prefers the method used by the joomla template guys at rockettheme, the problem here is that I am under the impression that all the books and all the articles that I read about CSS tell me to write CSS in the following manner:

1. Assign id's and classes to elements on the page, where each class is a group for certain types of elements
2. Assign styles to the elements using their id's and classes.

Simple, right?

Now the client suggests to use a different method, where you:

1. Assign visual styles to certain classes.
2. Give elements these classes.

Here is a simplified example using the clients suggested idea:

.box1 {
  background:red;
}
.box2 {
  background:green;
}
.box3 {
  background:blue;
}
.title1 h3 {
  background:black;
  color:white;
}
.title2 h3 {
  background:white;
  color:black;
}
.title3 h3 {
  background:orange;
  color:white;
}

Using this CSS the client can have up to 9 different boxes!

<div class="box1 title1">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box1 title2">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box1 title3">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box2 title1">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box2 title2">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box2 title3">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box3 title1">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box3 title2">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box3 title3">
<h3>some heading</h3>
<p>some text</p>
</div>

To do the same using my method, to add more boxed you need to edit more CSS and is generally harder to work with and modify he argues.

.box1,
.box4,
.box7 {
  background:red;
}
.box1 h3,
.box4 h3,
.box7 h3 {
  background:black;
  color:white;
}
.box2,
.box5,
.box8 {
  background:green;
}
.box2 h3,
.box5 h3,
.box8 h3 {
  background:white;
  color:black;
}
.box3,
.box6,
.box9 {
  background:blue;
}
.box3 h3,
.box6 h3,
.box9 h3 {
  background:orange;
  color:white;
}

<div class="box1">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box2">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box3">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box4">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box5">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box6">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box7">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box8">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box9">
<h3>some heading</h3>
<p>some text</p>
</div>

While I argue that his method means that to edit a box, he would need to edit all of the boxes that need to be changed on all the pages, he says that it's not a problem because server side scripting handles that.

So considering my method is indeed longer, , and while my clients method really looks like the very commonly seen "clear" class or the "clear-right" class that clears an element, and seems similar to the "redbg","bluebg" classes, I could not make any good arguments for my method or convince him that it was wrong to have classes like "clear".

Could someone help me understand if the clients method has any major drawbacks or benefits or is his way of writing CSS better than mine?
So that I can decide what kind of CSS to continue writing.

[dresden_phoenix]

Now the client suggests to use a different method, where you:

1. Assign visual styles to certain classes.
2. Give elements these classes.

This si a problem witht he client , not you. Unfortunatley many clients assess code by seeing the end product ONLY ( i.e.: how 'it looks or feels'). So for them "left-column" and "right-top-sidebar" is far more understandable than "main" and "secondary".

Also that is the problem with using rebuilt templates, they may have some member of their team who is an expert not with proper coding techniques but with styling THAT SPECIFIC Joomla! template. S/he may not know much about code and as such depends on what he expects the template to output.

It's also possible s/he is prepossessing CSS with SASS or the like.

In short, the client want to be able to check your work w/o having an understanding of coding. If that's a sacrifice the client wants to make.. it's one of the pitfalls of the biz.

[Stevie D]

It really depends on what the purpose of the styling is, and how interdependent the different declarations are, as to what method is more sensible.

In the example you've given, I think that "his" way is probably more appropriate. If you are always going to have consistency across rows (assuming it's designed to be a 3×3 grid, that's what it looks like!) and down the columns, it makes sense to abstract those properties and group them that way. Then if you decide that you want to change one row from green to #060 then you only need to change it once for the whole set. (This is where defining colour names would be such a helpful addition to the CSS spec, but it seems to be a pipe dream at the moment*).

On the other hand, if it's just coincidence that in the current design you want those items to share a property, but they could just as easily be different, then I would prefer "your" method. I try to minimise the use of multiple classes myself – there are times when it's the best way of doing things but often it just ends up complicating things more, and you end up introducing loads and loads of presentational classes into the HTML.

So, what's so bad about presentational classes? The whole point about HTML is to say what the content is and what it does. It's a heading (<h1>), it's an introduction paragraph (<p class="intro">), it's emphasised text (<em>), it's the <div> that gives the event venue details (<div id="venue">), it's an image that is a user's avatar (<img class="avatar">) and so on. The element, class and ID names all relate to the item's purpose on the page. That makes it easier to find what you're looking for in the HTML and CSS, because everything has a meaningful name (and of course "box1" wouldn't fit that bill very well either). If you label things as class="red", class="blue_bckgrnd", class="right" and so on ... what happens when you want to change something? You either have to hunt down each and every item on each and every page and give it a new label, or you end up with something really stupid like

.red {color:blue;}

which might come across as mildly amusing now, but when you're trying to debug or change things next time round, you're going to be pulling your hair out as you try to remember which colours/design features in the HTML match up with different colours/design features in the styling.

Off Topic:

* What I mean by that would be the option to set out the basic colours for your site once and then refer to them by name/code throughout the stylesheet. So you could have something like:

define-color["headings"] {color:#060;}
define-color["subtle"] {color:#afa;}
 
h1 {font-size:2em; color:"headings";}
h2 {font-size:1.5em; color:"headings";}
#footer {font-size:0.8em; color:"subtle";}

and then if you wanted to change the colour theme for the whole site you wouldn't need to worry about hunting down every last reference to #060 because you would just need to change it once. Not that I expect to see it happen

[Paul O'B]

Here is a simplified example using the clients suggested idea:


Using this CSS the client can have up to 9 different boxes!

<div class="box1 title1">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box1 title2">
<h3>some heading</h3>
<p>some text</p>
</div>

<div class="box1 title3">
<h3>some heading</h3>
<p>some text</p>
</div>

Actually, I code a lot of pages like that where you use the main class for the common elements and then just modify it with a secondary class where necessary.

The class names should never be presentational but probably not as abstract as .box and .title1. Maybe the box1 could be more descriptive (e.g. .main) and the .title class changed perhaps to reflect why the colours are different (sub headings perhaps or whatever the reason for the change of colour is). If the colour change is purely cosmetic then title1,2 and 3 would probably be ok.

There is a tendency to over-use that system (as in wordpress) so I try never to add more than 3 classes to a rule but mainly two most of the time where necessary.

Sometimes though it can be easier to use a new class altogether if your modifications are quite detailed but for a change of colour then an extra class tagged on is a good way to do it.

I often try to create re-usable sections of code that can be dropped anywhere on a page (within reason) and then just add another class to modify them depending on situation. In most sites there are often numerous opportunities to do this and save on code.

However, the class names should still be good class names and not .red or .blue.

There is also a school of thought that using mainly classnames rather than ids can help with specificity. For instance I often used to to this.

#content p{color:red}

But when I need to modify a certain p element in that section I have to say #content p.highlight{color:blue}

However if I had said:

.content p {color:red}

Then I can over-rule it with p.highlight {color:blue}

For main structure I would still use ids such as #main {}, but would avoid saying #main p{} as it is likely that some p elements would need to be modified.

In the end it's a matter of choice and sometimes there's little benefit in either method. It all depends on the job in hand and how its going to be structured, used and re-used etc.

[markbrown4]

I would also code it like the second code snippet you posted, I value brevity/readability above almost anything else.

[ralph.m]

Likewise, I'd generally prefer the client method, too. Being able to put multiple classes with different purposes on each div is very handy. But there's no right way, I guess.

[YuriKolovsky]

Thank you all for taking the time to share your experience with me.

I try to minimise the use of multiple classes myself – there are times when it's the best way of doing things but often it just ends up complicating things more

do you have any examples where this complication happens?

Off Topic:


Having options to set colors would also work if CSS just had variables, which would come in handy for more than colors. Someday maybe

There is a tendency to over-use that system (as in wordpress) so I try never to add more than 3 classes to a rule but mainly two most of the time where necessary.

Do you mean "never to add more than 3 classes to an element" or "never to add more than 3 classes to a css rule", like title1,title2,title3 {} or do you mean this title1.title2.title3 {}?

And what are the actual drawbacks of having more than 3 classes to a rule anyway?

For main structure I would still use ids such as #main {}, but would avoid saying #main p{} as it is likely that some p elements would need to be modified.

Also thanks for mentioning the school of thought, I've been having exactly this issue with some inner elements.

[Stevie D]

do you have any examples where this complication happens?

It's nothing major, mostly about the ease of working with the code. For me, most of the time I prefer to have a class that has all the style information about a particular design element. Sometimes there can be generic information that is common to several styles that I will abstract into a separate class, but when I do that, I try to make sure that it really is only generic rules, and not anything that might conflict with any of the other classes that I might want to apply to those elements. That's where it can get complicated – when you end up with conflicting rules being applied to the same element through different classes, or when you're trying to troubleshoot a page that isn't rendering as you expected it to and you've got multiple different classes interacting on the same element.

If you're neat and tidy about your coding and design, these shouldn't be a problem, but they can just cause that little bit of an extra headache if not used carefully.

[dresden_phoenix]

do you have any examples where this complication happens?

There is nothing inherently wrong with multiple classes. Sometimes its a good way functionality via .js toggling.
HOWEVER the MAIN risk I see is specificity conflicts. Specificity is defined via the number of selectors.

So the rules .Title1 h3 and .box1 h3 have the same specificity. This could end up having conflicts and thus debugging or changes in style may be perilous.

Another issue you could point out is code pattern.. assuming there is one. If the client actually cares about STRUCTURE.. this could give you the leverage you need if s/he doesn't then nothing you'll ever say will sink in , unfortunately.

What I mean by code structure is that if you know every one of the div's in the example will contain an H3 as a title, and that this is supposed to be so, then using .box# h3 reflects that structure far more confidently than .title# h3. That is their method are separates the properties of targeted elements in a way which does not CLEARLY indicate hierarchy. But again , maybe the client's goal is to be able to shuffle things willy nilly.

[Paul O'B]

Do you mean "never to add more than 3 classes to an element" or "never to add more than 3 classes to a css rule", like title1,title2,title3 {} or do you mean this title1.title2.title3 {}?

I mean something like this:

<div class="main highlight warning danger willrobinson user loggedin">test</div>

It just makes it too hard to debug afterwards as you have to search everywhere for the rules to apply or modify.

However, having said that I never bother looking through the stylesheet anymore to find stuff I just go straight to firebug and it tells me where everything is by line number so in some ways it means how I structure my stylesheet doesn't really matter as far as finding code is concerned.

[YuriKolovsky]

If you're neat and tidy about your coding and design, these shouldn't be a problem, but they can just cause that little bit of an extra headache if not used carefully.

I thought I was neat and tidy, but the way I wrote CSS does not seem tidy to my client, so I think I will have to convince him to sit down and do a rewrite where we assign common styling to certain types of boxes, and decide what exactly he wants to be able to swap around on his own, the only problem is that this takes time, and no client ever wants to waste their time on things that I was supposed to do in the first place (in his opinion).

But again , maybe the client's goal is to be able to shuffle things willy nilly.

He does care about structure, but he also wants to shuffle things.

I mean something like this:

<div class="main highlight warning danger willrobinson user loggedin">test</div>

It just makes it too hard to debug afterwards as you have to search everywhere for the rules to apply or modify.

However, having said that I never bother looking through the stylesheet anymore to find stuff I just go straight to firebug and it tells me where everything is by line number so in some ways it means how I structure my stylesheet doesn't really matter as far as finding code is concerned.

Does that mean that there are no drawbacks in having a ton of classes on an element any more because debugging is simplified thanks to firebug?

[ralph.m]

Off Topic:

things that I was supposed to do in the first place (in his opinion).

There are many ways to skin a template (so to speak) so unless he specifies something he wants at the start, it's not up to you to redo things free of charge when there was nothing wrong with them to begin with.

[Paul O'B]

Does that mean that there are no drawbacks in having a ton of classes on an element any more because debugging is simplified thanks to firebug?

With too many classes there's a drawback in html bloat and readability which is why I would try to keep the number of classes to a minimum.

It all depends on the job in hand but you don't want to end up with html that looks like old style html.

e.g.

<div class="bold italic red fontsize fontweight family">

If you do that then you are going backwards as it almost becomes old style presentational mark up.

[YuriKolovsky]

Off Topic:



There are many ways to skin a template (so to speak) so unless he specifies something he wants at the start, it's not up to you to redo things free of charge when there was nothing wrong with them to begin with.

Off Topic:

Yeah, I won't be re-doing things for free, but neither am I happy that I was not able to explain my reasoning for doing it one way

If you do that then you are going backwards as it almost becomes old style presentational mark up.

This is a great point Paul.

But it also makes me think that it's still not going backwards, now keep in mind that I'm not a fan of having more than one class on an element, just trying to make sense of things.
For example compare these examples (they are crazy to make the point more obvious):

Old style:

<div style="font-weight:bold; color:red; font-size:2em; font-family:Arial">
<h3>heading</h3>
<p>text</p>
</div>

Crazy style:

.bold h3 {
  font-weight:bold;
}
.red  {
  color:red;
}
etc...

<div class="bold red fontsize2 fontweight familyArial">
<h3>heading</h3>
<p>text</p>
</div>

Notice that classes still allow me to target the child elements, while the old style does not, this is still a major difference, and is really making my head hurt because it makes things a lot more complex to style.


Crazy ramble ahead:
Interestingly it also makes me realise that you can work perfectly fine with old style attributes only thanks to server side scripting, while CSS classes come in handy as groups, but could also be used as CSS variables that Stevie D mentioned in off-topic.

For example:
have every element on the page be generated by a server side script, using this script you then assign styles to specific groups of elements, where everything is handeled server side, and when you want to use variable styles you can use classes, or do it on the server side too. It seems like reinventing the wheel to me as CSS is fine enough, maybe offer the client some server side generated CSS files? where he picks what boxes from 1,2,3,4,5,6,7,8,9 he wants to have what styles assigned?



I clearly realise that classes are meant to identify elements of a certain group, not the groups style, but what keeps confusing me is that classes exist almost only for the purpose of visual representation (even when using js), so they indeed are groups of visual styles.
In the old days when files were plain HTML files classes are priceless, but now when everything is dynamic, styling can be dynamic too.



In the end I have decided to talk it over with my client and decide with him what type of styling he wants to add or remove on his own (because the client is always right), and will add them even if it's more than 3, and use my own styling method to give the default styling to the webpage.


Thank you all again for helping out, this is really great food for thought.

[itmitică]

What I mean by that would be the option to set out the basic colours for your site once and then refer to them by name/code throughout the stylesheet. So you could have something like:

define-color["headings"] {color:#060;}
define-color["subtle"] {color:#afa;}
 
h1 {font-size:2em; color:"headings";}
h2 {font-size:1.5em; color:"headings";}
#footer {font-size:0.8em; color:"subtle";}

and then if you wanted to change the colour theme for the whole site you wouldn't need to worry about hunting down every last reference to #060 because you would just need to change it once. Not that I expect to see it happen

Having options to set colors would also work if CSS just had variables, which would come in handy for more than colors. Someday maybe

Or maybe today.

320andup gives a great example on how to harness SASS to that end.
http://stuffandnonsense.co.uk/projects/320andup/

Excerpt from
_variables.scss

// 3. COLOUR 				==============================

$basecolor 		: rgb(45,53,62);
$compcolor 		: adjust-hue($basecolor, 180);
$bordercolor    : lighten($basecolor, 60%);

// Links

$linkcolor 		    : rgb(1,53,104);
$linkcolorhover 	: darken($linkcolor, 10);
$linkcolorvisited   : darken($linkcolorhover, 10);
$linkcolorfocus 	: darken($linkcolorvisited, 10);

// colour palettes

$alertcolor 	: rgb(252,248,227);
$errorcolor 	: rgb(218,79,73);
$infocolor 		: rgb(217,237,247);
$inverscolor 	: rgb(65,65,65);
$successcolor 	: rgb(91,183,91);
$warningcolor 	: rgb(250,167,50);

Excerpt from
320andup-csss.scss

// Colour interaction semantics
@import "colour";

Excerpt from
_colour.scss

/* Colour =================================================== */

// 1. ROOT 					==============================
// 2. TYPOGRAPHY 			==============================
// 3. COLOUR 				==============================

a {
text-decoration : none;
color : $linkcolor;

&:visited {
color : $linkcolorvisited; }

&:hover {
text-decoration : underline;
color : $linkcolorhover; }

&:focus {
outline : thin dotted;
color : $linkcolorfocus; }

&:hover,
&:active {
outline : 0; }
}

::-moz-selection {
background-color : lighten($basecolor, 65%);
color : $basecolor;
text-shadow : none; }

but now when everything is dynamic, styling can be dynamic too

320andup to the rescue again.

Look at the less folder for some great implementations of dynamic style with LESS.

Could someone help me understand if the clients method has any major drawbacks or benefits or is his way of writing CSS better than mine?
So that I can decide what kind of CSS to continue writing.

Regarding "client's way" vs. "your way".

I'd say both are inherently wrong.

I mean if you have 10 boxes, then you don't make them "box1",...,"box10", you make them "box" and "one",...,"ten". And with that, everything changes. For the better.

[YuriKolovsky]

I'm not a fan of generated CSS

Regarding "client's way" vs. "your way".

I'd say both are inherently wrong.

I mean if you have 10 boxes, then you don't make them "box1",...,"box10", you make them "box" and "one",...,"ten". And with that, everything changes. For the better.

Yeah, that is the best way to do it, and thank you for mentioning it because it did slip my mind for a moment, now I realize the best way to go about it in my situation.

But keep in mind that I made the methods in the question inherently wrong for a purpose, and it was to touch both the extreme ends of this balance, one being using classes as a strict identification method without any styling in mind, while the other was using classes strictly for styling purposes.

So the extreme ends look like this: "Classes for styling" vs "Classes for meaning"

having classes "box one" is closer to the "classes for meaning" end, while "box 3-columns" is closer to the classes for styling end.
interestingly both work well thanks to server side scripting, where to swap red for blue in all the right boxes just takes one edit, or if it's editable and stored in a database, one sql query.

Let me give another example:
classes "box one" can't have the box or the one mixed from box to box because it is meaning based, you can't just have "box one two three" one one element.
while with "style based" classes you can, for example "box thin tall bg1 float" you can mix and match the classes more, so you get more styling possibilities with less classes, and any person with zero CSS knowledge can mix and match them on their own.
The only drawback is that it adds more burden on me to design them to work in any combination, and it forces the client (who normally asks me to do it) to swap many classes on many boxes using a script when he suddenly decides that all the tall boxes don't need to be tall any more.

Yeah, it's a drawback, and to alleviate it I have created some base "meaning based" classes, that are already fully styled, so my client will add less style based classes


I've convinced my client to explain to me the styles that he wants to add and remove, made some basic styling that work with the combinations he wants, and he can now add some styling based classes to the otherwise "meaning based" styling that I did, along with position specific styling too and it looks like this (where box is a base class that he can't edit, this is example html, not the real thing).

.box {
  basic styling...
}
.one {
  basic styling for box one, already has most styles configured
}
.heading {
  font-size:1em
}
.content {
  line-height:1.2em
}
.position1 .box {
  some extra styling for position1 that is necessary for every box
}
.columns-2,
.columns-3 {
  float:left;
}
.columns-3 {
  width:30%;
}
.columns-2 {
  width:50%;
}
.bg1 {
  background:red;
}
.bg2 {
  background:blue;
}
.imgleft .img {
  float:left;
}
.imgright .img {
  float:right;
}

<div class="box">
<img class="img" />
<h3 class="heading"></h3>
<p class="content"></p>
</div>

<div class="box one">
<img class="img" />
<h3 class="heading"></h3>
<p class="content"></p>
</div>

<div class="box imgleft">
<img class="img" />
<h3 class="heading"></h3>
<p class="content"></p>
</div>

<div class="box imgleft columns-3">
<img class="img" />
<h3 class="heading"></h3>
<p class="content"></p>
</div>

<div class="box bg1">
<img class="img" />
<h3 class="heading"></h3>
<p class="content"></p>
</div>

<div class="positition1">
<div class="box">
<img class="img" />
<h3 class="heading"></h3>
<p class="content"></p>
</div>
</div>

Some of the names might not be great, but it's what the client wants because he can't remember what "box one" means, and I will make sure that redbg never has a blue background, and because he wants to mix and match a bunch of classes to make a ton of different boxes.

Either way now I am happy because the client is happy

The hint Paul gave about using classes instead of Id's also helped.

[itmitică]

In addition to what others have said, about classes not always being semantic, I'd like to add this: HTML attributes, aside from ARIA, have a small chance of being universally semantic.

It's a fool's gold, trying to find meaningful semantic names for vales in the class attribute. As opposed to tags, only unwritten conventions may make those values meaningful.

So it's safe to use any values for those classes, regardless: description or visual category. Like you just did, and it's no drawback to use them like that. It's convention, not semantics.

[oddz]

Some of the names might not be great, but it's what the client wants because he can't remember what "box one" means, and I will make sure that redbg never has a blue background, and because he wants to mix and match a bunch of classes to make a ton of different boxes.

There are probably several idealist who would look at code and think it is rubbish. I'm not nearly as motivated as others or to be precise the departed to go through it. However, given the requirements you are working with the sacrifice is understandable. Just don't expect to get any pats on the back or submit it for a portfolio review for people with idealist view points. Without hearing your side of the story the mark-up looks like it was written by someone who doesn't know what they are really doing. One of the departed highly opinionated members would probably tell you that classing a h3 with "heading" would be grounds for abolishment from this planet. Though I wouldn't say that… given your requirements. So just know what you are doing isn't really ideal and be ready to be assertive in regards to being asked why you did that way if showing the work in a portfolio.

[YuriKolovsky]

One of the departed highly opinionated members would probably tell you that classing a h3 with "heading" would be grounds for abolishment from this planet.

Thats right, but what about Mozillas recommendation to add classes to everything for performance reasons?
I don't have the time to fetch the link right now, but here is a similar one https://developer.mozilla.org/en-US/..._Efficient_CSS
They mention that having tag selectors is highly inefficient, and so adding classes to everything is standard procedure.

I personally don't like to add classes to everything, but it's still something to keep in mind when grading someones work.

[markbrown4]

http://css-tricks.com/efficiently-rendering-css/
It's the browsers job to optimize css. You should know best practices and avoid huge selectors but most of the time selector performance isn't an issue.

[John_Betong]

Off Topic:


Having options to set colors would also work if CSS just had variables, which would come in handy for more than colors. Someday maybe

Try this:

Keep refreshing the page and see how the colours change:

http://johns-jokes.com/downloads/sp-a/php-in-css/

Please note the site is cached. When viewing the source the additional code is due to Cloud Hosting. I would be very grateful if anyone knows how to disable this feature only on this page and not on the complete site.


file: style-001.php

<?php header("Content-type: text/css;charset:UTF-8");
  $hex = mt_rand(0,17);
  $x   = sprintf('%x', $hex);
  $bg0 = $x.$x.$x;
  $bg1 = 'f' .$x .'f';
  $bg2 =  $x .'ff';
  $bg3 = 'ff' .$x;

?>
body {background-color:#<?php echo $bg0;?> }

h1  {background-color:#<?php echo $bg1;?> }
h2  {background-color:#<?php echo $bg2;?> }
h3  {background-color:#<?php echo $bg3;?> }

div {width:88%; margin:1em auto; background-color:#eff; color:#000}

file: index.php

<?php /* */ ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
  <title>Just Playing with PHP and CSS</title>
  <link type="text/css" href="style-001.php" rel="stylesheet" />
</head>
<body>

  <h1>Heading 1</h1>
  <h2>Heading 2</h2>
  <h3>Heading 3</h3>
  <div>
    <a href='http://www.sitepoint.com/forums/showthread.php?870800-Class-quot-clear-quot-pros-cons'>
      Sitepoint discussion
    </a>
    <br /><br />
    <?php highlight_file('style-001.php');?>
  </div>
</body>
</html>