The class tag in HTML is used to define different sections of the web page that you want to look the same, so you can later style those sections of the page with CSS or JavaScript.

For example, it can be used to make all the numbers on a page look bigger, or it could be used across several pages to identify different specific parts of your page that you would like to look the same on every page of your web site.

The class attribute looks something like this:

In a div:

.... something goes here ....


And inline:
The quick brown fox jumped over the lazy dog.

You can put a class attribute on any html tag. You'll noticed I put a slash ending on each HTML tag, in addition to, making it HTML5 compatible, it also defines the end of the class.

One problem you may have in your CSS styling is caused by not ending HTML tags. This is one of the reasons you should always validate both your HTML and CSS scripts. Validating will pick up where you missed those nasty end tags, and make sure you haven't missed any ":" or ";" in your CSS script.

Let's get into some unique things we can do with the class attribute. You can combine class and id attributes in a single tag. The ID tag is the unique name of a section of the page, and that name can only be used once on the page. Here's an example of an ID and CLASS tags together:

In a div:

.... something tomish goes here ....


.... something dickish goes here ....


.... something harryish goes here ....

To use this in your CSS script, we could do something like:

.names {
font-weight: 800;
font-decoration: underline;
font-size: 1.2em;
}

#tom {
color: blue;
}

#dick {
color: green;
}

#harry {
color: magenta;
}

And you can combine them like so:
#tom.names {
font-style: italic;
}

.names#tom {
font-style: oblique;
}

In the case of the last two tags where we combined the ID and CLASS attributes, both are identical, and the order of the tags does not matter. You can have the ID first or the CLASS first, it is the same and has the same weight in CSS.

In this case since ".names#tom" is last in the script, the font-style rendered on the page will have the oblique font-style, thanks to the CSS cascade.

As long as we're talking about combining tags, you can have more than one class attribute in a single tag. Let's take a look at how this is done:

... something goes here ...

All the class names above are valid class names.

Let's take a closer look. You can have as many class names as you want in between the class quotes. Each class name is separated by a space, not a comma. The order the class names are in does not matter. The classes "names fudge" is the same as "fudge names" in the eyes of CSS.

Here's an example where we use the same styling as in our first example, using classes instead of the id's in the first example. The styling on the web page will be the same as in the first example.

.names {
font-weight: 800;
font-decoration: underline;
font-size: 1.2em;
}

.tom {
color: blue;
}

.dick {
color: green;
}

.harry {
color: magenta;
}

And you can combine them like so:
.tom.names {
font-style: italic;
}

.names.tom {
font-style: oblique;
}

The order of the names does not matter. The result will be an oblique font-style for .tom.names because of the CSS cascade. Also you can push the CSS name together, and don't need a space to separate them in the CSS tag.

One final note, for the few of you that still use IE6. IE6 does not do multiclassing. If you have CSS tags like ".names.tom", it will only see the last class name ".tom". You can still use each class in separate tags though, so ".names" works as a stand alone CSS tag.

Gee, I hope if your reading this post, none of you are using IE6, in fact I hope none of you are using any IE for your web development. If so, I'd like to suggest you might be a tad behind the technical power curve. Until next time...

There are many CSS Frameworks out there, that are free, for any developer to use.  What does a CSS Framework do?  Well, despite the fact that web browsers are all getting closer and closer to rendering web pages the same, they don't.  Browsers use different layout engines, that render web pages slightly differently.

The biggest pain for a web developer is to make a web site look the same on all browsers.  The second biggest pain is to make a consistent layout of columns in the web page.  Depending on what type of layout you want to use, you have to use different CSS techniques to accomplish each type of layout.  I'm talking about fixed sites versus elastic sites that expand and contract as screen resolutions change.

To make web developers job easier CSS Frameworks were developed to solve both of these problems.  The first problem is usually handled with what is called a CSS Reset, followed by a special file just to handle the IE browser, since it still is the worse browser available for adhering to W3C web standards.

