Good morning, lads! Popping by with another question. So, I'm started coding my new website design and bumped into something that used to be no problem for me a couple of years ago - coding a horizontal navigation bar. To be more exact, positioning and styling it. So, here are some screens to make things easier to understand/foresee. This is how it is supposed to look in the end. It's vertically centered and it fills the gap between the logo and the right side of the header (note, that the width of the spaces between the logo and the right side are equal (roughly 46-48px)). Well, there comes the problem. I have absolutely no clue how I should position it there. Here you go - the HTML, CSS codes and also the result that is shown in the browser. HTML: <!doctype html> <!-- Coded for Kurkime.lt by Dominykas Bartauskas also known as "Sacrive" --> <html> <head> <meta charset="utf-8"> <title>Kurkime.lt | Pagrindinis</title> <link rel="stylesheet" type="text/css" href="styles/default.css" /> <link rel="icon" type="image/png" href="favicon.png" /> </head> <body> <div id="core"> <div id="header"> <a href="http://www.kurkime.lt" name="Kurkime.lt | Pagrindinis"> <img src="images/header_logo.png" alt="Kurkime.lt" class="header_logo" /> </a> <ul class="navi_top"> <li class="navi_top"><a href="#" class="navi_top">Pagrindinis</a></li> <li class="navi_top"><a href="#" class="navi_top">Renginiai</a></li> <li class="navi_top"><a href="#" class="navi_top">Forumas</a></li> <li class="navi_top"><a href="#" class="navi_top">Galerija</a></li> <li class="navi_top"><a href="#" class="navi_top">Literatūra</a></li> </ul> </div> <div class="header_folds"> </div> <div id="main"> </div> </div> </body> </html> Code (markup): Then, there is the CSS code: /* ------------------------------------------------------------------ */ /* */ /* Coded for Kurkime.lt by Dominykas Bartauskas also known as "Sacrive" */ /* */ /* ------------------------------------------------------------------ */ body { background-color:#1d2026; background-image:url(../images/bg_00001.jpg); background-repeat:no-repeat; background-attachment:fixed; } div#core { width:1120px; min-height:1020px; margin:20px auto; } div#header { width:1118px; height:80px; margin:0 auto; background-image:url(../images/header_bg.png); } div.header_folds { width:1118px; height:52px; margin:0 auto; background-image:url(../images/header_folds.png); } div#main { width:1064px; min-height:940px; margin:-52px auto; background-image:url(../images/main_bg.png); background-repeat:repeat-y; } ul.navi_top { list-style-type:none; margin:0; padding:0; } li.navi_top { display:inline; float:left; } a.navi_top { display:block; width:80px; } img.header_logo { width:; height:; margin:20px 60px; background-image:url(../images/header_logo.png); } Code (CSS): And here's what I see in the browser: Could someone point out what I'm not doing right here and maybe point me into the right direction or show me an example how to do it properly? Would be a great help! Looking forward to the replies, Kind regards, Sacrive
Well... there are several things wrong - first off, you shouldn't have the same class on different items (ul and li) - second, you don't need to have both display: inline; and float: left; - one is enough. The problem is that you have the <a> and <img> inside the header, which pushes the ul down. Rethink the design - and besides, the logo is just text - why don't you just use the actual font, instead of an image?
Well, you've got a number of issues here -- part of it being outdated code, part of it being invalid code, and part of it being bad design practices. You are working in a fixed width design; fixed widths are ignorant rubbish -- as is dicking around in a paint program drawing pictures before you have semantic markup. You should be working on a semi-fluid elastic responsive layout, not a fixed width design made of choppped up images. Your images so far are presentational affectations, so they really have no business in the markup... and it looks like your image version has a massive background, a bit of bandwidth wasting nonsense I'd not be putting on a site in the first place. You are using images for text when we now have webfonts -- I would SERIOUSLY put thought towards using those instead, though that fancy script runs the risk of legibility issues be they as images or as a webfont. Once you slice up all those images and implement their states, it's likely the webfont would probably be at least the same size. In the markup you have content before you even have a H1... aka "the heading under which everything on the page is a subsection" using "old semantics", and lack a HEADER tag for "new sematics / pointless code bloat 5-tardery". The NAME attribute on an anchor is for hash tag targeting and ... well, that's about it. Spaces are invalid in it, special characters like periods and vertical breaks are a bad idea --- so... did you mean for that to be a TITLE attribute? Generally if you have to use the TITLE attribute or put text into an attribute like that, there's something wrong with the content of the tag. (like say, an image in the markup that's not content) Then there's your list, which to be frank has endless pointless classes for NOTHING; or at least nothing if you understand the "cascading" part of "cascading stylesheets". You are also lacking media targets for your stylesheet, have a pointlessly vague stylesheet name, a DIV doing what generated content could probably handle for you, and I STILL wouldn't use PNG for a favicon... and the presence of the TYPE attribute on that favicon LINK most likely is breaking it in legacy IE. (not that legacy IE supports PNG as favicon in the first place). So first, let's fix your markup. I will retain the 5-lip service doctype even though I'm pretty much going to treat it as 4 Strict. (just because actually using 5 just introduces pointless code bloat thanks to the re-introduction of old redundancies and creation of new redundancies -- write 4 strict or x1.0 strict, then deploy as 5 if you're having some bit of 5-tardery shoved down your throat!) <!doctype html><html lang="lt"><head> <meta charset="utf-8"> <link rel="shortcut icon" href="favicon.ico" > <link type="text/css" rel="stylesheet" href="screen.css" media="screen,projection,tv" > <title> Pagrindinis - Kurkime.lt </title> </head><body> <div class="widthWrapper"> <div id="top"> <h1><a href="/">Kurkime.lt</a></h1> <ul> <li><a href="#" class="current">Pagrindinis</a></li> <li><a href="#">Renginiai</a></li> <li><a href="#">Forumas</a></li> <li><a href="#">Galerija</a></li> <li><a href="#">Literatura</a></li> </ul> <!-- #top --></div> <div id="main"> <!-- #main --></div> <!-- .widthWrapper --></div> </body></html> Code (markup): Gimme a few minutes, and I'll belt out the CSS I'd be using with that.
... and here we go. I went with a solid blue background as a placeholder, but the transparencies of the 'inlets' and content area are retained. I used a stock webfont from fontSquirrel as well. http://www.cutcodedown.com/for_others/sacrive/template.html As with all my examples the directory: http://www.cutcodedown.com/for_others/sacrive/ Is unlocked for easy access. Semantic markup, semi-fluid elastic responsive layout, and gracefully degrading since it was built with progressive enhancement. In other words, IE8 and earlier don't get rounded corners, OH WELL. Doesn't even need images to function -- slap your background image on that and you'll see it does what you are thinking. Also try it out at different widths and notice how the layout strips off the fancy stuff while trying to retain it's usefulness at smaller sizes. IF (big if) I have time later I'll write up a breakdown of the how/what/why of the HTML and CSS for you so you can better understand the choices I made.
I've got some free time so here's a quick breakdown. If you look at the markup: I like to condense tags that should NEVER have anything else be between them as a reminder that, well... there should NEVER be anything else for tags between them. Since the 5 lip-service doctype is so tiny and the language and namespace declarations are tiny, this lets us condense doctype, HTML and HEAD to a single line and still be clear. I added the lithuanian language attribute so that your site will be correctly identified for it's language. For the favicon be sure to use a .ico for maximum compatibility. People like to dick around with like five or ten separate png files for every possible apple combination, seriously? Waste of code, waste of bandwidth, etc, etc... Particularly when .ico can hold multiple image sizes. It also helps to say both "shortcut" and "icon" as the REL so older browsers see it, and to omit the TYPE attribute The link to the CSS I added all the various screen media types. Some devices still report TV or mix their own "TV" sheet with screen if you don't say TV. Wii for example is notorious for this. Likewise many browsers report themselves as projection instead of screen in "kiosk" mode or even full screen operation, so it's good to nab all three. IT's also VERY important to say "this is for screen only" so that you aren't sending it to places where your screen layout is pointless or doesn't make sense -- like PRINT and AURAL; though sadly both IE and FF are jackasses about this and use SCREEN for everything, then make thier own dumbass changes that don't help anyone. Again, </head><body> condensed so we don't accidentally try to add markup between them. div.widthWrapper -- outermost container so we only need to set the width constraints once. I use a class for this since it's unlikely we'd need to target it with scripting or with a hash. div#top -- the wrapper for the header I call #top so if desired on something like a "back to top" link you can target it with a hash link. It's just a sensible name for it. h1 -- the heading under which all content of the page is a subsection; whenever possible a h1 should be the first text containing element on a page, and if following logical document structure you should only have ONE h1 on an entire page since again, it's the top-most heading everything is a subsection of. Just as a H2 indicates the start of a subsection of a h1, h3 is the start of a subsection of a H2, and so forth. That's why skipping over heading numbers (h5 with no H4 or H3 preceding them) is gibberish. HR also has a role to play in that it indicates a change in topic/section where heading text is unwanted/unwarranted. Numbered headings do NOT mean "text of different sizes" even if that's the default appearance just as "HR" does not mean "draw a line across the screen" #top ul -- the menu UL that follows needs no classes on anything except the ONE menu item that's different as it's the current page. (I guessed that's what that little white dot meant.). We can use #top to target it. From there I retained the content area just for testing the little side "inlets" which as presentation I'd generate in the CSS not the markup.... and then we just close out the remaining DIV and BODY+HTML. Oh, and notice the commenting style? I don't do "begin top" type comments because that's what <div id="top"> means -- you can't figure that out you probably shouldn't be writing HTML. The closing comments I use # or . so I know what class or ID on generic tags like DIV are being closed. I don't say "End #top" as again, that's what </div> means. (seriously, some people's comments are some serious herpafreakingderp) The comment is placed before the closure as in some versions of IE and FF comments between sibling level elements can trip rendering bugs. Yes, comments - the things that browsers are SUPPOSED TO IGNORE... can trip rendering bugs. The biggest two being "disappearing content" (which does exactly what it sounds like) and "double render' (which, well...) -- usually floats or inline-block have to be involved, and if you are unaware of this bug it can drive you BAT-**** insane trying to diagnose when it does rear it's ugly head. (particularly in IE8/earlier). A lot of times people throw CSS hacks and IE conditional comments to get around what could simply be fixed by moving the comment before the close. If it's before the closing tag, it can NEVER be between sibling-level elements. Ridiculously simple, easy and clear to follow fix. ... and that's the markup. On to the CSS. Follow along with: http://www.cutcodedown.com/for_others/sacrive/screen.css First thing in there is the webfonts. For SOME goofy reason some older browsers screw up if webfonts aren't the first thing in the stylesheet, so we get that out of the way first. Whatever font it was you wanted to use on the page, use a service like font squirrel to turn it into webfonts for you. I suggest adjusting their parameters to still include SVG as older iPhones and iPods that are no longer getting updates won't use any other format. Laugh being that for something people rant and rave about being so wonderful in CSS3, it's compatible all the way back to IE 5.0 and a decade before CSS3 was a twinkle in the W3C's eye. I then have a reset -- there are bigger resets like Eric Meyer's "reset reloaded", but that fat bloated train wreck does nothing but give resets a bad name and is the driving force behind the people who say "don't use resets". There are smaller resets like the so called "universal" one of "* { margin:0; padding:0; }" but that can drive you nuts as it changes form elements like input and textarea, which are already enough of a headache to put properties on cross-browser without making it worse. hr -- as mentioned HR have a semantic meaning of a change in topic. Usually we apply some other visual style for that so we hide them for screen media. When they are in the markup they are for semantics and non-visual or non-CSS user agents to provide document structure. I usually include this from the start since usually pages have a footer, and if that footer doesn't have any headings then there should be an HR before it to say it's not part of what comes before it. *NOTE* these H1..H6 and HR rules I'm stating come from the use of such elements in professional writing on which HTML was originally based. Providing document structure using the EXISTING elements are why I consider HTML 5's SECTION, NAV, HEADER and FOOTER tags to be pointless redundancies and code bloat. @media (max-width:480px) -- many smaller display IE and Safari devices screw with the font sizes. Since we know what we are doing we don't want that, so we disable it. Thankfully I've never seen this problem on higher resolution systems so we can target this with a media query as sending this to desktop resolution Safari breaks the ability to zoom.... It also proves how jacktarded Apple's coders are since it does not break zoom on iOS devices, it only breaks it on desktop OSX. body -- padding to push in the width wrapper, set the default font to be used on the majority of the page content, and the background. I like to set the font as little as needed -- 90% of what's on the page for font size and face should be declared HERE and inherited. Some advice, if you change the font-size set the bloody line-height or you WILL have your layout broken somewhere at some point at some time. There's a MYTH that you can omit a metric and just say "line-height:2" and it will inherit properly, and that's BS. It will break somewhere. Since saying "font-size:100%; line-height:150%;" is almost as long as the full font declaration, that's why I use the condensed version and state everything. Despite my ranting and raving about minimalism, I'll take clarity over saving a half dozen bytes any day. Part of why I consider white-space stripping to be sweeping crappy code under the rug, as if you have enough code for it to provide significant savings, you've probably done something WRONG -- like using some dumbass preprocessor or some ignorant halfwit framework. I also like my line-heights a bit taller than most people, it aids in clarity and in following longer lines when they wrap, hence the 150%. I use % for font-size here (and across the entire page) as much as possible so that the font will dynamically scale to either the OS or browser preference. Not all computers are set up with the same default 16px font size of windows/OSX. The laptop I'm on right now starts out at 20px because I set it for that (1920 wide at 17" is ridiculous unless your head is plastered 6" from the display)... and my media center with it's 10' interface is set to 24px. The Sun Blade 2000 in the garage defaults to 12px since it's a 19" display at 1152x836. That's what %/EM are there for since you can usually set the font size in the OS, and smart browsers (aka real Opera, not ChrOpera) will pick up on that -- AND you can set it in the browser in most every case it's not picked up from the OS. That's called "dynamic fonts". .widthWrapper -- this is where some of the real magic happens. A minimum and maximum width are declared so that the layout expands and contracts between those two points. No fixed width idiocy allowed in here. That's called "semi-fluid layout". These minimum and maximum widths are declared in EM, where 1EM == the declared font-size. So when those fonts auto-scale to the browser setting so does the entire layout! Cool, no? That's called "elastic layout". Of course, the margin just centers the widthWrapper. The minimum width is there for browsers that don't support responsive layout / media queries (basically IE8/earlier). We can change that for media query browsers later. It MAY be worth adding an elastic fixed width for IE6/earlier if you REALLY care... I left that out for now. #top -- I set up float wrapping using overflow for modern browsers and zoom for older versions of IE. Simple, reliable, easy, and why in 99%+ of cases there is NO legitimate reason to be pissing on the markup with clearing DIV or nonsense like "clearfix". Without this #top would ignore the height of the floats we place inside it as they are "not in flow" for containers. (though floats are in flow for CDATA/textNodes -- which is VERY confusing when first starting out with CSS). The center alignment becomes useful at narrower display sizes when we kill off the floats (we'll get to that shortly), and from there it's just colors and style. #top a -- I styled all anchors in #top, both the H1 an the menu the same way for consistency sake. Slightly darker than pure white, with no underscore. #top a:active, #top a:focus, #top a:hover -- the hover states. :active is SUPPOSED to be when the element is currently clicked on waiting for the next page to load or if the hash is currently followed. Sadly some older browsers use this for when the element is focused by keyboard navigation so we want to include it here. :focus of course is when it's focused by keyboard navigation, and hover is when the mouse cursor is over it. Switching it to pure-white means there's a hint of something going on in legacy browsers that can't do text-shadow, while using text-shadow for a subtle "glow" is an easy and attractive effect to aid in navigation. h1 -- since there should only ever be one H1 on a page, it's pretty easy to target it without getting complex. Floating it left means whatever's after it will ride up next to it. From there it's just size and padding. Using that webfont means we don't need any fancy image, we just size and pad it using those same dynamic/elastic EM and % measurements... remembering that since we are doubling the font-size the padding's should be half what they normally would be. #top ul -- as mentioned before, as the only UL in #top we don't need any classes or ID's to target this! (cool, huh?). Turning off bullets is no big deal, and floating it right puts it up against the right edge of the display opposite the left floated h1. I increased the font size to 125% as that's an easy number to use... as 1 / 1.25 == 0.8, so for sizes and padding at BODY scale, we just use 80% of the value. #top li -- again, no classes needed. LI are a pain in the ass to style thanks to IE8 having this pesky bug called "staircase effect". For that reason if I'm not making a dropdown menu I just set them to display:inline and then pretend they aren't there. Again, we want them for semantics since a menu is a list of choices (the actual MENU tag from HTML 3.2 being deprecated as redundant to UL), but since it's hard to style, just inline it and forget it. #top li a -- we use the LI in this selector to make sure we're setting values for it and not the H1 since it too would be a "#top a". The relative positioning allows us to have any absolute positioned children base left:0 and top:0 on the upper corner of this element instead of the page. This will be handy when we do #current. Once again I added zoom:1; as a haslayout trigger to trip rendering bug fixes in IE. If you don't care about legacy IE8 you could remove all those, but honestly the handful of bytes it takes is no big deal if it means you can deliver a page that still works in older browsers without too much effort. I set them to inline-block so they can still get top/bottom padding and obey line-height consistently but appear as a single line. Some people might float them, but it works either way. Half an EM body-scale padding usually looks about right on menus, but as I just mentioned we're at 125% font-size so that half an EM body is actually 0.4em locally. #top li a.current:after -- More magic. Using :after we can "generate content" -- in this case a bullet character (utf-8 0x2022). Since text is already centered we can "center" this bullet by setting a width, setting it to text align, pushing it left 50% and then sliding it back 1em with a negative margins. Negative margins are a POWERFUL layout technique, as they reduce the size of the element in "flow" while leaving the size it's rendered at the same. This can be used to fine-tune positioning like we do here, or to make it easy to have elements overlap each-other. I switched it to arial as the bullet in that webfont was kinda funky looking. So we can mark the "current" item with that dot, without doing anything in the markup more than a class. This also means we can apply DIFFERENT styles for current without changing the markup. (and that's a good thing). #main -- the content area I put a min-height on just so we can see it for now. The relative positioning is for those little "inlet" triangles to be absolute positioned off this element. The side margins should be the same as those triangles. I used rgba for transparency here with a solid fallback for browsers that predate that bit of CSS 2. #main:before, #main:after -- these two share a lot of common values so declare them together. Generated content of an empty space makes sure it renders in all browsers (empty will sometimes be ignored). The overflow:hidden and 1px font-size addresses IE and FF occasionally being dumbasses about element sizes, and from there we just set 0 width, 0 height, and 0 top. We can pull a little trick of borders to create the triangle, using a 2:1 slope that should look reasonably smooth on modern systems without the need for anti-aliasing. I used opacity on these to make them transparent instead of RGBA for legacy support, and that RGBA is often slow on borders in some browsers. (FF in particular). Then we do two more selectors for :before and :after each with the values that are unique for the left and right elements, specifically positioning and on which side to show our border... than thanks to the bevel of "solid" borders allows us to fake a triangle. @media (max-width:52em) -- I tossed a responsive layout on there because I could. When the screen is too small we just strip off the background-revealing padding on body, lower the min-width for browsers that support media queries, and then kill the floats on the header area so that everything is one-atop the other centered auto-adjusting to the available space. A quick tweak of the padding in the header, margins on main and removing the inlets makes as much screen space available to the content as possible -- important on small displays. ... and that's it. Pretty simple. Hope that helps. I know it's a lot to take in, any questions fire away.