Hello everyone. As you are about to see I am a complete noob and sorry for asking such a low level question but in the following code how would I get the nav bar to stretch across the whole container div? <p data-height="268" data-theme-id="0" data-slug-hash="BNwOWb" data-default-tab="result" data-user="ASATopGun" class='codepen'>See the Pen <a href='http://codepen.io/ASATopGun/pen/BNwOWb/'>BNwOWb</a> by Brandon Roberts (<a href='http://codepen.io/ASATopGun'>@ASATopGun</a>) on <a href='http://codepen.io'>CodePen</a>.</p> <script async src="//assets.codepen.io/assets/embed/ei.js"></script>
Okay I obviously posted the wrong link. Trying to post a codepen example here. Not quite sure how to do that. <html> <head> <title>Zyeber</title> <link rel="stylesheet" href="css/style.css"> </head> <body> <div id="container"> <div id="header"> <div id="logo"><img src="http://zyeber.com/img/logo.fw.png"></div> <div id="nav"> <ul> <li><a href="#">Home</a></li> <li><a href="#">About Us</a></li> <li><a href="#">Services</a></li> <li><a href="#">Contact Us</a></li> </ul> </div> </div> </div> </body> </html> HTML: #container { margin:0 auto; width: 960px; height: 500px; background-color: rgba(211, 203, 203, 0.71); padding-left: 5px; padding-top: 5px; border: 1px solid black; } #header { } #logo { } #nav { } ul { list-style-type: none; margin: 0; padding: 0; } li { float: left } a:link, a:visited { display: block; width: 120px; font-weight: bold; color: #FFFFFF; background-color: rgba(90, 168, 255, 0.55); text-align: center; padding: 4px; text-decoration: none; text-transform: uppercase; } a:hover, a:active { transition: 1s; background-color: rgba(1, 122, 255, 0.55); } Code (CSS):
Unless declared otherwise, UL is a block-level element. If it isn't floated, it will stretch across the whole container div, which it does. You just don't see it because you didn't wrap your LI floats (give overflow:hidden to your UL) and you didn't give your UL any background coloring. Just so you know, that #nav DIV is absolutely redundant in your markup. Lose it. Your #logo DIV should most likely be an H1, if you ignore rubbish html5 semantics. Also, you should really declare a MEDIA target for your stylesheet, as well as ALT attributes for all your images, not that the logo should be an IMG in the first place.
As @Phil S has said, the ul does take up the full, available width by default. Your list-items ar float, which means they shrink wrap if there's no declared width, and there's no magic number that will spread the list-items the full width of the list container. Here is one solution. There are some gotchas, but is generally robust in modern browsers, and doesn't break badly for older browsers. <!DOCTYPE HTML> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title> Test document </title> <style type="text/css"> /*<![CDATA[*/ body { background-color: white; color: black; font: 100%/1.25 sans-serif; margin: 0; padding: 0; } p { font-size: 1em; } h1 { font-family: serif; font-weight: normal; text-align: center; } ul.main-nav { /* Outline added for clarity */ outline: 1px dotted gray; padding: 0 1.25em; /* top padding added to compensate for generated line */ padding-top: 1.25em; text-align: justify; } ul.main-nav::after { content: ""; display: inline-block; width: 100%; } ul.main-nav li { display: inline-block; } /*]]>*/ </style> </head> <body> <h1>Justified Horizontal Menus</h1> <ul class="main-nav"> <li>item 1</li> <li>item 2</li> <li>item 3</li> </ul> <ul class="main-nav"> <li>item 1</li> <li>item 2</li> <li>item 3</li> <li>item 4</li> <li>item 5</li> <li>item 6</li> <li>item 7</li> </ul> </body> </html> Code (markup): cheers, gary
What people here are saying and/or dodging around could use some explanation. In the simplest of terms, by default wrapping elements (like your DIV and UL) do NOT obey the height of floats inside them. You should also be aware that quite often they also will not obey MARGINS inside them either. There are several ways to get around this: 1) one of the oldest is to put an extra element inside the wrapper like a "clearing div" -- this is generally a waste of code, non-semantic, and generally considered an outdated outmoded bad practice. 2) a big fancy bit of CSS nonsense called "clearfix" - It involves slapping a presentational class and some generated content nonsense on said class; it's a train wreck, just say no. Clearfix and it's kine is a decade and a half out of date. 3) float the parent -- floats obey floats. Since floats shrink if you want it to span the width, you'll need to say width:100%; -- and you may want to add clearing to the element after it. The problem with this is that the normal "box model" used to calculate widths and heights will add any padding or border to that 100% width making it wider than you want it. It's a good option in some cases, but not others. 4) overflow:hidden or overflow:auto on the parent. Auto can make scrollbars show up which is often undesirable, so hidden is usually the more common choice of the two. Elements set to overflow:hidden will wrap floats inside them. Beware that IE6/earlier do not have this behavior (technically IE7 and 8 don't either) but you can add what's called a "haslayout trigger" to mimic it. IE8/earlier "haslayout" fixes a lot of issues. It's a concept unique to IE stemming from an old (IE4 era) shortcut they took to try and make pages render faster. Elements that "have layout" take the time to calculate all their values every time new data for the layout is parsed, while those that don't only calculate when they are encountered during rendering. While there are several haslayout triggers such as width and height, the most reliable is to simply say "zoom:1;" -- A LOT of developers used to get their panties in a knot because zoom is "vendor specific" and not part of the CSS specification, but in the age of endless pointless vendor prefix asshattery like -webkit, -moz, etc, etc that ALSO are not officially part of the CSS spec, you can pretty much tell the handful of people clinging to that objection where to stick it. OF course if you give a flying purple fish about IE8 and earlier users, you can skip that. Really though if adding 6 characters to your CSS is a "big deal" there might be something wrong with the CSS. Zoom can also trigger a condition called "zoomfix" that's unrelated to haslayout that... well, it's hard to say when that bug will rear it's ugly head. Again, we're talking Internet Exploder here, unpredictable doesn't even begin to cover the headaches you deal with farther back you go in versions. There's a reason even M$ is trying to kill it off. Some other observations -- as mentioned you seem to have a number of "DIV for nothing"; tags like UL are perfectly good block level containers so it's rare you really need that extra DIV around it. Even that IMG tag probably doesn't need the extra DIV, though it's hard to say without seeing said image and the rest of the layout. It's even unlikely that being a logo the image even belongs in the markup as that's presentation -- it is far more likely it should be a <h1> with the text the logo represents, then using an advanced technique like gilder-levin to place the logo over the text hiding it. If you need clarification on that, just ask. I would REALLY suggest you avoid floating the LI unless you REALLY need them to have block behavior, and inline-block on them is rarely a winner either since legacy IE can't make block-level tags be inline-block. There's a particularly annoying bug in IE8 (or was it 7, been a while since I've seen it) where floats with blocks inside them have what's called the "staircase effect'. Best bet is usually to set the LI to display:inline, and then either float or inline-blokc the anchors inside them. WAY more predictable and reliable cross-browser. With targeting anchors, usually it's best to simply say "A" for all the common values instead of individually hitting :link and :active -- in fact your hovers SHOULD be losing their float state when hovered which could result in some strange behaviors. In that same way your transition only being on :hover means it should only animate when you hover it, when you mouse-out the animation will NOT show -- not sure if that was your intent. Looking at your codepen (since the URL is in there) it's also usually a bad idea to declare a fixed height -- fixed width and fixed height designs are accessibility rubbish. You should be designing a fluid width with a max-width so long lines aren't too long (that's called "semi-fluid") and doing so with your measurements in EM so it's based on the default font size instead of pixels. This CAN make some design elements (like massive fixed-width images) be "not viable for web deployment" -- that's not necessarily a bad thing. Putting that all together... <!DOCTYPE html><html lang="en"><head><meta charset="utf-8"> <!-- tell mobile browser we know what the **** we're doing --> <meta name="viewport" content="width=device-width, height=device-height, initial-scale=1" > <link rel="stylesheet" type="text/css" href="screen.css" media="screen,projection,tv" > <title> Zyeber Technologies </title> </head><body> <div id="top"> <h1> <a href="/"> Zyeber <span>Technologies<span><!-- image sandbag --></span></span> </a> </h1> <ul id="mainMenu"> <li><a href="#">Home</a></li> <li><a href="#">About Us</a></li> <li><a href="#">Services</a></li> <li><a href="#">Contact Us</a></li> </ul> <!-- #top --></div> </body></html> Code (markup): I call the DIV #top so that if you want to add a "back to top" link, it's just <a href="#top"> -- it's quick and easy. The H1 is for semantics since a h1 means the heading under which everything on the page is a subsection, hence it having text. The image would be placed over it using the nested span. The outer span is there to make it so you can style that text to resemble the image for when images are disabled. Both H1 and UL are perfectly good block level containers, so we don't need extra DIV there. When possible it's good practice to use up as many of your semantic containers for styling BEFORE you resort to adding DIV and SPAN which are 'semantically neutral'. Remember that DIV and SPAN do NOT imply any more meaning to the text they wrap than classes or ID's do, none of them provide "semantics" as semantics are instructions to say what the content IS, or WOULD BE in a professionally written document. This is a concept rarely found in online tutorials and buried in many books (if you can find it at all) but it's what "semantic markup" is about! B and I means WOULD BE bold or italic in a professionally written document, just as EM and STRONG mean "emphasis" or "with more emphasis"... HR means a change in topic, not "draw a line across the screen". A LOT of people just crapping out websites any old way (and I'm talking so called "experts" who should know better and have done it this way for a decade) never grasped this concept and choose their tags based on the default appearance, NOT the meaning. As you'll hear me say a LOT, "If you choose your tags based on their appearance and not their meaning, you are choosing all the wrong tags for all the wrong reasons". In fact, this is why I advocate writing the COMPLETE HTML for a page using it's content or a reasonable facsimile of future content before you even THINK about applying style to it using JUST the semantic tags, only adding DIV and SPAN where/when needed during the application of style. In any case, when it comes time to style that I would also suggest using a reset. There are tiny resets like the so called "universal" one of * { margin:0; padding:0) -- but that can cause headaches with some form elements in IE and FF. There are larger resets like Eric Meyer's "reset reloaded" -- but that's a fat bloated train wreck that borders on being a "framework" and wastes time doing things that have NOTHING to do with a "reset". The one I used was developed by Dan Schulz (RIP) and hits just what needs to be hit. You also seem to be using a LOT of alpha transparency -- I ALSO suggest not doing that either, particularly on things like logo's since they are incompatible with image-replacement methods that gracefully degrade. Either way an alpha transparent .png tends to be significantly larger and in the age of bandwidth caps taking our wonderful broadband age and dragging it kicking and screaming back to the performance of 1998, mated to how much larger image files can impact your hosting costs, It's just something to avoid for all but the simplest of things. It can be the difference between having a megabyte of images and 32k worth -- for example that logo ALONE I'd probably have down as a tiny little 2k 16 color png. Along those same lines, the blue on grey and white on blue texts are below accessibility miniumums -- I'm leaving those alone for now but it's something to address. There's actually math for determining legibility, if you are unfamiliar with it ask, and I'll post up another copy of it and/or link to it. Between the colours and the transparency you are ASKING for legibility issues, so that's something I'd suggest you look into and learn about. The CSS I'd be using for what you are trying to do there likely going something like this: /* RESET margins, padding and borders to give good cross-browser baseline */ html,body,address,blockquote,div, form,fieldset,caption, h1,h2,h3,h4,h5,h6, hr,ul,li,ol,ul, table,tr,td,th,p,img { margin:0; padding:0; } img, fieldset { border:none; } /* tell certain mobile devices we know what the **** we are doing!!! */ @media (max-width:480px) { * { -webkit-text-size-adjust:none; -ms-text-size-adjust:none; } } /* end RESET */ /* It's good practice to set the line-height a bit taller for legibility, I find 150 to 160% ideal. 85% works out to 14px/17px/20px for major browsers based off 100%/125%/150% scaling providing good accessibility. I also suggest using sans-serif fonts when possible on screen for content since screens usually lack the pixel density to render complex glyphs clearly. Say it with me, serif is for print, sans is for screen! Setting the font for the majority of content here means we only need to adjust it for elements that are different. It's just good practice to do it this way. I also advocate just using the whole condensed propery instead of the separate values just as a reminder to change the line-height EVERY time you change the font-size, since you CANNOT trust inheritance on that! */ body { padding:1em; font:normal 85%/150% arial,helvetica,sans-serif; /* believe it or not, you can't always trust these to be the defaults! */ color:#000; background:#FFF; } #top { min-width:48em; /* for pre CSS3 browsers */ max-width:68em; /* adjust this for the needs of the content! */ margin:0 auto; padding:0 0.25em; background:#E0DADA; border:1px solid #000; } h1 { /* width also trips haslayout, fixing rendering bugs legacy IE */ width:298px; /* Height of this element will be calculated off the two different line-heights and paddings. Trying to fix the height of elements with text inside them is an accessiblity no-no. one of the few times pixel measurements for font-sizes is acceptable is behind a image replacement technique like Gilder-Levin */ font:normal 64px/64px arial,helvetica,sans-serif; } h1 a { position:relative; /* allow nested span to APo off the top corner of this */ zoom:1; /* trip haslayout, fix IE positioning bugs */ display:block; text-decoration:none; text-transform:uppercase; text-align:right; letter-spacing:2px; padding:12px 5px; /* 12px top + 12px bottom + 64px line-height + 28px line-height - 6px margin == 110px desired height */ color:#8BE; } h1 span { display:block; /* force this to it's own line */ text-transform:none; margin-top:-6px; /* ride this text up closer to the blue name */ font:normal 24px/28px arial,helvetica,sans-serif; color:#000; } h1 span span { position:absolute; top:0; left:0; margin:0; width:298px; height:110px; background:url(images/h1Logo.png) 0 0 no-repeat; } #mainMenu { list-style:none; overflow:hidden; background:#9BE; } #mainMenu li { display:inline; } /* NOT stating the psuedostates means this targets ALL anchors inside #mainMenu */ #mainMenu a { display:inline-block; text-decoration:none; padding:0.25em 0.5em; color:#FFF; /* transition here means both in and out - I HIGHLY recommend not having excessively long (more than half a second) transitions, they become more hindrance than help at that point. */ transition:color 0.3s, background 0.3s; } /* :focus is for keyboard navigation -- some older browsers incorrectly use :active for this so it's best to just nab the three of these together! */ #mainMenu a:active, #mainMenu a:focus, #mainMenu a:hover { background:#6AE; } Code (markup): I documented the hell out of it to explain the how/what/why of most of the choices made. I also tossed up a live demo on my server. (Since codepen screws with the code too much and I hate the tiny little window nonsense) http://www.cutcodedown.com/for_others/designAce/template.html As with all my examples the directory: http://www.cutcodedown.com/for_others/designAce/ is wide open for easy access to the gooey bits and pieces. I know that's a lot to take in, but take your time, have any questions ask. There's a LOT of nuances to HTML that you won't find in tutorials or books right now -- sadly that's why so many websites are poorly coded. That's ok though, you came, you saw, you asked.