Converting a mockup into a cross-browser compatible, standards-driven, functional web design is simply not going to happen without a bit of head scratching along the way. Browser technology has advanced considerably in the last decade, but each browser still has its quirks - and you'll invariably have to deal with those quirks at some point if you develop web pages with any degree of responsibility. While far from being an expert in CSS design, I've beaten my head against my desk enough to know that most display issues can be solved, corrected, or hidden if you deconstruct your problem logically and look for help in the right places. Here's a brief and partial list of rendering problems and potential solutions:

My floated, multicolumn layout is broken. The right-hand column is being thrown down below the other two, the footer is being displayed over the content in my center column and the links in my left-hand column are ignoring the width of their container and breaking outside of the border.

Analysis: Floats are tricky. First, whenever you float an item, you MUST give it a width. Floats won't behave as they should until they're assigned an explicit width. However, this can be done with a relative or absolute unit (px, %, em, etc.). Logically, it makes sense that floats require a width defined in the CSS. Browsers need to know how you'd like to represent the floated item. How much of the page is it allowed to occupy? What should the browser do with the float if the window is resized? If you've specified that the floated item should be 33% wide, the browser is going to try to preserve that width, even it means kicking it down below the other items on the page.

Tips: The first thing you should do when confronted with a float issue is determine if the problem occurs in a (more) standards compliant browser, like Firefox, Safari or Opera. Make sure you've solved the issue in a good browser before addressing it in Internet Explorer, which will have its own issues with floats.

Try These: Get scientific with the layout specs. Add up the widths on the floats and include any margins and padding you may have added. If your layout is exceeding the boundaries you set for it, try backing off 1%, or a few pixels, on the overall width. Fitting the design into 98 or 99% of the allowed space will make most browsers happy, but Internet Explorer, in particular, will require this little adjustment, if not more like 96 or 97%.

Aside from width issues, the most common problem I've experienced with complicated float techniques is an incorrect placement of clearing elements. If you just can't figure out why one of your containers is bleeding into another, play around with the position of the clearing div (if you're using one). For older versions of Internet Explorer, the problem might be that the browser isn't respecting the layout of the clearing div. If this is the case, either add a non-breaking space inside of the div or consider removing the clearing div in favor of putting the clear directly on the element that needs to break the floating of the previous element.

Reference Materials:

• Position Is Everything is a great resource for float issues with an emphasis on browser quirks and Internet Explorer bugs.
• Westciv has a helpful table that quickly shows the extent to which layout properties are supported by the major browsers through each version.
• Maxdesign has a nice "Floatutorial"

I made custom images for the radio buttons and submit buttons on my form, but they're not showing up in some browsers and they look terrible in others. I also don't understand why the borders I put on my drop-down boxes aren't rendering.

Analysis: Form controls are notorious for being unpredictable. In fact, the W3C recommends against even attempting to style them, predicting that you're just going to mess them up and make it harder, or impossible, for visitors to use your form across browsers. Here's why: Unlike everything else in the browser's window (with the exception of the scrollbars), form controls aren't generated by your browser, they're applied by your operating system. Have you ever wondered why an input box in a web page is conveniently bordered by a thin, light blue line when your "Windows XP" theme is enabled, but seems to be unstyled when the "Classic" theme is active? It's the same reason why your submit buttons look remarkably similar to your ocean blue, liquidy scrollbars in Safari. Basically, you, as a web developer, have virtually no control over how the majority of your form controls will be styled, but knowing what you can change and what you can't will save you a lot of time and frustration.

Tips: Radio buttons, check boxes, drop-down lists and submit buttons cannot be reliably styled across browsers. My advice would be to leave them alone. You may want to set global styles to help control the text that gets generated inside them and the general spacing in and around the controls, but be careful with sophisticated background replacement techniques for custom images around your buttons. You could accidentally render the text inside them unreadable.

Try These: Don't style your form controls...at all. Unless you're working on a project that requires an overtly artistic interface, let your browser render the form controls the same way it has since 1995. Breaking convention may only serve to confuse the user, anyway. If you simply must change the look of the boxes and buttons, experiment with any of the following:

• Good ol' fashioned CSS: Use your stylesheet (or create a separate one) to play with the background colors of boxes, border styles and custom images. Just make sure to do a thorough usability test in as many browsers as you can get your hands on. Where possible, feed overriding styles to specific browsers through hacks or targeted stylesheets.
• Javascript: Plenty of designers have used Javascript to enhance the appearance and behavior of their forms. Do a quick search and steal some of their techniques (legally, of course).
• Flash: This method is terribly inaccessible, but it will give you ultimate control over the way your form looks and behaves. In those cases where your forms have to integrate seamlessly with the rest of your ornate design, and you know the user base will be especially tech savvy, Flash forms may be appropriate.

Reference Materials: Roger Johansson has a fairly comprehensive write-up on his website.

Some of my hacks for Internet Explorer don't work in IE 7. My design team has decided that we need to keep supporting IE down to version 5.5, but each version has its own set of irregular behavior. Previous attempts at Javascript browser detection to differentiate between the versions haven't gone smoothly.

Analysis: Internet Explorer, though steadily improving its rendering engine and its support for advanced CSS, is still buggy beyond belief. To make matters worse, each of the recent major versions (5, 6, 7) interprets the W3C standards in radically different ways. I've found that a good CSS/XHTML design process needs to include a QA phase dedicated solely to IE testing. Unfortunately, Internet Explorer still holds the market share for browsers and probably will for the near future.

Tips: Don't rely on hacks in your main stylesheet to target IE. Hacks, though clever and effective, usually become obsolete somewhere down the line. IE 7, for instance, no longer interprets rules prepended with the *html hack.

Try These: Microsoft recommends using "conditional comments" - proprietary statements that allow for incredibly flexible control over what gets sent specifically to IE and which version(s) can see it. To make this technique even easier to swallow, Microsoft has guaranteed that all future versions of IE will recognize conditional comments. Better still, other browsers are in no danger of interpreting the code inside these statements because they're inside something that looks very similar to an HTML comment. Use the conditional comments to send a version-specific stylesheet to a particular version of IE, all versions less than or greater than a certain release, or versions "less than or equal to" or "greater than or equal to" a certain release. You can even put the comments in the body to create markup that only IE will see.

Reference Materials: See the official Microsoft article for usage tips.

Some Final Advice and Links to Tools:

• Use a browser diagnostic extension to drill down your code and easily locate the source of your layout issue. Firebug is available for Firefox and the IE Developer Toolbar plugs into Internet Explorer.
• Measure widths and heights of rendered layout items by placing a ruler image in the background of a containing element.
• When attempting to diagnose layout issues in pages with server side controls, view the rendered source and make sure the server code isn't adding any markup that may "have layout" and bump the rest of your design out of place. If markup is being generated and inserted, turn it off in the stylesheet by targeting its ID and setting it to display:none;