The CSS Reset was first developed and championed by Eric Meyer, the Father of CSS, as he has consistently been involved in CSS development throughout its history, has written several books on CSS, and has a successful blog on the topic. His reset is available from his web site. It's a CSS file that can be edited like any other CSS file that resets all browsers to the same starting point when you start development.  His CSS Reset has been the initial source for all of the other CSS Resets used by other CSS Frameworks.

The next layer up is to have a CSS Reset and also format the text, forms, links, and tables to have a consistently, aesthetically pleasing look and feel on the web page. Fonts are preselected and move up nicely as you increase font size.  If you increase the font size by percent instead of pixels, the font size is consistently rendered.  Tripoli CSS fits into this category.

The rest of the CSS Frameworks go to the next level, and try to make web page layout easier and consistent across browsers.  This type of framework started with Yui Grids from Yahoo, followed by Blueprint, which also added Print layout.  These two are probably the most used of the layout frameworks.   Just as an aside, I use Hartija CSS to do my print layout.  There's a slew of others that offer a  slightly different twist on what they do, and each has its  slightly different layout tags and methods that you have to learn to use them.  Not to be remiss, other Frameworks you can checkout are: Yaml, Elastic, 960 Grid System, Emastic, Snowdust, Scaffold, Compass, and Elements.  If I missed any, my apologies.  That's a confusing array of choices for any developer, so the tendency is to pick one and stay with it.

There are two problems, for me, with using these layout frameworks. First, they all add bloat to your web page, as the framework has to account for every possible layout in its CSS files, and you're adding that to every web page.  Second, each framework has its own methods of implementing the framework within the web page, which involves learning their language and methods.

As I got better at CSS I found I was, at first, opening the framework's CSS file, and eliminating layout formats I wasn't using on the web page, and didn't need in the CSS file.  Next, I found from doing this, that I could do my own layouts, and get rid of the frameworks bloated code, not have to continually edit updates to the framework, and not worry about learning the framework language and methods.  In short, I outgrew the frameworks.

I came to the conclusion, that I need a CSS Reset for browser compatibility, and I like to have a aesthetically pleasing, and  consistent, look to the font on my web pages.  Tripoli was my best option, and I have been using Tripoli CSS ever since that decision.  Tripoli offers a CSS Reset, which I admit to have edited to change hoover colors and take out Opera 5 compatibility, and a consistent font look, and that's it.

Tripoli also offers a fixed width only layout plugin, which I admit to occasionally using, since the layout is simple, solid across all browsers, easily edited, and gives me a solid layout through out my site.

First, the link command , in your HTML document, in the header at the top of the page, is where you place "link" commands, and it looks like this:

You can have as many links as you want, but they all must be placed in the head section of your HTML document. CSS files are then added to your HTML document in the order they were listed in the header section.

The "rel" command tells HTML what it's loading, in this case a stylesheet. The "type" tells HTML how to parse the contents of the file, when it opens the document. I know it seems redundant, but both are used.

The "media" tag is important. It tells HTML when to use the stylesheet. If you only want to style your printer output, use "print" as the media type, and the only time that styling will be used is when the document is printed. You can have more than one media type separated with a comma. Possible values for the media tag are: all, aural, braille, embossed, handheld, print, projection, screen, tty, and tv.

Now, the @import command, that looks like this, if placed in the head section of the HTML document:

The @import tag, however, is normally used inside another CSS stylesheet file, that is then used to load more than one additional CSS files, like so:

@import url(../css/topmenu.css);
@import url(../css/sidebar.css);
@import url(../css/footer.css);

The first CSS file is loaded with the "link" or "@import" command from the header section of the HTML page, and after that CSS file is open, it would then load the other import CSS files. The rule for @import, when used in a CSS file, is that it must appear at the top of the page before any other CSS tag. If the @import tag is placed after another CSS tag it is ignored, and you'll find your styles won't load.

You may have picked up that there is no media tag with the @import command when inside a CSS file, you'd be correct, which is one of the difference between "link" and having @import within the CSS file. If you want separate media types for CSS files, then you should load them with a media tag in the HTML header section.

The other difference between the two is subtle, the "link" tag is an HTML tag and must appear in the HTML page in the header section. The "@import" tag, on the other hand, is a CSS tag, and thus, must have the "style" tags around it in the HTML page, or be embedded at the top of a CSS file.

