CSS Layout Tutorial (Part one)

[glyakk]

Due to popularity, I am going to try creating a three-part tutorial that will outline guidelines that you can use to migrate away from a Table based layouts. If this tutorial is well received I will continue with the other two parts as I get time to write them.

*Part one will deal with defining why to use CSS and to cover the terminology relating to positioning.
*Part two will confront the meat of this tutorial, the position attribute.
*Part three will handle a few tricks and hacks.

First some very powerful tools you could use to experiment with CSS are available for free. In fact it’s the first tools I turn to when I start coming up with a new site or page.

Mozilla Firefox (www.mozilla.org/firefox) and two extensions (texturizer.net/firefox/extensions). EditCSS and Web Developer down in the developers tools section. EditCSS allows you to load the CSS of a document into the sidebar and edit it in real time to see what effects you are having in real time. Truly an awesome tool. And the ultimate tool bar that no web designer should be without, Web Developer. If nothing else it has a function that can outline all elements in your document as you are viewing it from firefox. Great to see what’s going on with your elements. Used together these make great tools to play with CSS. And they are totally free.

Edit: The web developer extention now comes with EditCSS functionality built in.

Why CSS?
This argument comes up allot. Why use CSS when table based layouts work? The biggest reason is because of expandability. Table based layouts visually get the job done. If you have good eyesite and a half decent browser everything for the most part is fine. However they do a poor job addressing everything else. And most people with an internet connection do. So you would be able to reach about 85-90% of your users with tables. Not bad. But with proper use of CSS you could reach more if not all of them, and make your life so much simplier. Using CSS you do a fair amount of work upfront (at least when you start using it) but do little work later. Such as maintence or doing redesigns. Table based layouts are the opposite; they require fairly little work up front (assuming you are familiar with using them) but are very difficult to maintain. This is because with CSS you separate style from content. The markup of your pages does not change when you switch your design, only your style sheet attatched to the doument changes. So you could redesign your site by simply switching your style sheet. CSS Zengarden (http://www.csszengarden.com) is a perfect example of this.

When you use CSS you tend to create correct markup naturally, you begin to discover tags you never knew existed or you use very infrequently. After all why use the <P> tag when you could just wrap this bit of text in another <TD> right? Using CSS properly almost forces you to write valid (X)HTML. And writing valid markup will speed up loading time. Many designers don’t give much of a though about loading time because of the wide spread use of high-speed internet connections and fast processors and gobs of ram that seem to be the norm these days. But table based layouts do take a slight bit of time longer to render then CSS layouts. But writing valid code has another special bonus!! Search engine spiders love valid correct use of markup (http://www.alistapart.com/articles/seo). Although you don’t need CSS to write valid code, using it will help form this very good habit.

There is allot of discussion these days about accessibility for people with disabilities. The baby boomers are getting older as we all know and many of them use the internet from time to time. Their eyesight is getting worse and they often need to increase the size of the text. Using a table based layout sometimes this could end up breaking your site, separating sliced images, extending <TD>'s etc.. You can design a CSS layout to accommodate for this, as well as create separate specific styles that the user switch can between that might make your site easier to read such as switching to a better font, dulling bright distracting colors, etc.. This goes far beyond simple text enlargement. Also going back to writing valid code, this helps screen readers to better read your page. When your user gets to an <H1> tag the screen reader will act accordingly instead of having to decipher that the <TD> at the top of the page with the 24pt text is your heading. The topic of accessibility for people with disabilities can be made into a whole other tutorial or other book for that matter. The point is that CSS makes it much easier to achieve that goal.

Speaking of accessibility what about all these new fangled pda's coming out? Or other devices that can access the web? They bring with them the promise of being able to access the internet wherever you are. I think its a great idea, however us web designers are not playing nice and we are creating sites that don’t work, or at least work slowly in these devices. We are hurting what we are trying to create, the ability to access information anywhere. They don’t have the same resources our desktop computers have in terms of processor power or whatnot. As stated earlier table based layouts are much more processor intensive and in the case of these devices your site will take significantly longer to render. Also these devices have browsers themselves and if I am not mistaken the majority of the pocket pc users are using scaled down versions of IE 3.0 witch did not even use CSS!! So it will be ignored and the valid markup will remain, witch would be there because you practiced writing it religiously while designing your CSS based layout. J So it will degrade gracefully.

Witch brings me to my last point. Another reason why to use CSS is it helps get old outdated and broken browsers out of our lives once and for all. Why are we designing for such old browsers to ensure that our pages look at good (or bad) on their system as it does on the latest and greatest? When you use CSS and valid code, old browsers that do not understand CSS will ignore it and you will be left with you’re the information, the meat of our project. Although this does not look pretty, it will still enable our users to see our content without problems. There is also the issue of browsers that DO understand CSS but misrepresent parts of it. Although there are ways around the majority of these issues (Hacks) I do not endorse their use. They go against the principals of writing valid code, in the first place, but they are a necessary evil as browsers are slowly made to work properly. I will go over some of them in part three of this tutorial.

[glyakk]

Now that we got that sorted out
Layouts using tables has been the norm for too long. With the introduction of CSS1 back in 1996 and CSS2 only two years later you could think CSS would be more commonplace. And although they are getting better there is much to be desired.

Most people have no problems using CSS for things like font assignment, or menu creation using <UL>. That’s easy!! However the most elusive part of CSS seems to be its positioning aspects. AKA going tableless!!

*GASP*

Its really not that hard to layout a website using CSS. All you have to keep in mind is that you must forget almost everything you already know about webpage layout :). Not too difficult, right? The problem is that people that have always used table based layouts like to try to abuse CSS into doing things they are familiar with doing in tables. Such as, they treat <DIV> as though it were a <TD> without a table! Well it does not work like that. <DIV> is simply a division of your content, that’s what div stands for, division. You are putting tags around a bit of your markup to separate it from the rest of your markup. Another element that you can use to divide content is the <SPAN> tag. However <SPAN> deals with inline elements and <DIV> deals with block elements.

Inline vs. Block
Each Element that you use in your markup is either an Inline and Block element. An inline element is like text in a paragraph,

...This is text in a paragraph. The
<span>span tag</span>,
<a href="#">the a tag</a> and
<img href="#" /> are examples of inline elements...

inline elements keep with the flow, by default they do not create or define line breaks. Elements like <SPAN> <IMG> <A> are inline elements.

A block element would be the paragraph. <DIV> <UL> <H1,2,3,4,5,6> are also Block elements. They interrupt the flow of a document or define/create line breaks.

Box model basics
All elements theoretically box around them weather they are inline elements or block elements. It is essential that you become familar with the box model and how it works to work with CSS correctly. The parts of the box model are the content area, the padding, the border and the margin. Many elements have a predefined box model defined for them by the browser unless you redefine them in your style, such as by default all <UL> elements have some margin, same goes for <H,1,2,3,4,5,6> elements, <TABLE> elements have a border in gecko browsers, and the <BODY> element has some padding. WIth CSS you can redefine the values for these elements.

The content area of the box model is the place the content of the element will show up in, its also what is defined when you declare height and width, many people believe that when you define height and width you are defining it from border to border (if you are using IE 5.0/5.5 or 6.0 in quarks mode this is true) but in fact border and padding is not part of the width.

So lets say that you have this in your CSS:


element {
width: 50px;
height: 20px;
padding: 5px;
border: 1px solid #000000;
}


You would probably think that your overall width would be 50 pixels and height 20 pixles. When in fact according to the CSS specification it is actually 62 pixels wide (1+5+50+5+1=62) and 32 pixles high (1+5+20+5+1=32).

The padding area of the box model is sort of a buffer area between your content area and your border. In many ways it’s the same as margin only inside the border, however there is one difference that sets it apart. If you apply a background color or image to your element it will be inherited in the padding, where as your margin, it won’t. In CSS you can define it a few ways, either as an overall value to be applied to all sides or groups of sides or all sides individually.

Such as:

padding: 5px; /* all sides */
padding: 5px 3px 10px 10px; /*(top) (right), (bottom), (left)*/

Or you may apply the values this way:

padding-top: 5px;
padding-right: 3px;
padding-bottom; 10px;
padding-left: 10px;


The border of the box model is straight forward and the simplest part to understand. It’s the border, or area around the content and/or padding and just before the margin. With CSS you have some options on your border style, solid, dotted, dashed, inset, outset, grooved, double, etc..


border: 5px dotted #999999; /*all around border*/

Or to define all sides independently:

border-left: 5px solid #999999;
border-top: 1px dashed #FF0000;
border-right: 5px double #FFCC33;
border-bottom: 20px grooved #770077;


Margin is a lot like padding as stated earlier, only it resides outside of everything else, it cannot be colored or made visible with CSS or markup, it acts like a 'force-field’ (for those familiar with 80's cartoons) around your element. However Its values can be defined the same way padding is defined.. just use the word margin instead of padding.

