Here is the site I am building.
It looks fine in every other browser (well excluding IE6) except for IE7. My nav menu is a ul element and has about 70px padding-left, IE7 is treating that padding as a margin, why???
here is a screenshot of it in IE7 which I got from browserlabs.
DeathShadow, wow! I only just came across your replies to my posts, I’ll have a read of these just now. Really appreciate your time and help, thank you 
Hi,
You haven’t removed the default left margin.
#navigation-menu{
width:828px;
list-style:none;
height:55px;
margin-top:0px;
padding-left:73px;
[B] margin-left:0;[/B]
}
Always set the margin and padding to zero so that you start on an even keel
Also remove the xml declaration from the top of the page as that will trigger quirks mode in IE6. it’s optional in pretend xhtml anyway.
[B]<?xml version="1.0" encoding="utf-8"?>[/B]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
The doctype should be the first thing on the page as far as Ie6 is concerned.
e.g.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
You seem to have gone overboard on the child selector which IE6 doesn’t understand and in 99% of the cases is unneccesary in your code. (I can’t actually remember the last time I needed to use it )
thank you 
I guess all the other browsers ignored the default margin then but IE7 didn’t?
regards to the child selector, thanks for the info, I didn’t know that IE6 didn’t recognise it. Is there a list of browser supported CSS things anywhere? Also, how would you style instead of using child selectors then, would you give the elements IDs or classes? I always use child selectors.
So, how do you increase specificity then? If I want to overwrite something that has been styled by some other rule, I simply be more specific so instead of #item, I’d say #parent-item>#item, to make this rule overwrite the other one.
No the problem is that other browsers use padding for the default bullet space whereas IE uses margin for the default bullet space. That’s why I said you should always remove the padding and margins on elements you use because browsers apply defaults and these are defaults that they think fit. They are not the same between browser and they don’t have to be as there is no rule.
This is the reason that a lot of users use reset stylesheets to negate the browser differences but in truth all you need do is set the margins and padding every time you use a new block element (apart from divs which don’t have any default). See the FAQ sticky thread on reset stylesheets.
regards to the child selector, thanks for the info, I didn’t know that IE6 didn’t recognise it. Is there a list of browser supported CSS things anywhere?
Also, how would you style instead of using child selectors then, would you give the elements IDs or classes? I always use child selectors.
A child selector styles only matches all elements that are the immediate children of a specified element. The common place for using the child selector is in nested lists when you only want a style to apply to the top level children only and not the nested children (as in drop down menus).
However 99.9% of the time you want to style all descendant selectors of the element and not just the immediate children.
For example this rule:
div {background:blue}
div.test > div {background:green}
<div class="test">I have a blue background</div>
<div class="test">
<div>I have a green background</div>
</div>
<div class="test">
<div>
[B] <div>I have a blue background</div>[/B]
</div>
</div>
The div in bold doesn’t get coloured green because only immediate children are affected by the rule.
If you remove the child selector then all inner divs will be green:
div {background:blue}
div.test div {background:green}
<div class="test">I have a blue background</div>
<div class="test">
<div>I have a green background</div>
</div>
<div class="test">
<div>
<div>[B]I have a green background[/B]</div>
</div>
</div>
99.9% of teh time that is what you want so just use descendant selectors (which is just white space space between selectors).
So, how do you increase specificity then? If I want to overwrite something that has been styled by some other rule, I simply be more specific so instead of #item, I’d say #parent-item>#item, to make this rule overwrite the other one.
Yes you make it more specific but you don’t need the child selector to do this.
#parent-item #item{color:red}
Hope that clarifies a little
I’m guessing “#navigation-menu” is a <ul>? Well some browsers use padding to make indentation, some use margin. You already have hte left padding specified to a value that you like, however browserse that use margin to space get that 73px left padding+another ~16px
If you want to overwrite another rule, then it needs equal or higher weight. You can do that by adding elements to the selector rule, or by adding an ID to the element. Read up specificity here
What browsers support which kinds of selectors are covered in this chart here
Too slow…was doing the other thread! Sorry Paul !
Thanks to both of you. I really appreciate your help. I just bought a couple of CSS books last night to get me up on these sorts of things.
I will digest it all once I have finished the other 3 pages. But, can either of you explain a few pixels difference in padding in an a, or the pixels difference could be the height in a ul?
I reset styles’ margins by *{margin:0;padding:0}. But when I hover over one of the drop down links in safari, there’s about 2 pixels between the a (which is what’s background colour I change on hover, I expanded it’s height via padding) and the bottom of the ul (I set a height value for this). In mac firefox its fine. I’m guessing if it does that in safari though, it’ll be the same in windows browsers.
Do you know what causes this couple of pixels difference?
Do you know what causes this couple of pixels difference?
It’s hard to tell without code as it could be a lot of things.
If its an inline element then it could be the default line-height that is different. Adding padding to inline elements will be affected by the line-height as you can’t really make an element bigger than the line it sits in (although the real rules are more far complicated than that).
If you are looking to even things out then the element should probably be turned into a block display (or floating if horizontally aligned) so that all padding is added correctly and white space bugs cured.
If you are just expecting things to be the same size in all browsers then this won’t happen but usually is not an issue unless you are trying to match one element exactly with another. In those cases you would set a specific height and all browsers will match but most times you don’t really want to do that unless its something that has to fit exactly to match the design.
Using top and bottom padding on an inline element to create the same height element cross browser will not work (ignoring line-height for the moment) as the text is a different size on mac systems anyway.
There are many other things that could cause differences also not to mention bugs of course.
That particular reset (typcially called the universal reset) is fine for experimental code, but I’d never put it on a deployment website because it pretty well bones form elements cross-browser. Using that you can pretty much kiss off the odds of form elements like your contact page EVER rendering properly across all browsers.
Why? Well, here’s some major suckage - the HTML and CSS specifications actually do not SAY how form elements are supposed to recieve styling… and as with anything else the specification is vague on EVERY browser maker goes and takes a different approach.
Due to it’s Nyetscape heritage gecko based browsers like firefox have a seemingly random 0.2 to 0.3em padding on INPUT that no amount of CSS will get rid of that is added to whatever you set “height” to… IE flat out ignores height on INPUT, but will obey line-height as such (JOY) and it too has padding you can’t control in the form of 4px (I think)… Opera does the most sensible thing, and treats them as inline-block elements with 100% CSS control as such - while you don’t even want to get me STARTED about what Saffy does with form elements.
… and you don’t even want to see what resetting a SELECT will do across the different browsers - or worse, try looking at
a select you manually set padding-right on in FF.
This is why ‘targeted resets’ came about. The one I use (that was a collaboration between myself and a former Sitepoint member) is such:
/* reset margins and padding 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;
}
/* end reset */
It targets JUST the elements I tend to use that need a reset and nothing else. There are bigger resets like Eric Meyer’s “Reset Reloaded” - but that’s just a bit too saggy around the midsection for my tastes… especially since half the properties declared I’d be re-declaring the opposite of anyways, involves elements I don’t trust to use on a site in the first place (like Q) or violates good usability (like setting outline to 0 on all anchors)
As to your cross browser issues a lot of it stems from some just plain bad choices or outdated markup techniques - NOT neccessarily your fault when 99% of the books on shelves on the subject are a decade or more out of date. Hell, the only book on shelves the past six years I’ve seen that’s anything more than toilet paper is Ian Llloyds beginner book. (that frankly I think a lot of “seasoned” developers need to go back and read forgetting everything they THINK they know!)
Your navigation menu for example - you’ve got javascript doing CSS’ job, slew of classes when you have a perfectly good ID on the parent element, and comments before and after that COULD not only be tripping IE rendering bugs (YES, I SAID COMMENTS CAN TRIP IE BUGS) they are also redundant.
You might want to read:
http://www.ibm.com/developerworks/linux/library/l-clear-code/
While it’s for general programmers - there’s some really good information about commenting styles and comprehendable code. Take this for example:
<!--*************************************NAVIGATION **********************************-->
<ul class="cf" id="navigation-menu">
Really, it’s the start of the navigation? Opening that list with a id called “navigation-menu” gave me no clue! That’s treading into the same territory as making a comment “and now we’re done!”
There is NO reason given what you are doing there for style for the markup on that menu to be anything more than:
<ul id="mainMenu">
<li class="index"><a href="">HOME</a></li>
<li class="services">
<a href="services.html">SERVICES</a>
<ul>
<li><a href="services.html#inspection">INSPECTION</a></li>
<li><a href="services.html#repairs">REPAIRS</a></li>
<li><a href="services.html#training">TRAINING</a></li>
<li><a href="services.html#sales">EQUIPMENT SALES</a></li>
</ul>
</li>
<li class="info">
<a href="info.html">INFO</a>
<ul>
<li><a href="info.html#about">ABOUT US</a></li>
<li><a href="info.html#legislation">LEGISLATION</a></li>
</ul>
</li>
<li class="contact"><a href="contact.html">CONTACT</a></li>
</ul>
Everything else handled by CSS, with a behavior file like PeterNed’s HoverAnywhere to make IE 6/earlier play nice.
From there you’ve got a nonsensical heading order (headings should be used for STRUCTURE, not just because they make text bigger), non-flow text in a paragraph tag (footer), IE conditionals for dog only knows what since there is NOTHING on that page which should need to be targeted separately, multiple images doing the job of ONE, content cloaking in the form of that vcard nonsense (that could get you slapped down by the search engines)… There’s a laundry-list of issues before you even THINK about the CSS there.
Though don’t take the above as an attack or let it get you down - it sounds like you’re just starting out with CSS in which case what I’m seeing here puts you head and shoulders over half the people I see claiming to be “experts” on the subject. Your doing good, you just need some tweaks and pointers… and there are a few advanced techniques you are unlikely to find in any book that would serve you well on a page like this one.
If I have time later I’ll show you how I’d approach that same page including the menu, and give you a line-by-line breakdown of why I choose the HTML elements I do, and how the CSS I use works. The “teach a man to fish” approach… Teach a man to fish, he’ll bore you to death on the outdoor life network
… and here’s that rewrite
http://www.cutcodedown.com/for_others/nicolanicola/template.html
As with all my examples the directory:
http://www.cutcodedown.com/for_others/nicolanicola
is unlocked for ease of access to the gooey bits. Valid XHTML 1.0 Strict, would be valid CSS 2.1 if not the use of the browser specific ‘behavior’ property for PeterNed’s “HoverAnywhere” to make IE6/earlier work. Tested working identical in IE 5.5, 6, 7 & 8, Opera 9.62 and 10.52 (there’s something about those .x2 releases from Opera), Firefox 2 and 3.6, and the latest flavors each of Safari and Chrome.
To break down the HTML (I’ll do the CSS in a separate post to soon follow)
As Paul O’B pointed out, we lose the XML prolog so we aren’t dealing with IE in quirks mode, though since I wrote it to work in IE 5.x, we could actually get away without even using a doctype (though I wouldn’t take it that far). I added the full language meta, and something else you forgot - character encoding - could make a difference in how it renders as well.
You’ll notice my CSS includes use a ‘media’ type. I commented out the print and handheld ones… you may want to consider writing those since each target device has different capabilities. It’s important to remember that “screen” isn’t the only target out there, and sending to “all” can really screw things up.
Also noteworty is that every trace of that IE conditional malarkey is GONE. We don’t need it, we can fix most of the problems from inside our CSS file, no sense wasting bandwidth sending that hoody-hoo to everyone on every page in the markup.
You will also want to be sure to put in Keywords and Description metas - just be sure you use them for what they are for. It’s called KEYWORDS, not “KEYPHRASES”, keep it to 8 words or two word combinations, and try to keep it below 80 bytes… DESCRIPTION is there to show as text below your SERP - HOW it’s listed on the search results page… also something to keep in mind about your TITLE attribute since that will end up being your link back to your site.
First div is a bit like your ‘whole-page’, though I call mine “pageWrapper” - because that’s what it is, the wrapper of all major page elements. Don’t need a comment, becuase it says what it is.
After that the FIRST thing I try to get on the page is the primary heading. ALL lower order headings are by definition SUBSECTIONS of that first heading, so we nab it here. The nested anchor is nothing fancy, but you’ll see I have the site title present. The nested span is a styling hook to try and make it look a bit like the image you were using - and then there’s the empty nested bold tag.
That is there for what is called ‘Gilder-levin image replacement’ - a very powerful technique that lets you put a presentational image (like that heading) into the CSS instead of the markup. We absolute position this bold tag OVER the text hiding it. This is not considered cloaking becuase the text says the same thing as the image. In that way, I consider most header logos to be presentational affectations applied to the text. Turn images off on my example, and you’ll see why I do it that way.
Next is a div with the contact info. Rather than hide it, or try to use that convoluted vcard formatting which I’m not aware of any contact management software actually working with, I just put it in flat. Much like some of the microformat elements they are more hassle than they are worth. Someone ‘really’ wants it, make a custom vcf file.
The main menu is pretty much what I said above. I wasn’t certain exactly how you wanted it styled since it was so buggy - padding/blowing out of it’s container and not being consistent across browsers… so I just made them all fixed width, fixed the width of the dropdown, and let CSS do our grunt-work. It just seemed the simplest approach. Your original had the problem of using pt metric fonts, probably why it was breaking so horribly here since I’m a large font/120dpi user. If you’re going to fix the height and have dropdowns - as much as it sucks that means keep ALL your measurements for it in px or it’s going to break SOMEWHERE. Thankfully you are unlikely to ever have anyone kvetch about 24px being “too small”.
Content div, nothing too fancy. I axed the Content h1 as redundant - should have been a h2 anyways, then promoted the h3 to H2 so the document structure makes sense. Remember, skipping heading numbers bad/nonsensical, and lower order headings should always be subsections of the higher order heading preceeding it. If you can’t manage that, something is fundementally wrong with your document structure. (so no skipping to h5’s in a sidebar just because they aren’t as “important” as the content ones. If they’re less important just make sure your source order puts them AFTER the more important ones! - you’ll see people doing that **** all the damned time)
The image I put a ‘trailingPlate’ class on. I usually have three classes for images called ‘plate’ - a holdover from my print layout days. ‘leadingPlate’ being a float:left with the appropriate margin, ‘trailingPlate’ being a float:right with margin, and just plain ‘plate’ being display:block and auto-margin to center it. I put all three classes in place for you.
I changed #footer to a div because it’s not flow content. I like to reserve paragraphs for GRAMMATICAL flow paragraphs, rather than slapping them in willy nilly. A lot of people think of paragraphs in the typographical sense; going before the element to mark a block of text… others like to think of it in the word processor sense - a mark at the end to indicate the end of a block… me? That’s all PRESENTATION, and presentation has no **** PLACE IN THE MARKUP. As such, I use P to mark FLOW paragraphs of TEXT. That’s the grammatical/structural sense and makes a good deal of sense when using it to wrap cdata as a block.
Close out the pagewrapper, close out body and html, and we’re done with the markup.
It’s worth noting I usually write my markup BEFORE I even THINK about layout and graphics. Then I make the layout in CSS, and THEN at the final point do I start up the paint program to hang graphics on the layout. People don’t visit websites for the goofy graphics you wrap around the content, they visit FOR the content… so CONTENT FIRST seems like a pretty good idea, no?
In the next post I’ll break down the CSS.
Great posts Jason
Ok, on to the CSS. Follow along with
http://www.cutcodedown.com/for_others/nicolanicola/screen.css
You’ll notice I use camelBacks for my classnames - since it’s the format recommended and used by javascript I try to use it in all my web devlopment so I have consistency across all the different languages involved.
First is that reset of mine. Never needed more.
hr - I strip all horizontal rules as I usually use those just to divide up content for people browsing with CSS off. I can use border or background-images on my block level containers if I want that on the screen version of the document.
* html body - the “* html” hack targets just IE6. I try to avoid using it as much as possible, but in this case it’s a necessary evil since we only want to load csshover3.htc for IE6/earlier as in our case they are the only browsers that need it. You can find out more about this file here:
.htc files are basically javascripts that are applied to the page when it’s loaded or re-rendered in IE. By only throwing javascript at the browsers that need it (IE6/earlier) we don’t have to waste as much time (or bandwidth) coding around IE’s shortcomings. With almost 80% of the browsing public now on IE7/newer or alternative browsers, this is a definate improvement over throwing javascript or unneccessary class hooks into the markup.
body - The comment on the text-align says it all. IE5.5 is for all intents and purposes little more than IE6 permanantly stuck in ‘quirks mode’ since it was built to CSS2 before the standard came out of draft. (and yes, that is why we have the broken box model!). As such it ignores margin:0 auto for centering, but incorrectly obeys text-align on the parent. Next I set up the font as %/em. You were using pt, which there’s nothign really wrong with (some people would disagree - I say hey, at least it obeys the system metric) but for the page content, you REALLY should be using %/em. Just remember that for large font/120dpi users, uber-large 150% Win7 users the fonts will automaticalyl enlarge while your px sized elements (like images) will NOT, and that for some handheld users everything will appear 25% or so SMALLER (72 or 75dpi instead of 96) - though most handhelds just ignore font-size alltogether… background color is nothing to write home about.
#pageWrapper - width, center it with margin, turn off the center text-align we set on body now that #pagewrapper is centered in IE 5, and I set the content background color here because I can. The h1 and #footer will overlap it anyways.
h1 - since you are only ever supposed to have one h1 on a page, we don’t need any classes or id’s to target it or it’s children if we take proper care. Position:relative lets us absolute position that B tag sandbag in relation to the h1. I use the “holly hack” of height:1%; to trip “haslayout” - a special rendering quirk that fixes IE7/earlier positioning bugs. Percentage widths and heights are automatically changed back to “auto” if the parent element doesn’t have a fixed height or width declared on them (except for html and body which are special cases) - as such that’s the same as saying “height:auto” in standards compliant browsers (everything except IE)… for IE it is also treated as auto, but for some wierd reason it fixes some positioning bugs. Width, Height or zoom:1 are the most common haslayout triggers. I also set the font size for our largest text here.
The negative bottom margin needs a bit of explanation. By setting that I made it so that content after the element is ‘ridden up’ over our 182px tall heading. Basically it makes the page pretend that header doesn’t even exist when it comse to placing other stuff on the page! It’s a cool trick that often lets you avoid the headaches floats can create.
h1 a - the red color for the largest text, and strip the underlines.
h1 span - our nested span I set to display:block to force it to a new line below the big red “LIFTING” and we shrink it’s size and make it black. The negative margin just rides it up a bit closer.
You are probably noticing I do NOT declare our total 182px heading height on any of these elements. 46px top margin + 64px line-height + 23px line-height - 5px negative margin + 54px bottom margin == 182px… By not declaring the height, we avoid the IE5 broken box model and skip an unneccessary line of CSS.
h1 b - and here’s our logo image. I reduced it to a single file since blowing 17k on a separate logo seemed like a waste of time. Simple absolute positioning 0 0, with width and height of the image and the image as the background.
#contactInfo - Know how I said that negative margin on our h1 would make the content after appear OVER the content? That means all we have to do is make sure our right ‘info’ area is properly padded to total the same 182px height, so our margin falls into place. The left margin makes it so you can always click on the right half of the header to get to the home page - in some browsers if we let the entire div overlap you’d be unable to click on “h1 a”. We are forced to use PX metric fonts here because of the image interaction - using %/em or pt would cause the layout to break horrible on machines that are not at the so called “default” 96dpi… LIKE MINE. 14px is usually the smallest I will go in Tahoma since that’s the edge of legible for 120dpi users. (LIKE ME). Add in a text-align:right and we dodge all that pesky float nonsense.
#mainMenu - the position:relative in this case is to make sure it depth sorts over content. Position:relative and position:absolute elements inherently depth-sort over non-positioned (position:static) elements - so we don’t need to play with z-index at all. I declare the width just to trip haslayout since IE can be a bit funny with menus - strip the bullets, and I set text-align to center the menu text in their boxes.
#mainMenu li - position:relative in this case is for absolute positioning our UL. This way we can start with them positioned off-screen on the left, and then slide them into place on ‘hover’. I float them since thier child elements are going to float, and the display:inline is to deal with IE being a bit of a retard about margins on floats and ‘perfect width’ addition.
#mainMenu a - our anchors are of course floated, and I set a fixed width on them so they will add up to the full width. I did this because I wasn’t certain just what effect you were trying for with your version and this looked nice. Again you’ll see top/bottom padding with a line-height to add up to our total height. This centers the text and gives us 48px total height without acutally saying it.
#mainMenu li ul - and here’s our absolute positioning. The display:inline is so that we have a display state change (I change it to block) on hover. Without that IE will often ‘stick’ with the menu still open when you move the mouse off of it. Don’t know why, but it works. You can see I move the menu left:-999em; Since we’re running 100% font-size that works out to somewhere around 16K px, we’ll never see it, but screen readers will still read it. The top position is of course the height of our anchors, and again I declare the same fixed width on it. Doing so makes the menu behave a bit better and look nice.
#mainMenu li:hover ul - when we hover our parent list items, we want the child UL’s to slide into place. So here’s the left:0 to do so, and the display:block so IE won’t ‘stick’ open. Kind of funny since position:absolute elements are inherently display:block, and nothing you set for display can change that.
#mainMenu li:hover a - when we hover the top level line items, we want the background to change so we do that here. We do this off the LI instead of the A since we want it to stay lit up when you mouse-over the submenu.
#mainMenu li:hover li a - but we don’t want the child ones to light up, so we need to strip their background. We also give them a smaller top and bottom padding, and make sure that the text won’t wrap to multiple lines. [i]NOTE they will also inherit the 225px width off the #mainMenu a declaration, as well as any other values set there![i]
#mainMenu li li:hover a - but we want the nested ones to light up, so we put the background on them again. This can get rather convoluted the deeper you nest your menus, which is just part of why I don’t do three level cascades.
Content - just some padding and float clearing behaviors. Nothing fancy.
Content h2,
Content h3,
Content p - Fonts and padding. Yay.
.trailingPlate,
.leadingPlate,
.plate - those standard “plates” I mentioned in the HTML. Two of them float, one doesn’t. I tossed in all three since generally I include them for quick/easy formatting. It’s worth noting if I am designing the page for RTL instead of LTR I’ll reverse the floats on those; part of why I do NOT call them ‘left’ and ‘right’. ‘left’ and ‘right’ are presentational names, and presentation has no place in the markup.
#footer - padding, bgcolor, align… again, nothing you have not already seen.
I know the sizes and paddings aren’t a 100% match - I just belted this out quick though frankly, you had WAY too much white-space for my tastes given you were already on a fixed-width layout…
But that’s it, how I’d approach that. Said approach working in all browsers, though I’m pretty sure what I did with the menu is not what you were thinking… If you could explain that better with a picture of your FINAL idea, I can point you at a clean way to code that which will work in IE 6/newer without problem, and quite likely IE 5.x too.