So which one do you use?

Designers some times like a nice clean look to their HTML pages. They like to link in one style sheet, usually called "style.css," and then, in that style sheet, @import all the other style sheets for the page. The result is one line in the header section of the HTML page, nice and neat.

However, there are two problems, in doing that, to consider. Older browsers, when you use @import in the CSS file, especially IE, may load your CSS files out of order. Because of the nature of the CSS cascade, the order in which style sheets load is important, as to which style will be used for a particular tag. This will cause the designer a problem during development when he can't figure out why the styles for a particular tag are not working, or why the styles work in one browser and not in IE.

The other issue is performance. This was analyzed best by another blog author in High Performance Web Sites. When you load CSS files with the link command in the header of the HTML page the CSS files load in parallel with the order preserved. When you load CSS files with an @import either in the header section, or in a separate CSS file, CSS files are loaded sequentially, and you take a performance hit. Admittedly, this is not a big hit, but it does slow your load time.

The answer to this question now becomes obvious, use the "link" command in the HTML header section. You can specify your media type easier, you're sure the CSS file is being loaded, you're sure of the order that the CSS files load, and you load the CSS files in parallel, so your page will load faster.

To address the question, let's first start with a quick look at CSS specificity, it all starts with specificity and the cascade. It is named Cascading Style Sheets, after all.  Specificity, or which property takes precedence over another property,  is not that difficult to understand, if you think of a card game, like pinochle or spades, where the higher priority suit trumps all the other suits, and wins.

There are essentially 4 levels of specificity, or priorities, in determining which property will be used when there is a conflict, and since most developers use more than one CSS file for a single page, believe me, you will have conflicts.  The four levels, in order of highest priority to lowest, are: inline, ids, classes, and element tags.

If you have two different selectors that reference the same part of your HTML page, the higher level priority wins. If they both have the same level of priority, two ids for example, the last one in the list wins, thus the cascade name in CSS. That's it.

Not quite, let's talk more about using these selectors to minimize your problems in using CSS.

First off, there is a super trump tag that you can use, the !important tag.  It's not technically a selector, and it is only used with individual CSS properties, like so:

.footer
{
color: blue !important;
font-size: 0.6em !important;
margin-top: 5px;
}

If it's used, it trumps all other properties for that particular property.  CSS will use this property on the page when rendered.  Your footer in the above example will be blue with a font-size of 0.6em.

Having said that, it is a matter of pride to me, and a sign of a good CSS development, never to use the !important tag, huh?  If you use it too much you could run into conflicts where CSS will decide, with the cascade, about which !important tag is more important, and that will really confuse you.  If you want to get good with CSS, do yourself a favor, and forget about using the !important tag.  Of course, there's always that one time, where you just can't seem to make it work...only kidding.

Most people don't know that inline styles are higher in priority than the id or class selector.  Inline styles are used with the HTML span tag like so:

The quick brown fox jumped over the lazy dog.

If I had a CSS file with the following entry, what color will "jumped" be in the above web page?

#foxy {color: red;}

Yes, green with an 40% larger font, because the inline style trumps the "foxy" id selector.

Now, to the interesting tags, and the reason for this article, id's and classes. Yes, id's beat classes. Every id in the web page should be unique and only used once. You should use classes when you want to have the same properties affect multiple areas, or selectors, on the web page.

That doesn't mean the same id can't be used on every page, and often is. A good example is the use of id's to break up the page.  Most developers use a header, footer, navigation, sidebar, and main content id on all their pages.  Then they can include the same style sheet file in every web page and have the header, or footer, for example, have the same styling on every page.

My vote is to take a slightly different approach. I'd like to suggest you make these classes instead of id's.  For example:

Copyright 2010

Why?  More control.  You give yourself an extra layer of uniqueness control when you really need to adjust your styling.  Suppose you had more than one type of header for your web site, but every header is located in the same location on every web page, and you want to style that location.