Note: You may also apply negative values to the different parts of the box model to achive different results. In part 2 and 3 we will probably see some of that.

[glyakk]

Positioning properties
This is where the heart of CSS positioning comes in. This is where most people loose track, and to be honest it’s quite easy, just improperly explained. I hope to remedy that here. There are four values you can assign to this property: Static/Normal, Relative, Absolute, and Fixed. Static/Normal is actually the same thing; it’s the default vale of all elements. In CSS1 it was called Static, in CSS2 its now Normal. As far as I'm concerned this value is useless.

The following examples use the same markup, just different CSS rules.

Here is the Markup

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>CSS Tutorials</title>
</head>
<body>
<p>The dog walked <span class="standout">hungrily</span>
past the butcher shop</p>
</body>
</html>

View Example (http://www.digiffect.com/tutorials/css/base.htm)

Relative
The relative value defines that element will be positioned according to its original position, and will not be removed from the flow of the document. So if we set an elements position to relative and then said left:50px;, we would be moving it 50 pixles to the left of its orgional position, and the space it orgionally took up would still appear to hold that element. So say for instance we added this to the head of our Markup above:

CSS

<style type="text/css">
<!--
.standout {
position: relative;
-->
</style>
}

View Example (http://www.digiffect.com/tutorials/css/relative1.htm)
Nothing would appear to happen. However if we had this:

CSS

<style type="text/css">
<!--
.standout {
position: relative;
top: 10px;
}
-->
</style>

View Example (http://www.digiffect.com/tutorials/css/relative2.htm)
'Hungrily’ would seem to sink a bit lower then the rest of the text, but the space that the word originally took would still be intact, the sentence would not collapse on where the element 'used to be'.

Absolute
Absolute seems to be the hardest to understand, but its similar to relative, but it takes it positioning from its container, so it needs one. Also absolutely positioned elements are removed from the normal flow of the document. The space that would have originally been taken up by the word would 'collapse' because it’s being removed from the flow of the document. So say for instance:

CSS

<style type="text/css">
<!--
.standout {
position: absolute;
}
-->
</style>

View Example (http://www.digiffect.com/tutorials/css/absolute1.htm)
This would cause 'past the butcher shop' to collapse down to 'The dog walked' because 'hungrily' was removed from the normal flow. However there is another problem we face with absolute positioning:

CSS

<style type="text/css">
<!--
.standout {
position: absolute;
top: 10px;
}
-->
</style>

View Example (http://www.digiffect.com/tutorials/css/absolute2.htm)
This would not result in 'hungrily' sinking as it did earlier with relative positioning, instead it would be positioned 10 pixels from the top of your browser!!(Actually the body element) Witch is, ironicly, what it is supposed to do. That is because absolute positioning takes it positioning from its container. You might think that the <P> element is it's container but it is not because an element has to first be positioned first for it to be used as a container so it defaults to the body element as its container. You can easily remedy this by setting the <P> element to relative.

Add this to the CSS example above

p {
position: relative;
}

View Example (http://www.digiffect.com/tutorials/css/absolute3.htm)
Notice that the sentense is still collapsed, (that is just what absolutly positioned elements will do) however the element is now positioned correctly according to the boundries of the <P> element and not the body.

Fixed
Fixed is sort of an oddball, or special case item. It sets its position according to the viewport.(Or in the case of paged media, it would repeat in every page in the same location) So you could do some interesting things with it, like keep your footer visible at the bottom of your pages no matter what size the window is (the most common use for it). Or whatever you could think of.

NOTE: IE does not like to play nice with the fixed property, so you have to suppliment Javascript to get this effect to work properly in IE, bummer. So view the Fixed examples in another browser Mozilla/Opera/Safari/etc...

CSS

<style type="text/css">
<!--
.standout {
position: fixed;
bottom: 0px
}
-->
</style>

View Example, Does not work in IE! (http://www.digiffect.com/tutorials/css/fixed1.htm)
'Hungrily’ would be fixated to the bottom of your browser window(Not the body or HTML element, but the viewport itself) if you used this.


This concludes part one of using CSS for layouts, Next you will see some practical examples of how to use these elements to put together a few common layouts that you could fill with content as your heart desired.

[justlivyalife]

Looks nice! :)

[rosland]

It's obvious from your previous posts that you are quite a CSS capacity!

A continuation/follow-up of this tutorial would be heartly welcomed. :classic:

[splufdaddy]

I agree, some excellent stuff here.

[glyakk]

Thanks,

CSS seems to be my bag these days.. and I have tons of info to dump on everybody. I've never been much of a writer or teacher but I enjoy sharing what I know so I need to get used to it I guess.. :)

For those questioning, I left off the float property as well as z-index. But they will be explained next time. I might extend this to a four part series by splitting up the second part into basic positioning, and another as an excersise in layout discection.

Either way defenatly look for more tutorials on CSS from me. My next one after this will be about another benifit of CSS styling for paged meda (printing).

[Brak]

Excellent! I'd be very glad if someone posted a nice tutorial on using floats/margins/etc correctly to use positioning to your advantage. I've just recently learned how to use this effectively and found it's the best way to lay out pages yet :) Could inform a lot of people how to make tableless layouts really work!

[splufdaddy]

Not that you haven't done enough already, but you can attach an HTML file to your posts with CSS examples for certain things that are easier to show than explain. Good stuff. ;)

[xarst]

Great text about CSS! I've always wanted to throw the tables far away, but it seemed too difficult. I'm awaiting part 2 and 3. :)

[glyakk]

Originally posted by splufdaddy
...can attach an HTML file to your posts with CSS examples for certain things that are easier to show than explain. Good stuff. ;)

Wish granted.. I have updated the tutorial and will add another post soon explaining the float and Z-index property.

[james]

Great tutorial. I'm finding myself slowly moving to the <div>/CSS world, and this should help.

You should write a final example page with a header, side menu, menu items and main-content div.

Oh, I don't mean to be rude, but spell check it! There were a couple of annoying mistakes. But the tute was great.

[groovyjames]

Please do continue the tutorials, this first one is great.

I have started using CSS for styling and positioning and its dead easy and heaps easier than using tables 99% of the time.

[amnesia_180]

Very nice! I have only skim read this tutorial at the moment (still took long enough!) Please do continue the other parts to it.

I have used tables (afterall I am novice) for a while, and they get really difficult when u have lots of images and stuff... maybe this will make things easier!

[RoyDude]

Thanks for this tutorial. I've been eager to jump into tableless design, but had long sought a common sensical intro to the basics, and this more than fits the bill!

Consider it bookmarked! :)

Tx again,
~Roy

[Holokai]

So... Glyakk... about part two, buddy... pal.. :D

*pleads for a part two*
- Chris

[glyakk]

I have not forgotten about this.. just being fashionably late.. :)
I am hoping to have at least part 2 done by next week as well as addition to part one provided I can get some time this weekend to sit down and write it.

It is quite long overdue, and I appreciate everybody's long enduring patience.

[jbagley]

I cant believe it. Ive always used tables, and used CSS just for the fonts on a page.

When i wanted to create the box with a border effect I would make a table with rows and coloumns that I would set to 1 pixel wide so as to create the border effect. Ive just read your tutorial and checked your site out and tried to make the box effect with CSS in dreamweaver.

Its absolutely amazing! Im a converted CSS fan! Cant wait for tut2.

[karinne]

well done on the tut glyakk! keep up the good work! :)

[Stevio]

Can I be the voice speaking against the flow? Having used CSS for various sites, and a few times had to go back to using tables, it is not all a bed of roses using CSS.

Quite often, you end up using workarounds to get CSS to behave in the way you want with your layout. The reason for not using tables is that using tables is a 'workaround'. Partly this is due to the way CSS works, partly it is due to poor browser implementations. Printing especially can look messy when you have used CSS for layout, meaning you either have to design a second print version of the site (using tables perhaps?), and use two stylesheets to show the different version when browsing or when printing, or you go back to tables.

CSS is good, but far from perfect. Using tables is often still the best, and simplest, way to go.

[Trico]

Work arounds or not, the benefits of style sheets totally outweigh the use of tables for creating and maintaining layouts in my mind. Came across this following quote at DevShed, I wouldn't know how to put it any better.

Why people prefer TABLES over CSS
1. B/c they're used to them. They've always used them. They know how to use them. If they can invision it done, they invision it done in tables. (leads into #2)
2. B/c they don't design a site with CSS layout in mind, they design with a table layout in mind.
3. B/c they don't know what they're doing when it comes to CSS layouts and don't want to take the time to learn.
had to go back to using tableshad to? or wanted to?

CSS is good, but far from perfect.Agreed.

Using tables is often still the best, and simplest, way to goWhen it comes down to choice I would rather trouble-shoot a single CSS file than (insert number of pages)+ html documents.

[Stevio]

Well I could have stuck with CSS, and had a page that didn't print right. So then I had to create something that would print right for the same page. There was no easy way to change the CSS, the best solution was to create a hidden part to the page that would only become visible using a print stylesheet. This hidden part would be designed using tables, as that was what was needed to get it printing. So...why create two versions, creating an extra long page size? Simply use tables.

An example of a problem is with 3 column layout, where all columns are to be the same height, but you don't know which column will be the longest. Not a problem using tables.
(http://www.webmasterworld.com/forum83/284.htm)

As for updating multiple pages, that's not a problem either when you are working with a template in Dreamweaver.

There are often too many complicated workarounds when using CSS for layout, that require NO workarounds when using tables. I am not saying do not use CSS, but I am saying that you have to be realistic and realise it has limitations, and that sometimes the benefits outweigh the costs in terms of complexity and workarounds.

I often use a mix of both in my web sites.

[karinne]

have you been on www.zengarden.com ? it's a good site to understand how to have multiple stylesheets and not change the code of the page. that's how you create a workable css version of a site and if you want a print version, then you can create the print stylesheet for it without having to change the code.

anyways... i understand what you mean. it's frustrating sometimes but... once you learn how to do it right (which doesn't come in a day or a week), you'll see that css layout are more workable.

[xarst]

Yes, it's just getting the habits. You are so used to think in "tables" way, that it's difficult to thing in "divs" way.
But, you can also get the opposite effect, that's happened to me, I used to design with tables, and was really pissed off having to use spacer gifs and all that crap.

I still use tables for certain things though, like displaying tabular data (did you read that? tabular->tables ;)) because it's just adding weight to the HTML if you want to create something similar as a table with 4 rows and 8 columns with divs, tables are good for that, but not for hoding 52 tiny images, and when you move one 1 px to the bottom the whole layout get's messed.

[Ionize]

Cool tut, very handy, I'm new to this and it has helped no end. Thanks.

BTW whens the next part coming out?

[TimeBandit]

No doubt tables can be easier. I'll use both depending on the project though i try more and more all the time to only use CSS. It seems to come down to budget - if I have the time I will work on total CSS. It can be very time-consuming to get it right in each browser, especially on the intense designs I work on for my employer.

It also comes down to what you're trying to achieve. I'm usually of the mind that most code purists can take a long walk off a short pier... we're given some standards and many of us strive to adhere but we have to make a living as well. Clients don't want to hear about standards and such. They want the site done yesterday. They really mostly could care less if it shows up well on a BlackBerry, or for disabled users, etc., until it affects their bottom line, such as if/when a disabled group sues them for their site not being accessbile!

But having said that, I have had clients who specifically needed compliant, validated, pure CSS no table code, so it was quite beneficial to me personally to have worked so long and hard to learn how to pretty quickly code CSS. It's still a long haul sometimes, but that's most often because I work on a lot of pages that to a bigger degree than usual do not let the "Web site design" mentally keep them in a box while designing - so I pay the price when making this art into code. It's still the best "practice" in the world, coding a site from someone who hasn't been handcuffed by a "web" mentality... whew!

BTW, way back at the beginning of this thread there is an example of a "sticky footer" but it is noted that it doesn't work in IE. There is a sticky footer example on my site that works in both - not sure if i'm allowed to post a link so just surf into the resources area, October web technique i think.

[Sharp]

Will this ever be updated?

[megablaz0r]

No doubt - that is a nice tut.

glyakk seems pretty busy though, he hasn't been signed in to WDF for over a week as of now.

[Greenhill]

I've come to the sensible conclusion that I need to use CSS rather than tables. One hour ago I was wondering the best way to learn it. Then I find 'webdesignforums.net', become a member, & the first post I read is yours!
Thank You.
Tina :glasses:

[jbagley]

Hi Tina, and welcome to WDF! glad to see the women contingent here at WDF is increasing steadily.

See you around. :p

[megablaz0r]

There are alot more women designers in this field than there were even a year ago. Very encouraging..

Welcome to WDF Tina!

[Greenhill]

Thanks Jason.

[kenny]

really nice stuff around here.
You ppl are great. Thanks !!!


ZZZZZ

[mstocker]

Im loving the tutorial, im learning CSS as we speak, so you have been a great help.

Thanks again.

[Kye20]

Thankyou great tutorial, really helped me yo understand the concept of layouts in css.Keep up the good work :knockedout:
Kye