bronzemonkey

That's a pretty limited use of sprites and it's definitely not necessary for the images to be the same dimensions. Just look at how amazon.co.uk uses a large sprite for all the main UI images - http://g-ecx.images-amazon.com/images/G/02/gno/images/orangeBlue/navPackedSprites_v13._V219533094_.png The key is simply to produce a single matrix of images that is then positioned as a background image where needed.

Use a 301 redirect. Better for the user and better for any spider. Serving a 404 is a bad idea.

Sounds familiar, check here - http://www.positioniseverything.net/explorer.html Can happen sometimes if you're changing the background color of some other properties on :hover. But check at PIE to narrow down the bug you're experiencing and find possible solutions.

Using {opacity:1;} (because opacity is now fully supported by mozilla) won't work because it will only be 100% opacity that is inherited from the parent. If by semi transparent background you mean only semi transparent background colour, then you can use: {background:#000; background:rgba(0,0,0,0.5);} rgba is supported by all mozilla and webkit browsers. Declare a background colour before the rgba declaration to act as a fallback for any browsers that don't support rgba. In the rgba declaration the first 3 values are the rgb values and the last is the alpha value.

Probably because the image is floated left. Containers are not meant to wrap floated children and IE's behaviour is not in line with the specification. You can have the container completely wrap the image by floating it left too, or adding overflow:hidden, or by using some version of the "clearfix" (google: clearfix position is everything).

In addition, it's encouraged and sensible not to use "presentational" class or id values. Imagine having: <h2 class="float-left"></h2> <div class="wide no-margin"> <p class="highlight-yellow">Lorem ipsum dolor</p> </div> What happens if the paragraph needs to be restyled to be red? Or if the div no longer needs to be "wide" and needs to have margins. Or if we don't want the heading to be floated left? You might be able to restyle them without affecting other elements in different parts of the site that use the same class names...but usually it is much more difficult to do so because of the concept of using presentational class names. This links the css with the html much more closely, making it harder to use css changes alone to affect the appearance of the document. Instead there is often a need to go into the html to change class names. You can't have the css declarations for "no-margins" to contain margins, or for "wide" to end up being narrower than the default appearance, etc. But if you name based on semantics derived from the document (i.e. not with a though about how to visually present it) then you avoid both these problems. If my target has a class of "entry" or "section" then I can style it any way I want without ever having to go into the html or have confusing class names.

Make sure you have a valid DOCTYPE as the first line in your document. To center your container (or any other non-floated block element with a specified width) use: #container {margin:0 auto;}

Then you'll have to post the rest of your code if you want any help, because the adjacent selector works perfectly as intended in IE7. And in the future, try to mention the specific browser you are having problems in.

That's because IE6 does not support the adjacent selector. IE7 does. If you are just trying to control the space between paragraphs in a "contact" section you might be able to achieve what you are after by using margins instead. Set each <p> to have a top-margin (and no other vertical margins or padding). You will get space between the two paragraphs but without unwanted space below the final paragraph. If you are not floating the paragraphs or heading then you will find that the margin between the <h5> and the first <p> will also collapse (i.e. the space between the elements will be equal to the whichever margin is largest, they will not combine). That won't work because the first paragraph in .contact_us is not the first-child. The h5 is the first-child.

Isn't that the exact same design as in a PSD/NETTUTS article? What was the license on the design in that article?

Is that really your html? No DOCTYPE? iFrames?

Did you set it's width to 100%

IE7 doesn't need the text-align hack. That was only IE5. If you want to center a page you put {width:960px; margin:0 auto;} and that will center in all browsers from IE6 through to FF3. Probably because you were kicking IE into quirks mode by having an html comment outside of the html doc.