If you use the class "header" for all your pages, you only need to style the location once, but now on pages where you want to make the header different, you can have another class along with the original header class, or a unique id for just that one unique header page. Your not assigning a unique id name for each type of header, and having to remember which one is which in your css file. I, also, don't have to duplicate the location styling for each id.

When you need to adjust one thing on one page, you can assign it a higher priority id along with the class.  You won't have to worry about competing id's, which is the cause of most styling conflicts, and you'll end up with a lot less head scratching, trying to figure out why your styling isn't working.

Pseudo elements are tags that CSS recognizes, that attach to HTML tags, but are not put directly into the HTML markup. We see this most often used with hyperlinks and anchor tags.

CSS uses four pseudo elements to style links:

:link The link pseudo tag is used for all links on the page that point to other locations that have NOT been visited. Here's an example

a:link {
color: blue;
text-decoration: none;
}

Normally a link is underlined by your browser. If you don't want your link underlined you can shut the underline off with the text-decoration: none;.

The next tag is ":visited." These are sites that you have clicked on, visited, and then have returned to your page.

a:visited {
color: orchid;
}

Note the pseudo classes, " a:visited" for example,  is attached directly to the html tag with a colon, no spaces.

":hover" This styling will happen when your pointing device, or mouse, moves over the tag.  You do not have to actually click on the tag for hover to work.  This tags is used with the "img" tag to swap images when your mouse rolls over a picture. You can use this with other tags, like a table row.

tr:hover {
background-color: yellow;
}

Finally, we have ":active"   This styling is applied when an element has focus. Typically this is used with forms when you click in a form input box, or tab to it,  to type your name for example.

input:active { background-color: orange; }

Those are the basics, now let's get a little more specific, pun intended, and why some people's pseudo styling doesn't work the way they thought they had styled their tags. It turns out that pseudo tags all have the same specificity in CSS. That means that:

 a:link {color: blue;}
 a:active {color: orange;}
 a:hover {color: yellow;}
 a:visited {color:orchid;}

All are equal in terms of specificity in CSS. And according to the Cascade Styling rules, if specificity is equal, the last styling gets the nod. In the above order, if any of your links become visited, then, from then on, your link will show only the orchid color. Not quite what you want, so visited needs to be listed higher up, first or second.

In order for your links to perform properly, like you expect, they need to be listed in the correct order which is:

 a:link {color: blue;}
 a:visited {color: orchid;}
 a:hover {color: yellow;}
 a:active {color: orange;}

Link and Visited are mutually exclusive, in terms of which applies, so they can be listed in either first or second order interchangeably. Again: visited, link, then hover, and finally active: vlha, or "Very Lean Hungry Apes" as a memory aid. Enjoy, and good CSSing to you.

I had evaluated CSS Frameworks about a year and a half ago notably Yahoo's YUI grids, Elements, Blueprint, Tripoli, Hartija, and BlueTrip.  Elements included a folder systems for the entire site.  BlueTrip is Tripoli and Blueprint combined.  YUI, Blueprint, and BlueTrip feature a grid system to make multiple columns easier to implement.  Hartija is for printing.  Tripoli is a minimal framework that features a reset and font styling, but no column grids.

The outcome of the above review was I decided I had no problem making grids in CSS.  These frameworks seemed to add a lot of bloat with a learning curve.  I did not need a folder set up. I needed to have browser compatibility handled by Tripoli, and needed printing, handled by Hartija.  That's what I settled on and use with all my sites.

I searched for CSS Frameworks and found some new ones I missed in my earlier survey:  "960" was new and looked nice, then there was jQuery UI framework, and YAML.  I didn't jump to  look at any of these until I ran across a framework called Elasticss or Elastic CSS.

What hooked me on taking a closer look at Elastic.  A very simple grid system, elastic or fixed width columns, built-in event handling, and elastic and fixed height columns.  The last two features is what hooked me, no other framework I saw offered built in event handling and variable height columns, except maybe jQueryUi, which looked a lot more complicated to implement.  I decided to give Elastic a look.

I downloaded it, set up an HTML page, and started to link in their CSS and Javascript libraries.  And that's where I started having trouble.

I just could not get the thing to work initially.  I had problems with understanding how to set up the html tags to make the framework work.

