Absolute and Relative Positioning

February 16, 2004 | View Comments (12) | Category: CSS Focus

Summary: Absolute and Relative positioning in CSS.

This weekend I was working on a mini-project that forced me to work with absolute and relative positioning. Since I am a designer who 99.99999% of the time works with floats I found this quite interesting. What I had to do was take Kalsey's tabs code and make it work for a fixed width, centered design. Everything that I am going to discuss has already been written about in the wonderful article, Making the Absolute, Relative by Bowman, but I figured I would give it a shot and try to explain these properties of CSS positioning.

Relative Positioning

First let's keep in mind that the key to this code is we want the submenus to always be placed below the tabs so that it actually looks like tabbed menus with submenus. When working with CSS, text flows normal with regards to the screen of the website. I found that it doesn't flow with the html body of the page because even if I made the body have a width of 720px along with centering it, the submenus still were positioned relative to the screen.

Therefore, when no elements are declared as relative then any absolute positioned elements are placed in accordance to where you set them on the screen. Obviously, I didn't want the submenus to follow the normal flow of the screen, but the flow of the tabs above them. Since the submenus are positioned within the tabbed menus in the code (gotta love semantics), I made the tabbed menu <ul>'s postion relative.

#nav-tab {
border-bottom : 1px solid #ccc;
margin : 0;
padding-bottom : 1px;
padding-left : 10px;
position: relative;
text-align: right;
}

Now the submenus should follow the tabbed menus around where ever I decide to take them, but only after I give them an absolute position.

Absolute Positioning

When using absolute positioning make sure to remember that you have to position it using either top, left, right, or bottom. I gave the submenus an absolute positioning using top and right:

body.section-1 #nav-tab ul#subnav-1,
body.section-2 #nav-tab ul#subnav-2,
body.section-3 #nav-tab ul#subnav-3,
body.section-4 #nav-tab ul#subnav-4 {
display: inline;
top: 1.8em;
right: 1em;
position:absolute;
}

So now the submenus are positioned 1.8em's from the top of the tabs and 1em from the right of them no matter where I decide to position them. This is effective because it also keeps them positioned properly when a user decides to increase the font size.

The only major issue I am having with the code is the extra 1px that IE decides to give the tabs. If anyone could correct that situation that would be cool. Next, I am working on making a header type effect where the whole bottom border extends the width of the screen while keeping the tabs "centered". Hopefully, I haven't confused the whole world.

UPDATE: Forgot to show you the working example ;) CSS Tabs with submenus. Also here is the full header example I am working on.

Trackback URL: http://9rules.com/cgi-bin/mt/mt-tb.cgi/150

Comments

#1

Care to add fixed positioning to the list? It's much easier to explain and would cover the entire set of CSS2 positioning options.

David House

#2

I guess I will have to do that after I solve this problem.

Scrivs (http://www.9rules.com/whitespace/)

#3

Addressing the issue of extending the bottom border completely across the screen maybe you could use absolute positioning to position elements to the right and left (and possibly overlaping) of the outerFrame element. I've did a quick mock-up (it isn't perfect) here, http://www.policyscape.com/test-3.html (right only)

It looks fine in Mozilla/Netscape, but it's one pixel off with IE.

This might also be a problem if the user attempts to increase the font size, but if we allow sufficent room to move (increase the height of the header) then we might avoid breaking the line.

Greg Farries (http://www.mapleleafweb.com)

#4

Doesn't any design with absolute positioned elements eventually break when the user increases the font?

Placing your layout in a #container (or #pagewrap) at for example 780px alleviates the issue somewhat, but even then. I suppose the issue is just what font size is the perfect font size. I know this has been addressed before in several articles, but really, I don't think there is any "perfect" font size.

I know my Dad for instance increases his font to at least 14px (estimated) and despises sites that use fixed font sizes. He'd much rather have a percentage designated.

I've created XHTML/CSS compliant designs in 1024x768 (my ideal resolution for now) and then when I look at the design on a monitor set to 1280 or so the design looks off. Despite this hinderance, it doesn't prevent me from experimenting with the design until it looks similar at all resolutions (except 640x480).

And, now I'm wondering what the perfect resolution is, any ideas?

kartooner (http://www.kartooner.com)

#5

one little thing... You should use javascript:; instead of # when you want a link to nothing... using # jumps to the top of the page, javascript:; simply does nothing.
Not a big deal when you're working on a header, but when you need one halfway down the page, it's a big plus.

JC (http://thelionsweb.com/weblog)

#6

"Doesn't any design with absolute positioned elements eventually break when the user increases the font?"

Not if you work with ems ;)

Alex H.

#7

Yeah, back in the day, people didn't realize that it jumped to the top because they were all making 800x600 designs with IFRAMEs. :-D

Tom

#8

If we're nit-picking, I might as well say that you'd be better off using either javascript:void(0); or simply adding return false; to an onclick event for the current urls. Not sure about just using javascript:;, though. For simple tests, I personally would probably just use the # as well...

Ryan Brill (http://www.ryanbrill.com/)

#9

Not if you work with ems

I've got a prototype of my CSS tabs that is completely flexible. Everything's relatively positioned, tabs grow with the font size, the visual effect isn't dependant on a particular size or position, nothing depends on a browser hack, and it's all done in two lines of CSS code. Okay, maybe I'm fibbing about the two lines of code. The CSS is actually a beast.

The only reason it isn't released at this point is that it isn't as fully tested as my existing tab code.

Adam Kalsey (http://kalsey.com/)

#10

javascript:; is a shortcut for void. :-)
And you don't use it in onclick, you use it in href.

And I'm terribly sorry if you consider it nit picking, Ryan. I mentioned it because it's useful, not because the lack of it wholly ruins Paul's work here and brings about the eventual heat death of the universe.

JC (http://thelionsweb.com/weblog)

#11

Sorry, I think I came across wrong. Didn't mean to put your post down at all. I more meant that I was the one nit-picking, as it really was a small issue. :)

I'll take you word for it, that javascript:; is the same as javascript:void(0);, as I'm not sure.

However, javascript: is not technically a valid protocol for a URL as far as I can tell (http://www.ietf.org/rfc/rfc1738.txt). One should probably not use either method (javascript:; or javascript:void(0);), but rather a #, with a return false; in an onclick, as I suggested above.

Ryan Brill (http://www.ryanbrill.com/)

#12

Funny you posted this yesterday. I posted this the same day. I had actually come up with it a week before but didn't get around to posting it because I wanted to make it look nice. It still doesn't, but I have a few other priorties, like making my weblog look good (it needs it badly). As I'm not using this navigation for anything at present, it didn't seem so important.

waylman (http://www.achinghead.com)

Keep track of comments to all entries with the Comments Feed