I cant seem to figure out why my simple two button navigation wont fall in line with my site container formatting.
YOu’ll see a subtle vertical line in the right side of the header image, that is where the two button divider should align when complete.
HTML
www.fentonmedical.com/indev.html
CSS
www.fentonmedical.com/css/indev.css
Thanks for any help.
Just wondering: shouldn’t div id=“nav” be inside div id=“header”?
Let me give you this CSS code:
#nav {
}
#header {
position: relative;
margin-top: -20px;
background: url(../img/fmc_header.png) no-repeat center;
height:111px;
}
and this HTML code:
<div id="header">
<div id="nav">
<a class="latehoursbutton" href="latehours.php"></a>
<a class="staffbutton" href="staff.php"></a>
</div>
</div>
Now, see, the code above may seem to be an improvement, except with the way your page is now, it’s a roulette game trying to position the nav inside header.
You need to reconsider your layout. The way you gamble now with px margins will never lead you to a valid solution.
Honestly, I’ve been moving around the html elements so much trying to figure this out that, they may just be where it was left during my last head scratching session. Im really clueless as to why it wont fall in line. I’ve even stripped the html and css down to the bare essentials in another set of files and it still refuses. I know its my error, just not sure how.
Hmmm…
I don’t know if I’m not wasting my breath here, since you don’t seem to have many clues about it, and that you go blind in hope to catch it. But you should make the #sitecontainer a fixed width, put #nav inside #header and float it right. Then tinker to position it where you’d like it to be.
#sitecontainer {
width: 763px;
margin: 50px auto;
text-align: center;
}
#header {
position: relative;
background: url(../img/fmc_header.png) no-repeat center;
height:111px;
}
#nav {
float:right;
}
My best bet for you would be to use a template.
This works:
[HIGHLIGHT=“”]
<div class=“rbcontent”>
<div id=“column1”>
<div id=“nav”>
<a href=“latehours.php” class=“latehoursbutton”></a>
<a href=“staff.php” class=“staffbutton”></a>
</div>
<!-- in-line style here for clarity only –>
<p><br style=“clear:both”>
<span class=“bodycapsgreen”>Who We Are.</span><br> … etc.
I really appreciate your help, that took care of the problem.
Would you elaborate on the error of using px margins?
In case you can’t tell (sarcasm), I am a designer first developer (cough) notsomuch but I do my best.
Would you elaborate on the error of using px margins?
I will.
You’re fighting physics and against yourself the way you’re using margins. For example your hours wouldn’t need to be pulled halfway across the page except that you’ve put text-align: center on the parent. I’m not sure why you did that; maybe to fight the old IE5 problem? So now all your text wants to sit in the middle when it would have been sitting on the left.
Then the tagline, which is kind of delicate because that text can be any size on any particular browser (so it can cover up the green area possibly), would make sense floated right and inside a box containing the logo as a background image… followed by the two buttons.
*edit although if you kept it on top above the logo and kept the negative bottom margin, you do keep the advantage of the text-bottom remaining right at where the green area goes down, so that bottom margin’s not a bad idea.
Good that you’re using an image sprite (on the buttons), but you should add :focus to your hovers. It’s a good rule of thumb anyway: wherever you have hover styles (on something clickable), add focus as well.
I haven’t really figured out why column 2 is absolutely positioned. What happened?
Anyway, you might be able to go a long ways before any of this brittleness hits you because your page is fixed width and everything in it is fixed too. So it’s already very stiff and your weak point then is text (which can grow and shrink and wrap in browsers).
Generally what you can reasonably get away with is keeping the sitecontent fixed px width and the two containers, but let everything else get placed with document flow and let it go where it needs to.
Is there a different/better way to center-align the site in the browser window?
Im onto another issue now. My display is just as it needs to be in Safari but obviously it needs to be correct in IE and it’s not. My content is pushed further right than it should be.
http://www.fentonmedical.com/indev.html
http://www.fentonmedical.com/css/indev.css
Thanks again.
Your code is so confusing.
step 1: remove the relative positioning… unless that’s there for some child to get absolutely positioned?
step 2:
float: column1 left.
step 3: remove the weird margins on column2. It’s floated right already. Set margins to 0 for now.
step 4: make sure their combined widths and sidemargins, if any, fit inside rbcontent’s total inner width (so minus any sidepadding it has).
step 5: remove the height setting on rbcontent. Setting heights on things filled with text content is a bad idea. Instead, to make it enclose the two floats in non-IE-under-8 browsers, give it overflow: hidden. To trigger haslayout in IE 6 and 7, set a width on it (just look at the width set by mainbgcontainer, and see what it’s total inner width is (so minus sidemargins and sidepadding it may have… that’s how much room there is inside for rbcontent. Remember any sidepadding on rbcontent counts as it’s total width!).
Whatever comes after these two column1/2 floats should clear: both in the css.
After you do that, we can check in IE. I believe the column1 is centered in IE7 because IE has an old old bug: it will center blocks inside someone with text-align: center. I have no idea why you have that set anyway: if you want center alignment in a box, only set that on that direct box you need the alignment in, not parents.
So step 6: remove the text-align center on sitecontainer: you have way more text you are aligning left than center anyway, so this is not a helpful rule.
Just leave everyone at their default text-align: left, and only put it where you need it, like column2.
Thank you for the continued help, I realize looking at my css makes you want to claw your eyes out.
So am I correct in assuming that when I removed the text-align: center from sitecontainer that the reason it remains centered is the margin: auto?
I’ve tended to all your suggestions I believe and changed all but img dimensions to em’s.
Is it looking better?
I know I still have work to do. I haven’t checked IE again yet but even Firefox on Mac has the two buttons a touch too far right currently.
I realize looking at my css makes you want to claw your eyes out.
No, it’s confusing but it’s also simple. I claw my eyes out looking at the CSS for frameworks like Drupal with classes like “block clear block-block clear-block block-clear-block-block” running around.
So am I correct in assuming that when I removed the text-align: center from sitecontainer that the reason it remains centered is the margin: auto?
Ah, yes: so you were trying to use the text-align: center for box. Text align is different from the automargins in that, text-align is something you put on a block parent to center the inlines inside it while automargins go directly on the block you want to center.
So yes: you can center any block so long as
-it’s a block (and a static one: positioned absolute or floated elements can’t auto-margin)
-it’s got a non-100% width
The main chunk of the page is centered in all browsers. IE6 and 7 also accept automargins to center boxes, but if you don’t have a complete doctype they will act like IE5 who did not understand automargins… this why older sites are still using text-align: center on the body element. Long ago that was the only way to center blocks in IE. But you have a doctype and aren’t trying to make your site look good in IE5 so automargins for everyone. IE6 and 7 are just unfortunate in that they still center blocks who are inside someone with text-align: center.
I’ve tended to all your suggestions I believe and changed all but img dimensions to em’s.
Well, let me say this:
I write most of my boxes in em’s. However this has bitten me and it can bite you. There are advantages to em-based layouts but they will change from machine to machine because the font-size affects those em units. Which can be good or bad.
It’s almost always bad if you’re using ems but also with px. Since your main box is set to a width in px, you don’t want those two columns to be em’s. In machines where the default font size was set very small, you may get two columns sitting fine, but on my machine with Large Print settings (which some of my browsers inherit and others don’t, lawlz), one column must drop under the other because they are too wide to fit side by side. This is what I’m seeing in my Firefox here.
I checked IE7 and there actually the columns are side-by-side, because col2 is just sitting on top of column 1. But, they aren’t actually fitting, they’re just being weird there. They look ok but aren’t.
If you are just starting out using em’s for box dimensions (I almost always recommend em’s or % for text! but I’m talking now about boxes), you might not want to do that here if this is a client site. You might want the col1 and col2 boxes to have px widths, so you can count out the total px and make sure everyone can fit. Floats can sit side-by-side but if there’s not enough room for them to do so then you get float drop.
Or, if you’re feeling adventurous, you can keep em’s on those but then also use em’s for the main container. If all the boxes are in em’s then you can calculate again: if the parent was, say, 30em wide, then it can hold two boxes who are say 20em and 10em wide each… if there’s margin between those, then their widths must be less: 18em and 9em or something.
But in a px-width container it’s hard to measure how many em’s will fit in there, because that will be different per computer.
You might run across an idea that you can calculate px-to-ems by setting the font-size on the body to 62.5%. This is false but still gets spread around: ideally IF the user’s default font-size in their browser is 16px, then 1em would be about 10px. Even though many browsers do ship with that as the default font size, the user’s windowing system (I’m using Gnome on Linux, but there’s KDE, non-X11-based windowing like RatPoison, there’s whatever Macs use, and there’s many settings on Windows.
So I leave the default font-size at 100% and just keep everything proportional in em’s or %. But I feel fairly confident when I do it because I’ve done it several times and I’ve gotten through a lot of problems I initially had with them (you get surprises).
In general px-based layouts are brittle because almost all browsers can enlarge text. Text should be flexible. But English is a language with short words and text can wrap so setting px widths for the main containers can be an acceptable solution for this site for your client. Don’t set heights. What was bad about your px were more your negative margins and attempts at precision positioning using position: relative and the negative margins. Your layout looks like it can be rather straightforward: excessive positioning and lots of negative margins comes along in layouts trying to do impossible things, tricks, fun stuff or as demos of something. You can keep it simple.
So, decide if you’re going to go for the em’s for everything or px for major containers, and make them all so.
I’d say, since you’re using a width and automargins on sitecontainer, you do not need to set any width or sidemargins on mainbgcontainer at all: as a block element it will try to fill 100% of its available space (which is limited by sitecontainer).
Your header has the same thing: it won’t be able to be wider than sitecontainer.
Column 1 and 2 need calculated widths: either sitecontainer is set in em’s and then cols 1 and 2 have em amounts that can fit, or keep sitecontainer in px and set cols 1 and 2 in px. Either way, the same unit so you can measure. col1 by me is dropping, but by you it may fit.
Here’s a great tip: when dealing with floats, give everyone involved ugly background colours so you can see how wide they are. You’ll see right away which measurements actually fit and which don’t. I use this trick all the time: I don’t need to worry about Firebug or whatever developer tools, because I’ll see my containers’ widths in ALL browsers.
Let us know.
Thank you for that explanation, that box bg color tip was simple and effective.
It’s definitely getting close as now my only issue with Firefox on PC and Mac is the two buttons are just a touch lower than they should be(and are in Safari).
IE on PC still has two glaring issues, the bottom rounded corners of the main dark container are totally out of place and those damn buttons are stacking on each other. Does IE require my #nav to have a set width or something?
It’s definitely getting close as now my only issue with Firefox on PC and Mac is the two buttons are just a touch lower than they should be(and are in Safari)
Well the “too low” thing you can fix by either removing or just reducing your top margin. Right now it’s .5em. Try 0.
Second, instead of floating it left and pushing it to the right with a large left margin, why not float it right? (Or did you do that and get a weird result?)
IE on PC still has two glaring issues, the bottom rounded corners of the main dark container are totally out of place and those damn buttons are stacking on each other. Does IE require my #nav to have a set width or something?
Yes I see in IE7 that it’s shrink-wrapping the #nav container and so then the floats inside are forced to stack. Do indeed set a width equal to or a hair bigger than the total width of the two buttons.
I think the problem with the rounded-corner images in IE is two things:
rbcontent has overflow: hidden, which is good for modern browsers because it makes that box wrap your two floated columns, and it’s good for IE7 because it triggers Haslayout in that browser which does about the same thing. IE6 is left in the dust though: if you are writing for that one too you’ll need something else to trigger Haslayout there since overflow: hidden isn’t a trigger for 6. Now I did say you don’t have to set widths on boxes if they are intended to be as wide as their containers. This is one of those times where you might write down a (redundant) width just to trigger Haslayout. If you’re supporting 6 (and I did not look in 6), you can probably get away with adding
width: 100%
since it’s doing 100% right now anyway, and you’re safe to declare that here because there are no side margins or padding on that box. Here, 100%=100% : )
Then, Haslayout must not be enough for IE7, so rbbot might have to then also actually clear those floats.
Try giving it clear: both.
Nice, the clear: both on rbbot worked for IE.
I switched the nav from floar: right to left just to get away from using a negative em on positioning, not sure what the standard rule is when choosing to float left or right?
I still can’t get those buttons to position identically in Firefox and Safari. It looks proper in Safari and in Firefox it’s still down just the slightest bit. I can live with that.
The last IE issue I am having is it placing the buttons much higher than other browsers. Adding a width to the nav got them in-line again but now their placement is just much too high.
Im also confused about why those two buttons in IE are creating a opaque white box over the part of the header they are on top of? Clues?
Thanks for your continued guidance, its been awesome and I feel Im really picking up on stuff for once.
I switched the nav from floar: right to left just to get away from using a negative em on positioning, not sure what the standard rule is when choosing to float left or right?
It’s not any rule, really, it’s more “what’s the least amount of work you can get away with”. If I were given a picture of this website and told to code it, I probably would have had the tagline inside the header, for example: then if it were the only text in the header I could maybe either float it, or set text-align: right on the header or the p inside the header holding the text.
Having it first before the header and then pushing it down with a margin would look mostly the same, but it’s more “positioning” to me I guess. It means we have to take the header and the background image it’s holding and figure out how to let it “slide up underneath” the tagline (and pushing it down “over” the header is then the same thing).
So, usually if I have a container and I want the stuff inside to sit to the right, if that stuff is a box then I’ll probably float it right. If it’s a series of boxes to sit next to each other then I’ll propably float them left and let them stack up against each other… and then if they need to all be sitting to the right I’d either pad the left inside of their container, or give them a wrapper and float that whole wrapper to the right.
I guess it’s more to do with how you start seeing the DOM after staring at it for several years. There are probably developers out there who prefer large margins and positioning than floats or text-align. Depends on the design, depends on what the design is supposed to do at different screen sizes, depends on how fixed the layout is.
I still can’t get those buttons to position identically in Firefox and Safari. It looks proper in Safari and in Firefox it’s still down just the slightest bit. I can live with that.
Not sure but possibly a text-size or font-size difference between those browsers… since I believe in those modern browsers the floated nav is bumped down by the floated tagline.
The last IE issue I am having is it placing the buttons much higher than other browsers. Adding a width to the nav got them in-line again but now their placement is just much too high.
They don’t seem to be “seeing” the tagline above them.
Also I notice the #header, even tho it’s set to block, isn’t expanding completely to 100% width.
I think this is because of how IE incorrectly deals with margins, margin-collapse, and floats.
The tagline is floated right and then pushed down over the header… and so any floats inside the header need to be aware of that tagline and stay under it. IE allows margins to collapse on floats (when it shouldn’t) and also has a nasty bug where floats in the same direction don’t clear each other.
So setting the header (who is not floated) to clear could fix that in IE, but then the clearing would also force the header under the tagline.
Im also confused about why those two buttons in IE are creating a opaque white box over the part of the header they are on top of? Clues?
In IE7 it looks to me more that the header actually is stopping (rather than getting covered by white). IE6 is doubling margins on that #nav box (adding display: inline right after the “float: left” line magically fixes this bug in IE6, even though it should be ignored by all browsers).
The more I look at this design, the more I worry that it’s too image-based to deal well with em’s for box sizing.
Your positions depend heavily on those background images, and images are set in px-based dimensions. So while the text itself should remain flexible (even though this means users who need larger font sizes will have a broken page…), the boxes are always going to be a little off if sized in em’s between browsers and OSes because the box size is based on the font size, which differs even between browsers (rounding errors) and OSes (available fonts).
You have a smaller font (arial) in the same font stack as a larger font (verdana). In the (unlikely) event that someone has Verdana on their computer but not Arial or Lucida, your em-based setup will get too big when Verdana is the main font.
Here’s an idea of one way to do your header. It sticks mostly to em’s except in a few places because of your header background image:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<title>Fenton Medical Center</title>
<meta name="description" content="Fenton Medical Center" />
<meta name="keywords" content="Fenton Medical Center" />
<link rel="shortcut icon" href="favicon.ico">
<style type="text/css">
* {
margin: 0;
}
body {
padding: 5em 0;
color: #fff;
font: 100% arial, lucida, verdana, sans-serif; /*percentage font size stops an IE bug*/
background: #f3f3f3;
}
#sitecontainer {
width: 59.7em;
margin: 0 auto;
font-size: .9em; /*bring font-size smaller like you wanted*/
line-height: 1.3em;
}
#hours {
margin-left: 1.4em;
color: #8cc63f;
font-weight: bold;
}
#header {
width: 776px; /*setting a width in px because of img*/
min-height: 111px;
background: url(fmc_header.png) 0 0 no-repeat;
}
#header p {
min-height: 25px; /*size of divit in image*/
color: #404040;
font-weight: bold;
text-align: right;
}
#header ul {
list-style: none;
float: right;
width: 22em;
border: 1px solid #8dc640;
-moz-border-radius: .5em;
-webkit-border-radius: .5em;
border-radius: .5em;
}
#header li {
display: inline;/*this is pretty much to stop an IE bug, no other reason*/
}
#header a {
float: left;
width: 12.5em;
padding: 1.6em .5em;
color: #fff;
font-weight: bold;
text-align: center;
text-transform: uppercase;
text-decoration: none;
background: url(fmc_button.png) 0 0 repeat-x;
border-right: 1px solid #8dc640;
}
#header li+li a {
width: 7.3em;
border-right: 0;
}
#header a:focus, #header a:hover {
background-position: 0 -62px;
}
</style>
</head>
<body>
<div id="sitecontainer">
<p id="hours">OPEN M-F 8:30AM-5:30PM</p>
<div id="header">
<p>Serving our community for over 69 years.</p>
<ul>
<li><a href="latehours.php" class="latehoursbutton">Late Hours Clinic</a></li>
<li><a href="staff.php" class="staffbutton">Staff</a></li>
</ul>
</div>
</div>
</body>
</html>
http://stommepoes.nl/medical.html
Because of the em sizing, even this code results in small differences between browsers… how large the tagline is, the height of the buttons. I tried border-radius just to see if it could work ok… it’s not bad but would work better in px if it really needs to match that background image.
Also I put text in the buttons and styled them, since right now you have no button text. If the image doesn’t load for some reason, or the user can’t see images, those links are unknowns. I just threw in there a repeated png but the one you have has rounded corners… and you can see that is a small problem.
IE6 is not catered for in this code, mostly because in your version it looks like you’re supporting IE7 and above (I see nothing to fix the png issue… which, that image can be a flattened PNG instead of one with transparency… which brings the filesize down from 6.2kb to 2.9… nice).
If I were supporting IE6, every time I had “min-height” I would follow with a * html height declaration… and I would put a class on the second anchor in the nav so that I could style it as IE6 doesn’t recognise + selectors.
And, I probably would have a background image with rounded corners like you have, but then the buttons would HAVE to be sized in px, no other way around that.
But anyway, the above is an example to show how I see that content… another developer may do things quite differently. You could try something similar to mine.
So, general rule:
-text should be set in a flexible unit…em and % are recommended. I keep this simple to avoid weird inheritance problems (since an em is based on whatever 1em is of its parent… and I hate math).
-containers ideally would also be set in em’s or %, except where they must have px-based margins or padding (since trying to add those up is difficult to impossible)
-designs that are strongly image-based might not be able to have em-based containers unless there is a lot of sliding-doors (bits of images held at the corners of various elements to allow growing/shrinking boxes to maintain their overall look). Keeping the text flexible and the boxes in px to match background images means that while a bunch of text-enlargment might be okay (text grows, wraps, and ultimately gets “taller” on the page), eventually the text will be too large to fit in those px boxes and the design will break.
On that last note, in my designs I’m generally ok with design breaking if the text is still readable, since that’s ultimately the user’s goal, to read your page. But it does mean I check to see if, for example, light-coloured text falls out of a dark-coloured box and into a light area… I may have to give that text a background colour to keep contrast acceptable. Since this background-colour is invisible while the text is still contained inside the dark container, it’s win-win… but when there are gradients things start to suck : (