The elastic site had documentation, but it had problems.  It seemed complete, but what was wrong, was the developer had changed the syntax from one release to another and had some documentation one way, and some the other, which made things very confusing when the site didn't work.

The way I made it work was to look at their demo pages, view the page source in the browser, and copy there tags to my html page.

After I got everything working, I had mixed results.  On the plus side, their column system is excellent, and is not really a grid system. It features English language intuitive syntax. It is the easiest column system I have run across.  Columns are very flexible and easily re-size across the page and can be multilayer.   The ease of making columns, with intuitive English tags, alone would make me consider using this framework.

Html file showing Elastic CSS English language column syntax

The event handling was accomplished by linking in jQuery with the framework.  I was happy with this, since once jQuery was linked in, I could use it on the site, and with other plug-ins.  It did all the normal framework things well, like layout, browser reset, printing, and font styling.

On the minus side, I could not get the variable height columns working, and this was the main reason I evaluated the framework, and I tried.  I figured maybe a piece of the code had an error.

I put all the CSS through a validator and found two of the six CSS files did not validate, nor did the javascript come up clean.  I was not sure by the error, whether a  "*font-size"  tag, for example, which throws an error in the validator, was somehow part of the framework, or simply should be taken out and made "font-size."

I was almost already to far into it when I wondered if I had the absolute latest version, I decided to download the entire project located on github.  Did I mention how much I love git and github.

I opened the project, used the latest files, and still could not get the heights to adjust.  Bummer.

The resulting web page from the above Html file with CSS styling.

Elastic CSS looks to be about a year and a half old from its inception.  My hope is the developers will keep working, I think they could eventually have something special.  Right now, however, I don't think Elastic is quite there yet.

Here's what I want from a CSS Framework, and so far, I haven't found one that has it all.  If anyone knows of a framework with these features please let me know.  An easily understood and implemented multiple column system that handles elastic, jello, and fixed layouts, the same identical page in all browsers, print formatting, vertical column flexibility to eliminate "faux columns," and make columns have equal heights, the ability to style layouts, fonts, and colors easily across the site in separate css files.  jQuery integrated with the framework.  Finally, all of this imported with one line into a skeleton xhtml file that is a template to produce your page, and when I unzip the file and place it on my server, everything is linked up.  Now that would save  me time and is worth the cost of admission.

In thinking about what I'm asking for, it doesn't seem that unattainable, what it takes is someone with some spare cycles to put it together, or for the Elastic developers to polish their already nice framework to get the heights to work out of the box.   It also would be nice if everything validated.   I have my fingers crossed.

One of the things that cause people problems, and is not built into CSS, is filtering CSS styles and applying one style if a certain condition exists.  In short, an "if" statement.

There are several workaround for this, one of which is to use PHP to switch styles depending on a condition.  Let's take a look at the way you normally include a stylesheet in a web page.

The CSS file, cssfile.css, might look something like this:

h1 {color: blue;}
p {color: purple;}

.reguser {color: purple;}

Now suppose we only want the text in class "reguser"  to show up, with its special purple color styling, if the user is registered on your site, and if the visitor is not registered, then the text will not be displayed.

Let's use PHP to set up the condition.

In the PHP portion we unset a variable that we will use to track a registered user to initialize the variable.  We then set the $user variable to true if a user registered on another web page, using a $_SESSION variable.

We then get to the "IF" statement.  "IF" the $user variable is NOT set, as in the visitor did not register on the site, we add another CSS include file.  As an aside, you could have just as easily added another CSS file with an "elseif" statement.

Most web pages have many CSS files included, so adding another CSS file is nothing unusual.  It is encouraged.  In fact, CSS defines rules called specificity and the Cascade, as in Cascading Style Sheets, that determine which styling rules apply if there is more than one style assigned to the same element.

Let's see what the second CSS file looks like to take out the registered user text on the web page.

.reguser {display: none;}

Well, that was easy.  The CSS says not to display the element, so it will disappear off the page, and the PHP lets you have conditionals in your web page styling.