@FilmGod: if you have no container then you are hardly ever going to find a use for clearfix, since you can just use {clear:both;} on the next element in the source. The whole point of clearfix is to clear a float container. I don't like using overflow auto/hidden because sometimes it produces scrollbars or you want to have overflow set to visible. The benefit of clearfix is that it doesn't have any other effect and it is completely robust. At the moment I just prefer to keep all the code for this behaviour together in one place. It's a crucial bit of behaviour and I find that organising it helps me better visualise what is going on in a site. That's not to say that I might not change my mind over time! But it's not very useful in that situation since you can just as easily use clear:both. Where the clearfix variants are useful is in self-clearing an element so that it completely wraps the floats it contains. Classic uses are in the navigation (where list items are floated) and on the containing element of floated columns. If you don't use clearfix then you can't apply a background to the parent and top-margins on elements below will disappear behind the floats. ------------- IE's hasLayout is not triggered on any element by default, until you apply styles that trigger it (e.g. width, height, zoom etc). When you have floated columns or nav items, they almost always have specific widths set and so they will have "layout". The trick (in terms of this desired clearing behaviour) is triggering hasLayout on their container so that it will wrap the floated children. Neither IE6 nor IE7 support the :after pseudo element but they will force an element to wrap it's floated children (incorrectly, in terms of the spec) if the element "hasLayout". IE6 can use styles like {zoom:1}; IE7 also supports {min-height:0;}. I prefer to put any IE styles in conditional stylesheets...but technically the IE7 styles can go in your normal declarations since {min-height:0;} is the default value for min-height. It has no affect at all on other browsers so you don't even need the IE7 targeting selectors. So it's down to how rigorously you want to separate the styles that are only required for IE7 from the styles that target standards compliant browsers.

This looks like it is related to you having all these elements floated. The margin is just disappearing behind the float. Try floating your dividing element too.

@haku - dropfaith's layout is using floats BlueBoden's layout is trivially simple...anything more complex or variable and the flexibility is negatively affected when you use absolute positioning. - The header is a fixed height. - There is no footer. - There is just one simple 3 column layout. - No ability to merge columns one into the other I also disagree with placing your top content last in the source. The vast majority of the time this houses the main client branding, search, and primary navigation - which should all by first in the source. The use of absolute and relative positioning for so many elements in the document also risks reducing the flexibility and ease of absolute positioning for when it is most useful in repositioning specific elements to visually appear in a position different to their source position. There are very important uses for absolute positioning - which is why I also strongly disagree with people who say it should hardly ever be used - but it should be used for when it is the most appropriate tool for the job. When it comes to basic structural layouts, floats are simply superior to absolute positioning.

http://www.brugbart.com/Tutorials/7/

If you had been paying attention you'd have noticed I was talking to haku, not you. But what are these "serious rendering problems"? It's not a trick. It's a basic part of the css spec. Such as? And we've already pointed out that layouts relying on absolute positioning lack flexibility and can fail in IE6. The layout you gave as an example has no footer and would struggle to merge two columns into a single column (without modifying the source). It also uses more code than a float-based layout. Javascript and flash should be used if they are the best tools for a job. But they should be used to enhance a site and never be a requirement - they are different "layers". This is a basic accessibility issue and there are legal as well as moral requirements involved. It is your problem if you fail to make content accessible to a large chunk of internet users. Supporting IE6 isn't even that difficult if you know what you're doing...even if it means that IE6 users don't get the complete visual experience. Supporting IE6 isn't something you can seriously charge clients for while 30%+ of the market still uses that browser. Any government or large corporate client expects IE6 support because that is what most of their staff have to use anyway and what most of their intranets are built to work on. There are fundamental logistical, security, and financial reasons for IE6's continued existence in the business world. You're not going to find any professional who is going to say they want IE6 to hang around. Everyone is waiting for the day when it can finally be ditched without impacting business. But no serious professional can do that yet.

this is totally pointless

