Fixed size css navigation buttons?

I want to make a horizontal navigation for a site using buttons. I’ve managed to find some decent ready made navigation css on the web, that I could easily modify, but all the ones I’ve seen fit the padding either side of the text, so the buttons or tabs are all different widths because they are dependent on the text inside the <li></li>

Anyone know how I can make buttons so that each li item is a fixed height & width, so that I can make matching buttons, or perhaps point me to a tutorial somewhere?

Thanks :slight_smile:

You can use that approach just by setting a width on the <li>s in the menu, but be careful - it is very easy to break this layout by changing the amount of text, or by users changing the font size on their computers (which you have no control over). And it can look messy and unbalanced, because what people will notice is that different buttons have different amounts of white space on them, rather than that they are all the same size.

Stevie’s trying to say that something like this may happen to you also :wink: Sorry SitePoint…

Haha that’s funny :stuck_out_tongue:

So I guess if I really want the look, I should probably just make the images. A bit of a trade off in aesthetics vs seo I guess.

Thanks for the reply :slight_smile:

I don’t think they were saying don’t do it like that but just be careful and test that what you have doesn’t break like the image noonope provided.

In most cases I find that fixed width and height “buttons” actually initially scale better than fluid width ones if done correctly and if enough room is allowed. Don’t use tiny widths or heights that just fit the text but allow enough breathing space so the text can expand inside the button.

A button that is defined by its content will in the other hand grow and shrink as text resized and more often than not breaks other things along the way at first resize.

Here’s an example using both methods and you can see that the first demo using fixed width and heights allows about 4 resizes before things start to break or move.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
<html xmlns="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<style type="text/css">
ul {
    margin:0 auto 50px;
li, a {
li {border:1px solid #000;}
.test2 li, .test2 li a {
.test2 li a {
    padding:10px 22px
<ul class="test1">
    <li><a href="#">Link text</a></li>
    <li><a href="#">Link </a></li>
    <li><a href="#">Link Longer</a></li>
    <li><a href="#">Link text</a></li>
    <li><a href="#">Link xx </a></li>
    <li><a href="#">Link xxxx</a></li>
    <li><a href="#">Link last</a></li>
<ul class="test2">
    <li><a href="#">Link text</a></li>
    <li><a href="#">Link </a></li>
    <li><a href="#">Link width Longer text </a></li>
    <li><a href="#">Link text</a></li>
    <li><a href="#">Link xx </a></li>
    <li><a href="#">Link xxxx link xx</a></li>
    <li><a href="#">Link last</a></li>

On the other hand the fluid width and height element breaks to another line immediately and would ruin whatever followed next in that section.

Of course the second version can be resized almost infinitely and the text will still be accessible but in the first version you start losing the text after about 5 resizes.

As usual there is a trade off between what’s accessible and what works for the layout in question. I’m happy if the text can be enlarged a few sizes but the layout remains intact.

There is also the issue that we could use ems for height and width and then the button can scale uniformly but that would mean the rest of the layout would need to be in ems also and is not always easy to accomplish well. Even though ems are preferred a lot of users find layouts that scale out of the viewport inaccessible anyway so you would still likely impose a max width in pixels.

The bottom line is that whatever method you use you should always stress test to make sure it stands up to the demands that it will receive.

Yeah, the main pages here at sitepoint are filled to the brim with those types of issues. As a large font/120 dpi user I see them all the time – it just part of why I consider the main part of the website a write-off and just skip to the forums.

The “fixed width for nothing” design and 177k of markup to deliver 9.9k of plain text being just another indicator that for a site who’s motto is “become a better web developer” they still have a long ways to go in terms of their own development work – could be worse though, could be the spinoff sites where it’s invalid tranny code and 30:1 code to content ratios combined with the oh-so-wonderful “WCAG, what’s that?” attitude.

Ok, enough SP bashing :stuck_out_tongue:

ON topic, IF you do fixed width and height, set the fonts in PX metric, you CANNOT rely on %/EM or PT for those elements without it breaking somewhere – this is why fixing the height on anything content related is usually a miserable failure at web design. See that “looking for help” section in the screencap noonnope posted for an example of that in action. (when there’s NO excuse to not have word wrapping AND dynamic height on that element apart from some artsy fartsy painter being given too much control).

In that way those types of visual elements are what I like to call “not internet viable”. They break – a lot – to the point where it’s not worth even TRYING to do that in the first place, no matter how much one’s inner artsy child might want it.

Really though we’d have to see exactly what it is you want them to look like before we can really point you at an answer – everything so far is a wild guess. You might even be able to keep them dynamic width if you use an effect like sliding doors…

For example lets you have styled end-caps with a tiled center – which IMHO is the pinnacle of web design as wherever possible elements should remain dynamic… like on menu buttons for example it would really stink to have to try and go back a year from now to add or remove one if you make them all separate static images.