It use to be that you built web sites for a 800x600 resolution monitor, those days are gone. Now only about 3% of users have their monitors set at 800x600. The current sweet spot is 1024x768 with 20% of the viewers using this resolution. With more and more people moving to 1280x800 at 19% and 1280x1024 at 15%. The resolutions are all over the place. At this point in time you should optimize your web site design for 1024x768. That means that those folks that are still using 800x600 will have to scroll to see the screen.

The fact that a significant number of users not only have different resolutions, but most are greater than 1024x768 has led web designers to design sites that stretch their width for different resolutions. The CSS term for this type of layout is "liquid layout." The problem with liquid layouts is that if the screen stretches too wide, and text lines get longer and longer, text becomes difficult to read. The solution for this is the "jello layout," where the expansion of a web page is limited to a maximum width.

One of the solutions to the changing width is to use a consistent background color to surround your main content. This works and it is the easy way out, the content is set to a maximum width and the background covers whatever width is left. At higher resolutions though this looks ugly, too much background color. The solution is to make your background more interesting with a background picture or composite image, and that's when you run into some problems.

The traditional way to put a background image on your site is in the CSS file, like so: body {background-image: url(../images/myimage.jpg)}. The only problem with doing that is that you can't re-size the background image in CSS. To do this you have to move the image to your html file. This allows you to style and re-size your image in the CSS file.

Before we get into how to do this, a word about the background image you will use. If you expect to stretch the background image in width from one resolution to the next, you want an image that is more landscape oriented than portrait oriented. The problem with a portrait image is if you stretch the image too much you will distort the picture, landscape images bend easier in width. You also should scale the image to a size close to the size in width it will be at 1024x768, or 1024px. You can crop the image if it becomes too long in height. Lastly, you should worry about the image load time or the file size, and consider compressing the image to reduce the file size.

OK, we have the image we want for our background set up and ready to go. How do we set the background image to re-size with changing resolutions. First the html structure:

Nothing unusual here. We are inserting an image into the web page right after the body. The tricks are in the CSS, let's get to that...

* {
	margin: 0;
	padding: 0;
}

body {
	text-align: center;
}

#backimg img {
	position: absolute;
	top: 0;
	left: 0;
	width: 100%;
	z-index: 0;
} 

That's all there is to it...well, not quite. This will anchor your image to the upper left corner as a start point. The "position: absolute;" takes the image out of other relational groupings with the rest of your web page, and is important to making this work. The width: 100%; tells the browser to stretch the image across the entire monitor window. Well, get to the z-index in a second.

Well, that's all well and good, if you change browser resolutions, you'll see the image stretch, depending on your monitor resolution, but how does the content area fit into this set up? Well, the "bodywrap" tags represents the content of your web page. You want that centered in your window with the background image to show on either side of your content. It would be nice if the content would re-size with the background, and well use the same technique to do just that. Here's the CSS.

#bodywrap {
	position:absolute;
	width: 94%;
	margin-left: 3%;
	margin-right: 3%;
	margin-top: 30px;
	z-index: 20;
}

This will expand your content with a 3% border for your image to show on the edges. Use the margin-top: 30px; if you would like to show a piece of the background image at the top of the screen. If you'd like to have your content have a white backdrop, we need to add another div. It would be background image, then backdrop, then bodywrap for your content, here's the CSS section for the backdrop, like so...

#backdrop {
	position: absolute;
	background-color: white;
}

Here the color of your backdrop is white and we have also taken the backdrop out of the web page components layout, but it is absolutely embedded in the bodywrap.

Which brings us to the z-index. The z-index tells the browser which layer to put on top of another layer. The higher the number, the more that content block is moved to the front of the screen. Thus our background image is 0 and the bodywrap is in front of that image at a z-index of 20.

Here's the complete CSS file in a compressed format. Enjoy.

* {margin: 0; padding: 0; }
body {text-align: center; }
#backimg img {position: absolute; top: 0; left: 0; width: 100%;	z-index: 0; }
#bodywrap {position:absolute; width: 94%; margin-left: 3%; margin-right: 3%; margin-top: 30px; z-index: 20; }
#backdrop {position: absolute; background-color: white; }