Float based layouts are more flexible and robust. IE6 won't accept a declaration like {position:absolute; top:100px; bottom:100px;}. Other browsers will, and will simply calculate the dynamic height (or width) of the element, but IE won't. That is another important reason why you can't use absolute positioning for complex layouts. IE6 still has substantial market share (over 30%) and those of us who work on projects for large clients could never fail to cater for that browser. It isn't outdated because it is still in significant use. It is also unnecessary to not style layouts that work in IE6 because everything you've done in your examples can be done just was well, with less code, and still support IE6. The reality is that a LOT of businesses, the public sector in most countries, and users for certain countries are still running XP and IE6. They will not upgrade from IE6 until they migrate away from XP. There are security and logistical reasons for that decision. In some cases that will mean upgrading their entire network of PCs to new hardware which can run Windows 7 (because they look set to skip Vista completely). Most public sector networks will not allow staff to download any programs - IE6 is all they can use for browsing - and there is no pressing need to upgrade their hardware since most businesses need little more than word, outlook, excel and powerpoint. Unless you're working on small personal-projects for people and they are unaware of the statistics regarding browser usage, most people working for clients cannot afford to alienate such a high proportion of visitors. Not giving IE6 users some new shiny enhancements to the experience is one thing. Not giving IE6 users a functional and readable website is quite another. You don't need conditional comments to overcome the double margin bug. It can be avoided by adding {display:inline} to your declarations for that selector. However, I believe that your main stylesheet should only contain declarations that target (more) standards compliant browsers. Every IE bug is documented and predictable. I will always list declarations to fix IE specific behaviour in an IE version-specific stylesheet. For example (in an IE6 stylesheet): /* double margin fix */ #element, .elem1, .elem2, .elem3 { display:inline; } /* clearing and haslayout fixes */ .contains-float, .contains-float-2, .contains-float-3 { zoom:1; } /* min-height */ .lorem {height:100px;} .ipsum {height:325px;} No hacks. No mixing of bug-fixing code with standards code. Future-proof. It is clear what declarations are fixing what IE problems. In addition to that, some complex layouts will require their own IE6 mixture of declarations or a suitable alternative, and all that stuff can be kept separate in this file too.

IE8 is still in beta...no one supports it in their projects yet. No point. Report the bug to the IE8 development team.

I was talking about the page that you linked to. The horizontal scrollbar is due to the way you've centred the menu. If you just add the style that I posted above then it will stop the menu (only) creating a horizontal scroll.

To get rid of your horizontal scrollbar: #mainNav1 {overflow:hidden;} The problems with you tooltips might be down to some IE6 issues with changing the display from none to block on hover. An alternative is to not change the display value of the element but to position it far offscreen (-9000px/em) and then pull it back when hovered over. ------------------------------ Just to discuss the alt attribute on images. alt attributes should be a text alternative that conveys the meaning of a non-decorative image. If the image is decorative then you leave the alt attribute empty (alt=""). The alt attribute is not there to provide a "description" of the image (e.g. "dog picture" or "man holding a glass") and nor should it repeat text that is already present. You might decide that your images of the paintings are decorative, to show the painting to a potential customer, and thus the alt attribute should remain empty because the technical information is listed below. But you might think that the image of the painting is conveying information that is important to a customer, and therefore, you would want the alt attribute to contain a textual alternative to the visual content that conveys some of the info/meaning of the paintings to anyone who cannot see the image (for whatever reason). For example, the alt text of the image would not be "old fisherman" when the title is already "old fisherman"...it could be a paragraph: If the alt text is good, and appropriate, then if you read the html document as pure text you should barely be able to tell which is "alt text" for non-decorative images. It should read as part of the document...no different to any other content that you'd write.

It has nothing to do with using a transitional doctype - that does not trigger quirks mode. I suspect that the problem is that you have something appearing before the doctype in the source. The viewed source in FF and IE when copied (exactly) into a new file will result in the page being centred as you wanted in IE and the page not rendering in quirks mode. This means that there isn't anything wrong with the html or css as such (yes, {margin:0 auto;} is how you centre elements in standards mode...the text-align is a hack for IE5 or quirks mode, i.e. it's useless here). If you look at the source in Chrome then it will show a very small dash before the doctype...I assume that you might have a space or something in your original source before the doctype. Make sure that absolutely nothing is getting sent to the browser before the first character of the doctype declaration. Also, since you are using an HTML doctype, you should not putting xml attributes into the html element and you should not be using: <meta http-equiv="content-type" content="text-html; charset=utf-8" /> but instead <meta http-equiv="content-type" content="text-html; charset=utf-8">

This is what you need to do