SitePoint Sponsor

User Tag List

Results 1 to 5 of 5

Hybrid View

  1. #1
    SitePoint Enthusiast cluongo's Avatar
    Join Date
    Jun 2011
    Location
    Atlanta
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    List Positioning/Word Space Help

    So here's my problem:

    I'm trying to center my list within a "navbar" which consists of a Photoshop made image that is 960px by 35px. I originally had it set as the background image for the navbar and gave it the width and height listed above.

    I noticed when I added padding, the image stretched. I couldn't center my navlist in the middle of the image. So I put the height as 29px to add padding that added up to 35px total. Is that an okay way of centering navbar text? Or is there a better?

    Also, how do I put some space between all the links in the navbar.

    Here is the site: Untitled Document

    CSS/HTML attached:

    Code:
    <!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>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Untitled Document</title>
    
    <style type="text/css">
    
    body {
    	background: black;
    	margin: 0px;
    	padding: 0px;
    }
    
    #container {
    	width: 960px;
    	height: 1000px;
    	background: #fff;
    	margin-right: auto;
    	margin-left: auto;
    }
    
    #header {
    	width: 960px;
    	height: 150px;
    }
    
    
    #navlinks {
    	margin-right: auto;
    	margin-left: auto;
    	text-align: center;
    	background-image: url(nav.jpg);
    	height: 29px;
    	padding-top: 6px;
    }
    
    #menu {
    	list-style-type: none;
    	padding: 0;
    	margin: 0;
    	color: #fff;
    }
    
    #menu li {
    	display: inline;
    }
    
    #menu li a {
    	font-size: 12px;
    	color: #fff;
    	text-decoration: none;
    	font-size: 17px;
    }
    
    #menu li a:hover {
    	background: #906;
    	color: #330;
    }
    
    
    </style>
    
    </head>
    
    <body>
    <div id="container">
    
    <div id="header"><img src="banner.jpg" /></div>
    
    <div id="navlinks">
    <ul id="menu">
    	<li><a href="#">Home</a></li>
        <li><a href="#">About</a></li>
        <li><a href="#">Products</a></li>
        <li><a href="#">Support</a></li>
        <li><a href="#">Contact</a></li>
       </ul>
       
    
    </div>
    
    
    <div id="content"></div>
    <div id="footer"></div>
    </div>
    </body>
    </html>

  2. #2
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    the outer wrapper looks like it is full width, so you shouldn't have to say the margin on it -- NOT that it should even be in the markup in the first place. The UL is a perfectly good block level container, you don't need to slap a div around it.

    For browser compatibility reasons I would never state height and padding at the same time -- in general you are using some methods that may break cross browser... like not explicitly declaring your line-heights...

    My approach to that type of menu is to strip bullets off the UL, apply the background to the UL, set text-align:center on the UL -- and that's IT there. Set the LI to display:inline; as you are doing, then on the anchors set the font-size AND a line-height that's 10-20% taller than the font-size, then set the anchor to display:inline-block so it can accept padding top and bottom.

    NOWHERE would I declare height -- instead I'd let my line-height plus padding equal the desired total height when combined.

    Said method being a lot less prone to breakage. When I'm back at my desktop I'll toss together an example of that.

    You may also want to consider using a heading for your heading, not putting the presentational image in the markup, providing images off graceful degradation, using a modern doctype so you aren't in transition from 1997 to 1998, and a wee bit more meaningful a name than "container".

  3. #3
    SitePoint Enthusiast cluongo's Avatar
    Join Date
    Jun 2011
    Location
    Atlanta
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Awesome thanks, looking forward to seeing your example and I'll get back to this guy and fix it up.

  4. #4
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Sorry for the delay in getting back to you on this... Busy weekend. I'm going to cover a lot more than the menu.

    Here's a demo of what I mean:

    Vision 1 Desktop

    as with all my examples the directory:
    Index of /for_others/cluongo

    is unlocked for easy access to what I did. I re-saved the logo image at 5% loss to get the filesize under control, cut the tiled background down to a normal size for the menu, and added a hover state to the menu image as the bottom half of it.

    As you can see, the HTML doesn't need many of those extra wrappers, and does things a bit differently. It starts out with a MODERN doctype instead of being stuck in 1998... includes media types appropriate to this styling so we're not sending this to print or other devices where it might not make sense... You'll also notice closing comments -- adding closing comments makes it clear what's being closed, I use # and . to say class or ID just like you would in CSS there. I don't say "close" because that's what </div> means, I don't say it on semantic tags since, well... they're tags that have meanings. I put the comment BEFORE the closing tag because there's some odd bugs with comments in most every version of IE and some minor point releases of FF that can cause extra block-level containers to be thrown in the DOM (FF) or worse, can cause the content to fail to render or even render twice (IE).

    but the real changes come in it's guts.

    Code:
    	<h1>
    		Vision 1 Desktop<br />
    		<small>Desktops / Laptops / Repair</small>
    		<span><!-- image replacement --></span>
    	</h1>
    That image is a presentational affectation of some text, as such it really has no business in the markup. It's also the first heading on the page of which all other headings should be treated as subsections -- that's H1's job. By adding text and using the small-tag to de-emphasize the tagline we give search engines and screen readers something to look at -- and we can apply styling for the people who browse with images disabled and CSS on. The empty span we can then position over that text to apply the image. Since there should only ever be one H1 on a page, we don't need any classes or ID's or extra wrapping DIV.

    The menu:
    Code:
    	<ul id="mainMenu">
    		<li><a href="#">Home</a></li>
    		<li><a href="#">About</a></li>
    		<li><a href="#">Products</a></li>
    		<li><a href="#">Support</a></li>
    		<li><a href="#">Contact</a></li>
    	</ul>
    Gets the id directly on it. UL is a perfectly good block level container so there is no reason to be putting an extra DIV around it. That's just a waste of code -- even if it is so common a practice they came up with some shtickdrek excuse to justify doing so with the completely useless "nav" tag in HTML 5...

    You'll also notice I threw in some HR -- I use those to break up sections for people who browse with CSS disabled. I set them to display:none globally -- you want to use them in the content, turn 'em back on.

    On the CSS side, I start out with a reset so I don't even have to think about the oddball and different margins/paddings/borders on elements across browsers. there are bigger ones, they tend to defeat the point of using CSS and are a waste of bandwidth. There are smaller ones, they tend to break form elements. There are people who say "don't get in the habit of using resets" -- it usually takes them days to do what I do in five minutes.

    On body I set text-align:center first so IE 5.x will center #pagewrapper... I know, IE5.x who cares? how about all the people with windows mobile phones more than two years old? That's right, until two or so years ago the most recent IE for win mobile was 5.5, and they JUST got 6.x at that time. (and we wonder why Opera on mobile is so popular). It's one extra line that if we take care, means we can support all the way back to IE 5 with little to no extra effort than it takes for 6, 7 or 8. (see why I think IE conditionals for CSS is BULL... Javascript, working around the **** implementation of OBJECT, sure. CSS, not so much)

    From there I set up the font I'll want across most of the page -- I advise against trusting the default font, I advise against using a serif font on screen. Serif good print... not good screen. Mongo like screen... You'll notice I set both the size (85%) and the line-height (140%)... the first of those gives us 12px for 75dpi users, 14px for 96dpi users and 17px for large font/120dpi users -- which for arial and helvetica seems to be the idea. You use other fonts, you'll want to play with that.

    The h1 gets position relative and width:100% to trip haslayout -- this lets us position that child span appropriately in relation to it. I do a text-transform to make it match the styling and give it some pretty colors for images off users.

    The height of the H1 is calculated using padding and line-height rather than explicitly stating it. As a rule of thumb I try to avoid saying heights on any container with text in it... they tend to break otherwise. The small tag inside the h1 gets display:block so that it's line-height only equals what's declared inside it. Failing to do so will space it out to the 48px used on the h1.

    39px top padding + 48px line height + 24px line-height +39px bottom padding == 150px -- the height of the image being placed over it.

    The span is again where I applied the heading image. It's just absolute positioned over it with the logo image centered inside it.

    #mainMenu I strip bullets off of, and set a px metric font. PX for fonts is generally an accessibility /FAIL/ on content -- it's why the WCAG says "DON'T DO THAT!!!" -- but when you want to interact with a background image you aren't left a whole lot of options in that department. When forced to do so by a image interaction I recommend 12px as the smallest you should EVER consider, and then do all-caps.... 14px is a little...twictchy, but it's very unlikely even large font/120dpi users will ***** about 16px bold text being "too small"... We also set a background color here for images off users, and tile the background image.

    #mainMenu li -- this I just strip formatting by setting to inline. As a rule trying to style LI cross browser is a pain in the ass, and should be avoided unless you REALLY need to make a dropdown menu out of them.

    #mainMenu a -- inline-block on these lets us add top/bottom padding. Since on #mainMenu I made it 18px line-height, 9px top and bottom padding gives us 36px total height, whcih I changed your background image to. As a rule of thumb, try to use multiples of 4 for heights and 8's for widths, as they tend to compress better when saving as .png or .jpg.

    Oh, also note I made the background image a .png since it only consumes 234 bytes that way, instead of the 16k jpeg you had there.

    #mainMenu a:psuedos -- for the hover/keyboard states I just set the background color darker for images off users, then slide the background position up. This reveals the bottom half of the image file allowing you a graphics appearance when hovering those buttons without using a separate image file. More files == more handshakes to the server which means slower page loads.

    The rest of it I just tossed some styling on as examples. Notice I pad the top of the content area, but the bottom of the P tag. I do this instead of using margins so as to avoid any margin collapse headaches once floats are involved.

    Hope this helps.

  5. #5
    SitePoint Enthusiast cluongo's Avatar
    Join Date
    Jun 2011
    Location
    Atlanta
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Wow. What a response. Thanks a bunch I appreciate this and this definitely helped shed some light not just on the navbar but other issues I was facing.

    One hell of a response.

    Thanks again for the explanation and files.

    -Chris


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •