Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

The Principles Of Cross-Browser CSS Coding

It is arguable that there is no goal in web design more satisfying than getting a beautiful and intuitive design to look exactly the same in every currently-used browser. Unfortunately, that goal is generally agreed to be almost impossible to attain. Some have even gone on record1 as stating that perfect, cross-browser compatibility is not necessary. [Links checked & repaired March/06/2017]

While I agree that creating a consistent experience for every user in every browser (putting aside mobile platforms for the moment) is never going to happen for every project, I believe a near-exact cross-browser experience is attainable in many cases. As developers, our goal should not just be to get it working in every browser; our goal should be to get it working in every browser with a minimal amount of code, allowing future website maintenance to run smoothly.

Further Reading on SmashingMag: Link

In this article, I’ll be describing what I believe are some of the most important CSS principles and tips that can help both new and experienced front-end developers achieve as close to a consistent cross-browser experience as possible, with as little CSS code as possible.

Cross-Browser CSS

Understand the CSS Box Model Link

This is one of the first things you should be thoroughly familiar with if you want to be able to achieve cross-browser layouts with very few hacks and workarounds. Fortunately, the box model is not a difficult thing to grasp, and generally works the same in all browsers, except in circumstances related to certain versions of Internet Explorer (more on this later).

The CSS box model is responsible for calculating:

  • How much space a block-level element takes up
  • Whether or not borders and/or margins overlap, or collapse
  • A box’s dimensions
  • To some extent, a box’s position relative to other content on the page

The CSS box model has the following basic rules:

  • Block-level elements are essentially rectangular (as are all elements, really)
  • The dimensions of a block element are calculated by width, height, padding, borders, and margins
  • If no height is specified, a block element will be as high as the content it contains, plus padding (unless there are floats, for which see below)
  • If no width is specified, a non-floated box will expand to fit the width of its parent minus padding (more on this later)

Some important things to keep in mind for dealing with block-level elements:

  • If a box has its width set to “100%”, it shouldn’t have any margins, padding, or borders, otherwise it will overflow its parent
  • Vertically-adjacent margins can cause some complex collapsing issues5 that may cause layout problems
  • Elements positioned relatively or absolutely will behave differently, the details of which are extensive and beyond the scope of this article
  • The rules and principles above are stated under the assumption that the page holding the block-level elements is rendered in standards mode (this point was added later after review of the comments posted6)

The Box Model as shown in Firebug
The box model as its displayed using Firebug in Firefox

Understand the Difference Between Block and Inline Link

For experienced developers, this is another no-brainer. It is, however, another crucial area that, when fully understood, will cause the light bulb to appear7, many headaches will be avoided, and you’ll feel much more confident in creating cross-browser layouts.

The image below illustrates the difference between block and inline elements:

Block and Inline Elements

Here are some basic rules that differentiate block elements from inline:

  • Block elements will, by default, naturally expand horizontally to fill their parent container, so there’s no need to set a width of “100%”
  • Block elements will, by default, begin at the leftmost edge of the parent box, below any previous block elements (unless floats or positioned elements are utilized; see below)
  • Inline elements will ignore width and height settings
  • Inline elements flow with text, and are subject to typographical properties such as white-space, font-size, and letter-spacing
  • Inline elements can be aligned using the vertical-align property, but block elements cannot
  • Inline elements will have some natural space below them in order to accommodate text elements that drop below the line (like the letter “g”)
  • An inline element will become a block element if it is floated

Understand Floating and Clearing Link

For multi-column layouts that are relatively easy to maintain, the best method is to use floats8. Having a solid understanding of how floats work is, therefore, another important factor in achieving a cross-browser experience.

A floated element can be floated either left or right, with the result that the floated element will shift in the specified direction until it reaches the edge of its parent container, or the edge of another floated element. All non-floated, inline content that appears below the floated element will flow along the side of the element that is opposite to the float direction.

A Floated Element

Here are some important things to keep in mind when floating and clearing elements:

  • Floated elements are removed from the flow of other block-level, non-floated elements; so in other words, if you float a box left, a trailing paragraph (block level) that’s not floated will appear behind the float in the stack, and any text inside the paragraph (inline level) will flow around the float
  • To get content to flow around a floated element, it must be either inline or else floated in the same direction
  • A floated element without a declared width will shrink to the width of its content, so it’s generally best to have a set width on a float
  • If a block element contains floated children, it will “collapse”, requiring a fix9
  • An element that’s “cleared” will avoid flowing around floated elements above them in the document
  • An element that’s both cleared and floated will only clear itself of elements that come before, not after

Use Internet Explorer First (Or Don’t) Link

Please note that Smashing Magazine’s team strongly advises against developing websites in Internet Explorer first. In our opinion, sites should be developed in “modern” web-browsers, with standards first and then be tweaked for buggy versions of Internet Explorer. The advice below does not reflect the opinion of the Smashing Editorial team. Agree or disagree? Comment on this article!

Most of what I’ve discussed so far has to do with CSS coding and layout principles. This principle is more related to habits and preferences of most designers. Although we might hate to use IE6 and IE7 in our everyday internet activities, when it comes time to build a client project from scratch, one of the best things you can do is test your layout in those browsers early in development. You might even want to open up a standalone version of IE6 or IE710 and just start your development in that browser.

Of course, you won’t have access to tools like Firebug, but generally for CSS (especially early in development) you won’t need Firebug. It’s much easier to get a layout working first in IE6 and IE7, then fix for other browsers, than to do it the other way around. Waiting until late in the development process to open up IE6 and/or IE7 will likely cause some, if not all, of the following problems:

  • Multiple hacks will be required, needing separate stylesheets for different versions of IE, making the code bloated and less maintainable and making the website slower
  • The layout in some spots may have to be reworked, multiplying development time
  • Testing time will increase, sometimes exponentially, leaving less time for more important tasks
  • The layout in other browsers will not be the same as in IE6 and IE7

I wouldn’t expect developers to use Internet Explorer this aggressively for personal projects, web apps, or other non-client work. But for corporate clients whose user base is primarily on Internet Explorer, this tip could prevent a lot of headaches while getting things to work properly, and will definitely make a cross-browser experience much more likely.

Sometimes viewing IE’s problems as “annoying bugs” can create unnecessary negativity, and can hinder development time and future maintenance. Dealing with IE is a fact of life for designers and developers, so just view its problems as you would any CSS issue — and build from there.

Understand Internet Explorer’s Most Common Problems Link

If you’re going to start with IE in your development, or at the very least check your layout in IE early on, then you should understand what things Internet Explorer (usually versions 6 & 7) has problems with, or what its limitations are.

A detailed discussion of every possible problem that can occur in Internet Explorer, and a list of all of its CSS compatibility issues11 is certainly beyond this article. But there are some fairly significant inconsistencies and issues that come up in relation to IE that all CSS developers should be aware of. Here is a rundown of the most common problems you’ll need to deal with:

  • IE6 will become problematic if floats are overused, causing (paradoxically) disappearing content or duplicate text12
  • IE6 will double the margin on floated elements on the side that is the same direction as the float; setting display: inline will often fix this
  • In IE6 and IE7, if an element doesn’t have layout13, it can cause a number of problems, including backgrounds not showing up, margins collapsing improperly, and more14
  • IE6 does not support min- and max-based CSS properties like min-height, or max-width
  • IE6 does not support fixed positioning of background images
  • IE6 and IE7 do not support many alternate values for the display property (e.g. inline-table, table-cell, table-row, etc.)
  • You cannot use the :hover pseudo-class on any element in IE6 except an anchor (<a>)
  • Certain versions of IE have little support for certain CSS selectors15 (e.g. attribute selectors, child selectors, etc.)
  • IE versions 6-8 have little support for CSS3, but there are some workarounds16

There are many more bugs, issues, and inconsistencies that can arise in Internet Explorer, but these are probably the most common and most important ones to keep in mind when trying to create a cross-browser experience. I encourage all developers to do further research on many of the issues I’ve mentioned above in order to have a more accurate understanding of what problems these issues can cause, and how to handle them.

Some Things Will Never Look the Same Link

As already mentioned, creating the exact same experience visually and functionally in every browser is possible, but unlikely. You can get the layout and positioning of elements close to pixel-perfect, but there are some things that are out of the developer’s control.

Forms Will Often Look Different Link

Discussing all the differences and quirks that occur with form elements across the different browsers and platforms could be an article in itself, so I won’t go into extensive details here. A simple visual demonstration, however, should suffice to get the point across.

Take a look at the image below, which displays the <select> elements on the Facebook home page, as shown in 5 different browser versions (screenshots taken from Adobe’s Browserlab):

The Facebook sign-up form in different browsers
<select> elements appear differently in different browsers

Some form elements can be controlled visually. For example, if the client requires that the submit button looks the same in every browser, that’s no problem, you can just use an image, instead of the default <input type="submit">, which, similar to <select> elements, will look different in different browsers.

But other form elements, like radio buttons, textarea fields, and the aforementioned <select> elements, are impossible to style in a cross-browser fashion without complicating matters using JavaScript plugins (which some developers feel harm the user experience).

Typography Will Always Look Different Link

Another area in which we can’t expect pixel-perfect designs is with regards to fonts, particularly fonts on body copy. Different methods17 have sprung up to help with custom fonts in headers, and the recently launched Google Font API18 will contribute to this. But body copy will probably always look different in different browsers.

With typography, we not only face the problem of font availability on different machines, but in some cases even when the font is available on two different machines, the type will look different. Windows ClearType19, for example, is available on IE7, but not on IE6, causing the same font to look different on two different versions of IE.

The graphic below displays screenshots from A List Apart20 on IE6 and IE7. The grainy text in IE6 is more evident on the heading than in the body copy, but all text displays a marked difference between the two browsers (unless of course the text is an image):

A List Apart's typography compared in IE6 and IE7
A List Apart’s typography compared in IE6 and IE7

Use a CSS Reset Link

Ever since I started using a CSS reset for my projects, my ability to create a cross-browser experience has greatly increased. It’s true that most resets will add unnecessary code to your CSS, but you can always go through and remove any selectors that you know will not be a factor (for example, if you don’t plan to use the <blockquote> tag, then you can remove reference to it, and repeat this for any other unused tags).

Many of the margin- and padding-related differences that occur across different browsers become more normalized (even in troublesome HTML forms) when a CSS reset is implemented. Because the reset causes all elements to start from a zero base, you gain more control over the spacing and alignment of elements because all browsers will begin from the same basic settings.

CSS Reset
A CSS reset as shown in Firefox’s developer toolbar

Besides the benefits of producing a cross-browser experience, a reset will also be beneficial because you won’t use as many hacks, your code will be less bloated, and you’ll be much more likely to create maintainable code. I recommend Eric Meyer’s CSS reset21, which I’ve been using for quite some time now.

Use SitePoint’s CSS Reference Link

If you’re having trouble getting a particular CSS property to display correctly across all browsers, look up the property in the SitePoint CSS Reference22 to see if it has any compatibility limitations. SitePoint’s reference (which is also available as a hard copy23, though not as up to date), includes a useful compatibility chart that displays browser support for every standard CSS property.

SitePoint's Compatibility Charts for CSS Properties
SitePoint’s Compatibility Charts for CSS Properties

Each compatibility chart is accompanied by a fairly detailed description of the bugs that occur in different browsers, and users are permitted to add comments to document new bugs that come up and to provide further explanations on complex CSS issues.

Using this as a guide, you can narrow down the possibilities, and can usually determine whether or not a CSS issue is due to a browser bug, or due to your own misapplication or misunderstanding of the CSS property in question.

Conclusion Link

While there is so much more that could be discussed on the topic of cross-browser CSS, the principles and guidelines I’ve introduced here should provide a foundation to assist CSS developers in creating as close to a consistent cross-browser experience as is currently possible. Cross-browser CSS is an attainable goal, within reasonable limits.

But, as an epilogue to this article, I also would like to concur with those promoting the use of CSS3 with progressive enhancement24, and encourage developers to push new CSS techniques to the limits, even doing so, where possible, on client projects.

The principles I’ve introduced here should help developers create a beautiful and intuitive experience in IE, while providing an extra-beautiful and super-intuitive experience in the more up-to-date browsers. That’s a cross-browser goal that is definitely worth striving for.

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6 #comments
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24

↑ Back to top Tweet itShare on Facebook

Louis Lazaris is a freelance web developer and author based in Toronto, Canada. He blogs about front-end code on Impressive Webs and curates Web Tools Weekly, a weekly newsletter for front-end developers.

  1. 1

    Ben MacGowan

    June 7, 2010 3:50 am

    Great article.

    I would disagree with the starting with Internet Explorer first. I always code in Firefox, so I am pretty much guaranteed that it will work in Firefox, Safari, Chrome and Opera. Then being to look at Internet Explorer to work out the kinks.

  2. 2

    I think, you should start with the browser most of your users will use. For different projects these are different browsers.

  3. 3

    I used to start with IE as you suggest here, since if it works in IE it’ll usually work in everything else. But eventually I grew so dependent on Firebug and the other developer add-ons for Firefox that it no longer made sense to test in any other browser. Plus, the more I worked with CSS, the more I knew how to avoid causing IE problems in the first place and deal with them relatively painlessly if they did pop up.

    One tip: If possible, sniff the browser and attach it as a class to your body tag. You can’t do it in all situations (for example, it’s usually bad practice in Drupal because of how the cache system works), but it’s easy to do in WordPress.

  4. 4

    Michael Ward

    June 7, 2010 4:01 am

    “You might even want to open up a standalone version of IE6 or IE7 and just start your development in that browser.”

    That way lies madness!!

    Develop in Firefox and test regularly in other browsers (after each major styling feature is in place) – that way you can catch bugs or differences before they accumulate in to balls of inter-dependant problems.

    Develop to standards (which tend to be predictable) and fix bugs in browsers as you encounter them. But do not leave IE6 testing until late on, you will severely regret it.

    Loved the rest of the artice :)

  5. 5

    James Moxley

    June 7, 2010 4:16 am

    Working in IE first is a terrible idea, work with a compliant based browser such as FireFox, Chrome, or Safari. Its good practice to test against a whole suite of browsers, but development will be easier starting with a compliant browser. Don’t use hacks within the CSS, instead use conditional comments to overcome the quirks within IE.

  6. 6


    June 7, 2010 4:20 am

    awesome article!!
    ithink as alexey said, and u can analyze it using any statistics as google analytics to know the most browsers used by your project visitors

  7. 7

    I agree with developing in the “best” browser you can first. Getting everything looking right across Firefox, Safari and Chrome is usually very simple. I’d go as far as to say if you run into more than a couple of minor layouts niggles between the latest versions of these three browsers you’re doing something wrong.

    I always leave IE testing until late on, using conditional comments to include IE-only stylesheets for version 6, 7 and 8 makes it quite a clean way to work.

  8. 8

    I disagree with you, if you mean it is better to start developing with IE. If you develop Websites or Webapps you need tools like Webdeveloper-Toolbar or Firebug for live-debugging or the Speed Tracer for optimzing the loading speed. If you do develop frist for or with IE, you don’t have those possibilities of live-debugging or -testing.
    First: Firefox, Safar, Chrome, Opera, ………, IE

  9. 9

    I have to agree with Ben. I used to code in IE first, and I’ve long since switched to coding in Opera/Firefox first (I check both as I go along). 99% of the time, doing this makes the site look the same in Chrome, Safari, Opera and Firefox. It also looks the same in IE8 the vast majority of the time, and IE7 and IE6 only need small tweaks by using conditional comments. I’ve found when I develop for IE first, I end up starting over because the stuff I put in place for IE is completely messed up for Firefox/Opera/Chrome/Safari.

    I believe understanding the other key points he’s mentioned up there helps a LOT with this, because as I’m coding for the standards browsers, I’m thinking of what could/would happen in IE. Stuff like “disappearing text” is fixed by giving elements hasLayout. Duplicate text is *dead* easy to fix – the only time I’ve ever seen that is when I put a comment *outside* of a closing div – put it just before the closing div tag, problem solved. The rendering of min-height and max-width can be set with a conditional comment by setting width and height – IE6 will expand to that, but it won’t go over it.

    All in all, it’s really in how you work. Perhaps a lot of people work more efficiently doing IE6 first. Great for you. I think you’re nuts – because if *I* do it that way, it takes me 2-3 times as long to get something finished. But if it’s more efficient for you to do it that way, I salute you, and continue on. It’s more efficient for *me* to make IE the *very last* thing I check. I can have IE 7 and 6 fixed in 30 minutes or less – so to me it makes no sense to code for the worst thing and “fix” everything that’s working fine.

    So although I, personally, do not agree with coding for IE first, I don’t think I should tell everyone they are wrong if they do. If it’s efficient for you to do that, wonderful. For me, it’s not. Neither of us are wrong. But the other points made are excellent, and very useful. Good article :)

  10. 10

    Very good article, but I have to disagree with the “start with IE, them go for the rest” strategy. That way, the not-so-good (to put it politely) browsers will never go away.
    I always design and code for standards first, test with Firefox, Chrome, Safari and Opera, leaving IE for last. And it it doesn’t look too ugly and works ok, I leave it as is.

  11. 11

    Start with the bad and then make it good? That doesn’t make any sense.

    You should start by making your code as correct as possible, then provide exceptions for those that need it.

    I personally have found that using this technique has resulted in designs working in all modern browsers from the start. The only browser I am left to tweak for is IE6, which I do using conditionals. I check my code in Firefox and IE7 as I go, with checks in Safari and Chrome at major milestones. I rarely have to do any adjustments to get things working properly in those four.

    If you are having that many problems getting a design to work in IE7 the same as Firefox or Chrome, then you are either using code that isn’t fully supported yet, or you are coding wrong.

    And yes, I know that they have different rendering engines. But all of these engines are rendering to the same spec. If you are coding within finalized standards, then you shouldn’t be having problems.

  12. 12

    I also disagree with using IE first. I find that using IE as a base means spending more time to get it to sit correctly in other browsers. Where as if I use Firefox I only have to do small changes to make it fit into IE with conditional css

  13. 13

    I’ve got to agree with everyone who’s pointed out that starting development in IE and checking in FF/Safari etc as you go is terrible advice.

    This used to be the way i built web sites when i was learning my trade (as did many other people i’m sure) but as soon as i switched my workflow round life became soooo much easier.

    You know that if something works in FF it will just as likely work in every other non-IE browser, and you then have the luxury of conditional CSS to target any IE problems. If you do it the other way round there’s no way of writing specific rules for non-IE browsers to fix a rule that works in IE because of a quirk of implementation, but doesn’t work in any other browser.

    There’s some great nuggets of info in this article, but making IE your development browser is not one of them :-(

  14. 14

    Nice article with some good understanding of the basics. I’d like to add that using a CSS Reset should be used with caution. Always re-pattern the reset so that you don’t end up ‘fixing’ basic selectors over and over again. Normalise instead of zeroing.
    Personally I’d never advise starting with IE. In my experience it usually leads to more CSS bloat. Working in Firefox or similar compliant browser results in a leaner HTML and CSS. Having said that, you should routinely check your front-end code in IE to make sure you find things working or failing as expected.

  15. 15

    There are a few basics you can learn that will help you with IE, but I’d never start with IE when it comes to coding. You can always go back in and tweak the code for IE anyway.

    Also, I stopped supporting IE6 a few weeks ago, officially. With only 5% of the population now using it, I think we can all safely stop supporting it.

  16. 16

    “You should start by making your code as correct as possible, then provide exceptions for those that need it.”

    Spot on.

  17. 17

    Nice Article :)

    Some time I found cross browser issue due to bad html markup write by designer. If you write correct markup you never found any cross browser issue.

  18. 18

    Vitaly Friedman (Smashing Magazine)

    June 7, 2010 5:01 am

    To be honest, I don’t believe this is true. I have seen many corporate environments in which IE6 is dominating with over 40% of usage. It depends on the setting in which your website will be used. I don’t think we can trust “global” statistics, it doesn’t really help us, unless we are talking about a global project that is tartgeted at global audience.

  19. 19

    I agree with some points made above; you should code to standards, not for browsers.

    Starting with IE6 and then working up is stupid in my opinion. I work in a corporate environment and at least 70% of our users are still on IE6, but I still design in modern browsers and work back. Even in this corporate environment, I still use cutting edge CSS and HTML5; it’s presentable in IE, but much nicer in a modern browser.

    This still gives you cross-browser compatibility, but also futureproofs your website.

    Browsers like Firefox, Safari, Chrome and Opera (and IE9) are getting more and more similar in the way they render sites. Why ignore this fact and code for the outliers? It just doesn’t make sense to me.

  20. 20

    With Firebug Lite you can use Firebug in IE browsers.

    I totally agree with:
    a near-exact cross-browser experience is attainable in many cases

    It’s absolutely true that when you know where to look for, many if not all designs can be made presentable by IE6.

    IE5, now that was hell. People have been making beautiful websites for years, even when IE6 was a modern browser. If webdesigns change so older browsers can’t present them, the problem is not the older browser, it’s in the new designs.

    Much hatred and dropped support for IE6 stems not from technological impossibilities, browser market shifts and quirks. It stems from inaptitude at designing and developing solid webpages.

    Starting with IE6 on positioning the main page structures saves me time. If a page works in IE6 and not in modern browsers, you are still doing it wrong.

    Progressive enhancement is the prettier cousin of graceful degredation. Progressive enhance your designs from IE6, don’t degrade your designs to work with IE6. An IE exception is rarely neccessary when enhancing designs. When degrading designs there is too much reliance on IE exceptions.

    Yes, you should still code properly and semantically, and not code for browsers. But when you are adding IE exceptions you are essentially doing exactly that!

    An IE6 template doesn’t automatically mean an unsemantical document rife with exceptions and browser specific code. Only if you have many troubles producing a solid IE6 template, will you associate an IE6 template with browser dependant code.

  21. 21

    If your code for IE6 is incorrect, you are doing it wrong. You can perfectly start with IE6 and code your HTML and CSS correctly.

    You are promoting hacking over sensible enhancement. I very rarely need IE exceptions in my designs. You clearly need them. I’d say this reliance shows you aren’t coding your HTML and CSS correctly first and foremost, regardless of which browser you code in.

    IE exceptions is coding for browsers, not coding to standards. IE hacked code is certainly not clean.

    If you need fixes for IE7 and even IE8 you aren’t writing HTML, you are writing anti-Microsoft manifests.

    Getting pages looking the same in all browsers is nonsense. Web is not print. You also can’t make two books look exactly the same if they come from different pressing plants. Maybe if you make images of your websites.

    There are many high-profile webdevelopers who take this stance. I think you don’t really know what the original definition of cross-browser is (I think you mean multi-browser, unless you can somehow do wonders with ancient browsers such as Netscape 1).

    Pixel-perfect cross-browser designs are a pipedream, and in the case of form elements (system elements that are intuitive and known by the user) even unwanted. Just one glance at the difference in rendering fonts and everything associated with them such as font-variant and text align justify, will show any dev/designer it is impossible to make HTML look exactly the same on even a small subset of modern browsers.

  22. 22

    Amber Weinberg

    June 7, 2010 6:07 am

    I dropped support for IE6 several months ago, but ive found that by simply using a CSS reset and coding in standards normally means that my sites are perfect in IE7 the first time.

    And I too disagree with developing in IE first. Why should we limit our development to old browsers and handicap the newer ones? Plus this seems like it would take much longer to dev this way. We should be focusing on progressive enhancement techniques instead.

  23. 23

    I don’t want to be a troll or a curmudgeon, but it must be said: The clearest evidence that CSS is a failure is the fact that for this article, all of the examples are IMAGES. If CSS is so viable why not just use HTML elements and actuall CSS to create the examples? -Definitely use images to illustrate browser variations in forms or the way different browsers show the same CSS but it is really interesting that even for the float and inline examples are done with images created in Fireworks or Photoshop. Why didn’t SM or the guy who wrote the article use actual Divs, styles, classes etc to make the examples?

  24. 24

    Gilles Ruppert

    June 7, 2010 7:27 am

    Just by saying you should code in IE first makes this article not credible. Having resources like this on the web is dangerous and makes it difficult for new people starting out. I hoped that by now people who write articles for sites such as Smashing Magazine would know that. Shame on Smashing Magazine for publishing this!

  25. 25

    I love that Smashing placed a disclaimer for developing in IE first…couldn’t agree more! Develop for modern browsers and then tweak for the rest of the world.

    Otherwise, great article!

  26. 26

    for me, Coding for standard compliant browser first is an unbreakable principle!! and standard compliant browsers (in order) are latest version of Opera, FireFox, Safari and Chrome.
    I think what is meant in this article is that while you develop for the standard browsers first, begin testing in standalone versions of IE6 and IE7 as early as possible.
    It should make it more explicit, probably, by saying that as soon as you’ve a decent markup and presentation working across standard browsers, hop to IE6 and IE7 and test for the common mistakes so that you do not go far into your design before getting the basics right on legacy browsers as well.

  27. 27

    Niels Matthijs

    June 7, 2010 4:59 am

    Like others have said, if you want to take the future-proof way, start development in Firefox/Chrome or Opera. After that, go fix lesser browsers. And keep debugging until your final task, when you know your base css won’t change.

    If you start developing for IE, you’ll be left with a lot of bad tactics and crappy code that will live long after the older IEs (6 and 7) have died out.

    Besides that, I don’t really see how this article is about cross-browser styling. It’s a good article, preaching the basic principles of css, but its connection to cross-browser styling is slim at most.

    (but at least it’s not one of those “sexy css3/html5” articles, which is quite refreshing! :)

  28. 28

    “…Multiple hacks will be required, needing separate stylesheets for different versions of IE, making the code bloated and less maintainable and making the website slower…”

    So, inserting IE-only required lines into your regular stylesheet does not bloat code? (display: inline to fix double margin for example)…I guess NOT.

    …and IF your layout requires additional IE-ONLY-CSS-file(s) to request: so be it. It will not slow other browsers down.

  29. 29

    Chris Korhonen

    June 7, 2010 5:05 am

    The methodology here seems to be the opposite of common sense.

    Internet Explorer has historically suffered from rendering problems because it relies on a buggy interpretation of web standards. Its gotten better over the years, but you still have that legacy.

    When developing a web site, it makes sense to start development in a browser which is more standards compliant in terms of how it renders documents. That way, your pages are more likely to work across more browsers and you are not building in dependancies on browser bugs. Its a lot easier to go in, test your pages and handle these bugs later.

    So, please don’t use Internet Explorer first, or you are going to be writing more code and having headaches in the long run!

  30. 30

    David F. Weiss

    June 7, 2010 5:10 am

    Nice article Louis! There are some solid concepts here on cross-browser CSS. As for which browser to start testing in, I do believe you should start with the “good” browsers first. Firefox, Chrome, Safari and Opera have more CSS3 support so if your site is going to use that, better to code that from the beginning and create the best experience possible early on in the project. Coding for IE6/7 will often require separate stylesheets anyway, which doesn’t necessarily need to be done at the beginning of a project.

    However, the most important thing is a client’s target audience. So if analytics show that a client’s site visitors use IE6/7 more than anything else, then I would probably start there, while trying not to throw my computer out the window ;-)

  31. 31


    June 7, 2010 5:11 am

    very good article, thx :) … though – i’d neither start nor recommend starting a project with ie as the main reference.

  32. 32

    Like quite a few have already commented, start with IE?? What the… I re-read the sentence a few times just to make sure I’m not seeing things. Coding in IE first then FireFox is like… paint the whole canvas with the ugliest colors you can find first then work your way back to the nicer colors, if the above sentence doesn’t make sense to you, that’s the point :-}

  33. 33

    Ben MacGowan

    June 7, 2010 5:25 am

    Thanks frietkot, but yes, I do realise that different browsers have different rendering engines. However in my experience, websites which are built in Firefox 90% work flawlessly in Opera, Safari and Chrome.

    I still always check my work in those browsers, but as these more popular browsers are more standard compliant then they are less hassle than trying to make non-standards code for IE work in Firefox.

    Another way at looking at is, IE offers conditional commenting for style sheets whilst the others don’t. Surely it therefore makes more sense to add styling in these conditional commented stylesheets to make the page work in IE, than using unreliable hacks which result in invalid CSS to make the page work in Firefox etc.?

    Glad to see I am not alone in my thinking and Vitaly put it perfectly in his comment: “It just makes more sense to start designing in the right environment and fix problems in the “less comfortable” environments after that.”

  34. 34

    Ben MacGowan

    June 7, 2010 5:31 am

    Agree 100% here with Vitaly. We cannot really trust the global statistics, however nice it would be to. The Mashable article which referred to IE6 only have below 5% of users was in fact on for the United States. Worldwide IE6 still holds a 14% market share.

    I am a strong believer at looking at your website’s users. Are a higher percentage of people using IE6? Most of us designers and developers will probably find that in our blog stats less than 1% are using IE6 which definitely warrants not supporting it. However like Vitaly said, in a more corporate environment, people are still stuck with IE6.

    I even read somewhere that companies are staying with IE6 because popular websites such as Facebook who drop support, mean that their employees will stop visiting within work hours.

  35. 35

    John Robinson

    June 7, 2010 5:40 am

    As many have said above, starting with IE and building upward to better browsers is just wrong. So very very wrong. Code your HTML and CSS *correctly* first and foremost, and then hack your way to whatever fixes you might need afterwards.

    The benefit to this is that you can keep all of your IE, IE6, IE7, IE8 specific fixes in their own files without compromising the good stuff. Do the same thing for proprietary CSS3 styles too. Yes this means there’s a bit more organisation required, but that’s nothing compared to clean code.

    “… look exactly the same in every currently-used browser. Unfortunately, that goal is generally agreed to be almost impossible to attain.”

    I’d like to know who generally agrees with that statement, as it’s utter nonsense. Getting pages looking the same in all browsers isn’t impossible by any means. Unecessary, certainly. Costly, definitely. But by no means impossible.

  36. 36

    I always start with a simple reset stylesheet. You’d be surprised just how many of IE6’s quirks and bugs can be ironed out before you even begin to code. I always start off in Firefox too, if you use a reset stylesheet, you won’t have to change much for IE6.

  37. 37

    What he actually says is to check your layout in IE6/7 early on, not develop in IE6 from the start.

    I personally develop in Firefox, Chrome and IE6 checking each browser periodically, when i’m done – i never have to fix anything, as i’ve already done it along the way. Much easier.

  38. 38

    Why do you have to start with either IE or Firefox?

    I always start by launching Firefox, Chrome, Opera, Safari and IE8 as I use Spoon’s Browser Sandbox for launching IE6 as well. Even though I look mostly at Firefox when developing every now and then (pretty often actually) I refresh in all the other browsers. After I’m done I take a look (using Spoon again ) in IE7 and older versions of the most common browsers.

    Useful article by the way:)

  39. 39

    Yeah I have to agree here with the comments. Doing it wrong (non-standard wise) first then fixing it to work with standards makes no sense to me. IE ^6^ is really the only one that needs fixed, seven is usually close enough and webkit, FireFox and Opera are rarely rendering differently. The IE conditional statements make it easy to target IE 6. And I rarely need more than a few styles re-written (on a site where the base css file is a 100 or so lines long). So it isn’t that much overhead to maintain that IE ^6^ only file.

    So I say, like some others, do it right first then fix IE. Also for IE try FireBug Lite. It works pretty well.

    And the resets help tremendously. Here is my own little success story. On a file I inherited that was 1800-ish lines long (written years ago) I was able to get rid of all but a few hacks and loads of extra lines for IE just by adding a reset. And I took an extra 12k off the file size.

  40. 40

    Scott Petrovic

    June 7, 2010 6:13 am

    Good article. What browser to start coding in is debatable, but I think Firefox is just easier because of the development tools. Aligning an image perfectly is a lot easier in Firefox using firebug than IE trying to guesstimate.

    I learned a few thing in the article, so I enjoyed it. You can always tell a good article by the amount it stimulates its audience.

  41. 41

    Louis Lazaris

    June 7, 2010 3:13 pm

    This is my first response in this article today because I was very busy with other things, and did not even know until late in the day that this article had been published. I also didn’t get a chance to read the comments until only a few minutes ago.

    It’s great to see so many have commented and are sharing their views on their own personal preferences, especially with regards to what browser to use first to ensure cross-browser CSS.

    Here are my thoughts on the comments from those who are opposed to starting development with IE6 or IE7:

    In no way was I implying that a website’s CSS should be coded using sub-par, less-than-standard code for certain versions of IE. There is no way I would ever encourage such a thing.

    The fact is, you can create a pretty accurate layout using IE6 or IE7 without having to resort to too many hacks or sub-standard methods. If developers take the time to understand the principles of CSS, and IE’s most common problems (which is what the rest of the article covered), then developing for IE first will not be a major problem, and will not, as some suggest, cause developers to use less-maintainable code.

    If you know what kind of CSS code is the best to use (that is, up to standards, best practice, etc), then you can limit yourself to that code and develop for IE6 and IE7 with fairly good results. Obviously, you will run into problems with margins and some other issues. But they are not difficult to fix, and should not affect your CSS in other browsers too much. If it does affect other browsers, you should know from experience with what is standard, and you can put comments in the code, or use IE hacks early, if necessary.

    Also, I was not suggesting that IE6 and IE7 be used and the other browsers be ignored until the QA stage. What I was recommending is that IE6 and IE7 be used *very early* in the CSS development, and not just tested at the end when you’ve committed to a lot of CSS, and you’re then required to use a ton of hacks. The purpose of my advice to use IE first (or at the very least, very early) was to prevent unnecessary hacks and conditionals, and thus to minimize them.

    I also have a feeling that many of those who have said that it’s wrong to develop first in IE6/7 haven’t actually tried it. Yes, it’s true that the other browsers are more compatible with standards, but that’s the reason that using IE first is better. If you do your best to limit yourself to standards-compliant, and best-practices CSS from the start using IE6 and IE7, then there should be very few problems to correct in the other browsers — because you’re using standards-compliant code. If you can’t get IE to work with the best possible code, then just use a hack or conditional. This will ensure that the only hacks/conditionals you use are the ones that are absolutely necessary. This way you’re not putting in hacks for IE simply because you don’t understand how the CSS works.

    And finally, in the article I noted that we should not use IE6/7 first if those browsers don’t hold a high market share in the usage statistics for the project being developed. You should only take that advice if you know that IE has a large market share in the niche or client work you’re involved in.

    But I’m glad the article went over well (for the most part), and I hope a few of you will try using IE6/7 first (if nothing else, just to prove me wrong!) and see if it doesn’t work out well. I think it works fine for my own purposes, and I’ll continue to do it to the extent that it’s necessary.

  42. 42

    Coding for IE first is some of the worst advice I’ve ever read.

    Code to standards FIRST, then apply fixes/hacks as needed. Coding to render in IE6 or IE7 first is a recipe for future disaster and it’s a huge part of the reason it’s taken almost a decade for IE6 to die.

  43. 43

    “We should be focusing on progressive enhancement techniques instead.”


    And progressive enhancement means starting with the poorer scenarios, such as javascript off or an ancient browser such as IE6.

    Graceful degradation means starting in modern newer browsers, relying on modern support (such as PNG transparancy) and providing a fall-back for IE6 (usually accompanied with hacks, exceptions and less than optimal results).

    Most of the time it turns out the design doesn’t need transparancy or can do with faux transparancy.

    Or you can make real rounded corners visible in IE6, provided you start with it. Tell me it’s somehow better standards coding if you -moz-border, -webkit-border-radius, it and give IE6 the square middlefinger, because it doesn’t work nice with you.

    Lots of CSS3 and HTML5 is not standard, nor recommended (yet).

  44. 44

    Please let IE 6 die! It is time for that old Browser. Even Microsoft recognized that.

  45. 45

    NEVER code in IE first. That’s a well known rule. Code for modern browsers than fix in the others…it will make your life much easier

  46. 46

    Opera is at less than 1% market share, so many professional web design companies don’t include it in browser testing. There’s really no point in trying to make your site work for Opera, it’s a waste of resources.

  47. 47

    Breno Ribeiro

    June 7, 2010 6:58 am

    “If your code for IE6 is incorrect, you are doing it wrong. You can perfectly start with IE6 and code your HTML and CSS correctly.”

    Do you use the “float” or “position” properties? then you already are coding wrong if you start with IE6 or IE7. There are so many bugs for them…

    “Getting pages looking the same in all browsers is nonsense. Web is not print.”

    Yep! But it will never be impossible.

  48. 48

    I’ve been using CSS for four years, and was introduced to the horrors of the IE6/7 rendering engine right off the bat. Since then I have found that if I remember a few simple things I can code for every browser with out needing hacks.

    First, if I want to support IE6 I’ll avoid using transparent pngs (a pain in the butt), and I can’t have nested divs with overflow set to hidden. Second, I just accept that if I’m using border properties to divide links, my border will be 2x as thick in IE6/7 and compensate for the difference. (Rarely a problem because I almost never want more that a 1 or 2px divider.) I also know that I have to set the overflow property on floats to hidden. Also I avoid positioning things in a way that triggers the IE z-index bug, if I have to “trigger” that bug, there are simple work-arounds that just involve clever placement of z-index properties . I also remember that CSS3 doesn’t work. (Why does IE have to be so far behind? –Don’t answer that.)

    It may sound crazy, and I may have left out one or two things, but I can create the same advanced layouts as many others do using hacks, but without the hacks.

  49. 49

    Erwin Heiser

    June 7, 2010 7:03 am

    Ugh… this is easily one of the worst articles on SM ever. I can hardly believe this slipped past the editors.
    Code for IE first? Really???

  50. 50


    June 7, 2010 7:03 am

    Designing for IE6 first?! Didn’t expect this from Smashing Magazine

  51. 51

    Wilfred Nas

    June 7, 2010 7:04 am

    coding for IE6 first is just plain wrong. If you still have problems fixing the things IE6 throws at you after all these years, you shouldn’t be in web development. Sure IE6 is crap, but it has been this way for many, many years. All of those bugs / differences you should be able to code for…

  52. 52

    Great Article. Thanks for listing so many helpful tools, especially the CSS Reset.

    And to throw in my opinion on the above comments, I don’t think Louis was saying that you should develop using IE. I think he was saying you shouldn’t wait until your site’s done to test it in IE, which would be a great way to spend hours more on a project hunting down CSS hacks.

    It’s best to develop using the browser that has the best development tools for you, AND keep the other browsers open while you work so that you can test as you go. This will save you a lot of time and headache.

    Thanks again Louis!

  53. 53

    (Oops, this is meant to be a reply to the OP, not to the comment I actually replied to!)

    Code for IE’s broken interpretation first?

    That’s just plain dumb.

    Build it right first, then accomodate browser foibles – be it IE, Safari, Firefox, Opera or whatever. Nine times out of 10 if you do it right in one of the “better” browsers then the others will be OK too.

    Coding to the broken standard and then cobbling hacks together for the more accurate renderings is extremely short-sighted and sits counter to the whole point of having the standard.

    So you code to cover IE, create further rules to “un-break” the broken CSS you’ve had to use to get IE to play. Then IE gets updated or something changes and you fix your CSS so IE doesn’t wet over the carpet. Oh noes! Everything else broke too… let’s do that. Rinse and repeat.

    Just build it right once. Patch the failings when you need to.

    Honestly I can’t believe that a web professional is advocating this totally backwards approach. The mind boggles.

  54. 54

    I’m sorry, but I disagree. Using Firefox, Opera, or Safari first (even with differing rendering engines) display the code in a more pure form, not how the browser interprets what it thinks you might have meant by the code.

    In other words, using those browsers first to test will REALLY show you your actual mistakes. IE6 “mistakes” could be misinterpretations based on a variety of factors.

    I’m another one who is surprised this article suggests testing in IE6 and 7 first, and feel the argument made here that testing in Firefox first leads to hacks is completely false. I test in Firefox first and, more often than not, only have two to three lines of conditional CSS, if any at all, to write to make the experience match in IE6 and 7.

  55. 55

    This is like stepping back into the 90’s with advice like this and the saddest part is, some of you think this is a good, no… a “great article”. I also disagree with Vitaly… 40% usage?! How many of those browsers Vitaly, are from corporations or big businesses that will not and cannot upgrade because of conglomerate politics? How many of those IE6 systems are stuck there because of stuffy CEO’s that need to give the OK in order to do that and lack the common sense to? How many of those machines are in the hands of the blissfully ignorant?

    Saying IE6 still owns 40% of the market share in browsers is like saying Facebook has 4 million members. How many of those Facebook members have more than 1 account? How many of those Facebook users have more than 5 accounts because they play those ignorant and time/life-stealing Zynga-based games?

    Putting IE on your list first is like putting the cart in front of the horse. It’s ignorant advice to say the very least.

    Also, to “Terry” re: Opera, look at the Opera statistics for Europe and Asia, and you tell me that is <1%, it is also not a "waste of resources" if you're doing the job right and doing your coding clear and concise.

    This article, if it were on paper, I wouldn't even allow it to line the litter box of my pets.

  56. 56

    Breno Ribeiro

    June 7, 2010 7:08 am

    Because of ancient browsers? Or text based browsers? Or blind people?

  57. 57

    It’s not April 1st right? For a second first I thought this was a joke.

  58. 58

    I agree, with a reset style sheet and starting in FF I rarely have to do anything special for IE6, sometimes its just a matter of tweaking one or to classes.

  59. 59

    Ben MacGowan

    June 7, 2010 7:13 am

    Wouldn’t call it the worst article on SM. There are some good points in the article e.g understanding the box model. Some people don’t understand these.

    The only point which really lets this article down is ‘starting with IE’.

  60. 60

    We should learn to do things the right way. IE6 doesn’t encourage us to do so.

  61. 61

    “many professional web design companies don’t include it in browser testing”

    The good ones do.

    The “1% market share” depends on the market you’re looking at. Sure Opera isn’t as prolific as other browsers but that’s no reason not to support it if it is running close to standards – which it is.

    Don’t forget all those Wii’s and mobile devices out there that use Opera.

  62. 62

    Sorry but i should use FF for fast development, then i should test in IE6, also the IE bugs you can expect them while your slicing ….

    one more thing i don’t need all of the previous reset only
    *{margin:0; padding:0} is pretty good

  63. 63

    There was a day when I thought “If it works right in IE, I’m done.” Amazing how things have changed. Now, I code for Firefox, and in all serious-ness, I’m fine if a site isn’t compliant with IE 6. I’m sick of having to support a browser that is anything but one. Microsoft is responsible for the plague on the web and they’ve done too little too late to stem that tide.

    I code for FF, then will make changes so it can run in later models of IE and other browsers. It’s a sad thing that the world doesn’t understand that thanks to the browser wars, we’re required to do significantly more work just to ensure the site looks/works as intended across multiple clients.

    There’s a reason for standardization.

  64. 64

    Yes, I use absolute positioning. If you correctly identify the parent containers as relative IE6 should give you no problems. Naturally I use floats too, without problem or silly hasLayout/zoom statements. An overflow:auto and using padding for spacing/gutters solves nearly all float “problems” (the behaviour of floats is correct). will let you know of the bugs and solutions. Yes, IE6 is buggy, no it is not wrong to use standard code that renders acceptable in a buggy browser.

    It is impossible to get functional industry websites render exactly the same in all browsers currently in use. There are differences between font-rendering in different versions of Firefox. These can not be solved. You wouldn’t want to anyway, even if you could – it would be as useful as making sure every smashing magazine book or Sunday’s newspaper looks exactly the same and contains 0% pressing anomalies.

    (And having to rely on browser specific hacks for to make IE present acceptably would be like providing a different set of reading glasses with the smashing books)

    I’ll go further than the author and state that designs should be implemented for IE6. The first thought should be: How do I make this work for IE6 while adhering to standard code? That mindset creates designs that need no exceptions, and provide the best experience to those lower on the technology/accessibility scale.

    IE6 should not be an afterthought. If IE6 is the starting point for a design, you can make it render the best representation of the design. I haven’t heard of any modern browser that has troubles with standards complient code that initially renders fine on IE6.

  65. 65

    What started out as a good article ended up failing miserably. I have 2 main gripes:

    1. This article fails to discuss the most important thing that affects CSS Box Models… DOCTYPES and Quirks mode. How can you NOT talk about the importance of understanding the effects of Quirks mode when discussing the CSS Box Model????

    2. As others have pointed out already, the suggestion to code to IE6/7 first is just plain stupid.
    “It’s much easier to get a layout working first in IE6 and IE7, then fix for other browsers, than to do it the other way around.”
    How do you “fix” for other browsers when it’s IE6/7 that are display things incorrectly? It’s MUCH easier to develop to standards compliant browsers and then “fix” the IE6/7 bugs than it is to develop to a buggy implementation and then try to change standards compliant browser to behave in a non-standard way. That quote has got to be one of the dumbest suggestions I’ve ever read. Come on Smashing, time to give your editors a kick in the pants.

  66. 66

    Jordan Miskowicz

    June 7, 2010 7:31 am

    Completely agree with you Ben!

    I don’t think any coder/developer should work in any specific browser because that’s what is “expected” of them. Code in the browser that you use in your daily routines–the one that you are most comfortable with. Whether it’s Firefox or Chrome or Opera or even IE.. work in that browser and simply check as you go.

    Recommending someone how to work is not the best solution possible. It hinders motivation and decreases efficiency.

  67. 67

    I always use AOL as my starting point.

  68. 68

    Tobby Smith

    June 7, 2010 7:38 am

    This article does not present any relevent information about cross browser coding. If we’re talking about cross browser coding, how bout mentioning degrading CSS for older browsers? A debate on using JavaScript to even out browser bugs? I think by now most of us understand how to use the box model.

    My point is when it comes to web development, I am looking for articles that go beyond the same ol’ cookie cutter “How to use CSS” articles we see everywhere. This article clearly shows that the author didn’t do their homework at all. Smashing should be ashamed.

  69. 69

    Tobby Smith

    June 7, 2010 7:38 am

    Well said sir…

  70. 70

    Maybe it’s just me but from my experience, i’ve learnt that first we understand a theory, a convention or a standard then we apply it and then if there are differences we try to fix them.

    Careful people with what you publish. The (serious) experienced ones will tell this article shouldn’t be posted not because it doesn’t make sense to work that way but because people just starting out use your articles as a bible or something.

  71. 71

    The idea behind starting to work in IE6 / 7 first is that you code for the lowest denominator. That being said, why not code for IE5 first? Or IE4. Surely, there must be someone out there using them.
    Yes, I’m for coding in the most standards compliant browser and then maybe(!) add code for older, iffy-er browsers.

  72. 72

    As Vitaly pointed out in a tweet just a minute ago: “Smashing Magazine’s articles do not necessarily reflect editors’ opinion. We are a platform for discussions, not one unified voice.”
    While some of us don’t agree with the article’s viewpoint, the idea is worth noting and, who knows, perhaps there are projects to which this type of approach is more suited than our usual, “modern browsers first, then ol’ dodgy IE”.

  73. 73


  74. 74

    I agree with developing first on Internet Explorer first if your client base is largely corporate, as they’re often still on IE6! So as far as making the distinction, it’s ok.

    One point though, IE6 does support fixed positioning of background images on the <body> tag (only).

  75. 75

    [sarscasm] I design for IE5.5 first, use tables for layout, transparent gifs for spacers and shims, and filters for transparency this approach seams to work fine for me…[/sarscasm]

  76. 76

    I develop my sites with Safari before tweaking it for IE!

  77. 77

    First of all, please stop saying that this or that opinion is “plain stupid” or “dumb”. Insults don’t make you guys smarter. People have habits when working, let them be. Are you good enough at work to be writing for SM? Come on. Let’s discuss without that arrogance.

    Secondly. I have a very simple question. Why not work with all possible browsers at the same time? Why not use firefox with firebug to test, but also have instances of chrome, safari, opera and IE open to test at the same time? Does it really take so much time? It’s just pressing F5… clear some caches… you can even use Internet Explorer Development Toolbar (ok, yes, I was kidding on that one). You can even have another laptop(s) in your desk with older version(s) of IE running, or some of those tools that compare renderings in different IE’s (Expression Web 3).

    In the end, you don’t develop or write code in a browser. You do it on the notepad, or code editor of your choice. Those are browser-war-free. Upload to server, press F5.

    Seriously guys, I prefer to spend time doing this, that wasting it tweaking, hacking, and fighting. Let me know if I’m wrong.

  78. 78

    We most certainly do. Opera still commands a chunk of the mobile market as well as set top boxes and consoles.

  79. 79

    Andrew Armitage

    June 7, 2010 7:52 am

    Whatever happened for progressive enrichment? Are we forever going to be held back by IE6? I hope not or the web we love will be going nowhere fast.

  80. 80

    I’m pretty sure he said it depended on audience. My website for example, very rarely gets hits from any version of IE, but one of my clients (a shipping company) commands a large Italian and Western European audience. They have a steady 30% of visitors still using IE6.

  81. 81

    It doesn’t really matter why IE6 still represents such a high proportion of visits to some websites, the fact is that it does. Last month, 33.9% of the visitors to one of the sites I work on used IE6. They’re not lesser visitors because of that; they’re just browsing from work.

    I used to work in the same way as Louis as the percentage was quite bit higher a couple of years back. I can see the logic. But it’s definitely quicker working in a decent browser first.

  82. 82

    I am agreeing with the writer…
    While I often start with firefox because of fire bug, but when I go to far I almost always have to make major changes in IE…
    I have found that constantly changing back and forth as I work saves a lot of headaches during the process. I have found a great add on for firefox that lets me switch back and forth while staying in the firefox window.
    But it is a fine line to walk. You cannot just disregard IE because “You” don’t like it…unfortunately, IE is still the most used browser. While we as designers understand the concept of “modern” browsers most laymen don’t, and even if I educate my client, how do I educate his clients…and so on and so on…
    So in short, yes…you have to design for IE early on the design process…

  83. 83

    Jeremy Carlson

    June 7, 2010 7:55 am

    Agree with Ben and Vitaly. You have to go with what YOUR visitors are using. The company I work for has around 20% of our client’s visitors using IE6. We can’t just ditch it with that many people using it.

  84. 84

    You are exactly right!

  85. 85

    cancel bubble

    June 7, 2010 7:58 am

    I was going to leave a snotty comment about how the box model is SOOOOO played out, just use a valid doctype, but then no mention of doctypes in the article?

    So here’s my snotty comment :)

  86. 86

    I have stop supporting ie6 as well.
    I feel the sooner we stop supporting it the sooner it will go away…

  87. 87

    John Robinson

    June 7, 2010 7:59 am

    As Breno has pointed out, there are numerous bugs with IE6, and even 7 (and also 8, and FF, and Chrome, and Safari – they don’t all get away free), that aren’t accounted for by coding to standards. To highlight just a few all too common real world examples – IE6’s double margin float bug is fixed with a hack that is not correct CSS. IE6’s rogue character cloning on lines of a certain length is fixed with a hack that is not correct CSS. IE7’s incorrect implementation of floating elements above cleared elements (such as form labels and adjacent fields) is fixed with a hack that is cumbersome and superfluous HMTL, or a hack that is not correct CSS.

    If you code to IE6 (and to some degree 7) you are not coding to standards. If you code to standards your stuff won’t work in IE6 (and to some degree 7). Maybe you’ve been lucky to have never had to float an element?

    The best solution for the industry’s progression, and our sanity, is to code to standards and then fix any problems seperately. Filling your HTML and CSS with extra code for IE6 etc from the start (which you ARE doing if your layouts are flawless in IE6) is code bloat and is asking for trouble.

    Cross-browser means what the industry understands it to mean, which I am quite confident means the main browsers in use today that “support” at least HTML4 and CSS2 to a decent degree. Edge use cases such as Netscape 1 or Amiga’s browser can safely be ignored.

  88. 88

    John Robinson

    June 7, 2010 8:09 am

    I would hope that not many people *really* code their entire site for the more compliant browsers and then finally check it all in IE6 and fix bits one by one. The important point that is being made is that whichever small bit of code you are working on, code it with standards in mind and then add whatever extras you need for non-compliant browsers seperately. This is probabaly all going on in tandem as we code, but it’s the mindset that is important.

  89. 89

    Totally stupid to start with IE for anything. Begin with a solid standards complaint browser and then make some accommodations for the weaker browsers.

  90. 90

    I agree, I don’t think he mentioned at any point to open IE first, I understand he said to test early!
    The problem with the browser wars, the mac vs pc wars, all the internet wars…each side only reads what they want.
    Most people here apparently wanted to read that the writer said open IE first…

  91. 91

    Mike Simmonds

    June 7, 2010 8:15 am

    “Use Internet Explorer First” – Seriously I cannot believe I have just read an article on Smashing Magazine with those words. All this method will give you is bloated code and a bad time for users.

    It’s views like this that stop design/development from moving forward, what happened to graceful degradation?

  92. 92

    Breno Ribeiro

    June 7, 2010 8:21 am

    Coding for IE6 first is just wrong and i will not argument on that any more.
    As for the reference, i do like this one:
    in the sitepoint reference, i have too many clicks to see a css property… for newcomers, sitepoint is a good start since it explains about each property with more detail than quirksmode.

  93. 93

    There are numerous bugs, agreed. There are numerous hacky work-arounds, agreed. It is perfectly possible to create a floated or absolute positioned website in IE6 and never stumble against these bugs, because you know how to avoid them.

    I float elements, I like floating entire designs. While I was unlucky to happen upon some bugs and headscratching, I was lucky to learn how to avoid it.

    I am afraid of divitis-diseased code.

    You don’t need extra code for IE6!

    My documents are less bloated and are more uniform in presenting. You use exceptions and hacky stuff, not me.

    Cross-browser means what the industry understands it to mean. Cross-browser is an industry standard term from the late nineties. You can go all language pragmatic on me, but just because you mistake cross-browser for multi-browser or revive a term set by the industry does not mean cross-browser means something different all of a sudden.

    Keep on coding websites that fall apart in IE6. I’ll have more e-commerce shops to optimise the conversion rate for.

    If you can’t correctly float an element in IE6 without resorting to non-standard code or pulling ur hair out, that says a lot more about your own skill level, than me supposedly unable to float elements without running into bugs.

    Using padding instead of margin to combat double margin bugs is not a hack. It is an example of sensible coding for the lowest denominator (which still has a formidable market share). It is an example of a coder who starts with clean standard code that initially renders fine on IE6 and makes for easy enhancement in modern browsers. Dropping an IE exception style sheet in your design, because your forgot or didn’t think/focus on IE6 while building, makes you the lazy bloatcoder.

    Response to below:
    U act as if margin and padding carry semantic information, they are just tools to make your content look a certain way. Using a 10px white border on a white background is no more “hackier” than using margin or padding.

  94. 94

    John Robinson

    June 7, 2010 8:32 am

    Using padding instead of margin to avoid IE6’s margin bug is most certainly a hack. A hack that shouldn’t be necessary, and a hack that makes you use a property you don’t intend to use. If we’re using padding to avoid the margin bug, how do we then use padding when we want padding? An extra container element? No thanks.

  95. 95

    You lot are being highly illogical captains.

    Like noted once in this discussion by a real developer: You don’t even need hacks or exceptions for daring designs.

    1. Bloated code

    Standards-compliant code build with IE6 in mind is far less bloated than standards-compliant code build for modern browsers, and made to work backwards for IE6+ with exceptions, style sheet overrides or ie7.js.

    2. Bad time for users

    Creating a page that renders correctly in IE6 and enhancing it, will create a better experience for everyone in the access chain. Creating a page for modern browsers and using a png hack do transfer your design to IE6 makes for increased loading times, and less richer experiences.

    3. Design and development can move forward all it wants.

    It is business reality that is being addressed here. You are not helping your clients by putting your own ego, lack of legacy browser coding skill or views on webstandards before creating an implementation of a design that communicates its message to a hefty chunk of users. If you are ignoring IE6 and removing focus, you are not a good web developer (at least one that makes money for their clients).

    4. What happened to graceful degradation?

    It got superseded by its prettier cousin: Progressive enhancement. If the industry wants to move forward to an accessible web, then enhancement should be taken over degradation.

  96. 96

    Smashing Magazine is not an official channel for webstandards (luckily).

    These concern opinions, not facts. Don’t say it is Smashing Magazine that states the world is flat. They don’t have a responsibility for webdevelopers starting out to state nothing but well-agreed upon fact. That responsibility lies solely in the webdeveloper, who ought to be able to find the specifications in the official channels and form a working opinion on that.

    Louis gets paid a bonus if his articles are talked about. This 100rd post is positive for him. Smashing Magazine gets a bonus if articles get talked about and generate discussion.

    You web folk should know by now that this is fertile ground for link bait and troll bait. Louis is essentially just trolling us all and laughing at the furor of the comments.

    BTW If Louis would have redesigned Smashing Magazine, I’m sure it would have worked with IE6 from the start. No wonder Vitaly doesn’t share his opinions. I will go with the solid webdeveloper who knows how to make a page work in IE6 (being Louis in this case).

  97. 97

    Start with IE first?
    The point is not for sites to look identical in all browsers…
    Actually, I’m not even going to start…
    What a stupid post. Christ.

  98. 98

    Kevinjohn Gallagher

    June 7, 2010 9:22 am

    I am sadly not surprised to see so many people jump on a bandwagon here, withotu actually reading the article’s content.

    At no time did the Author suggest coding for IE6 and then going through each of the “modern browsers” and making it look good for them.

    At no point in time did the Author suggest writing bad or invalid code aimed at IE6 and then going through each of the “modern browsers” and making it look good for them.

    At no point in time did the Author suggest coding for IE6. He didn’t, re-read it before throwing your toys out of the pram.

    What the Author did suggest was that by writing your code as normal, and looking at it first in IE6/7, you would see any potential bugs early. This is really just common sense. Far too much of my work in the last 2 years or so has come from “fixing” websites where designers/developers haven’t even tested their site in all the browsers.

    You may or may not agree with that, and thats cool; but ask yourself this: How many times do you see someone write some code and test it in 1 or 2 browsers (max) on their current OS and then go back to developing until the site is “done”?

    We are all creatures of habit, and sadly far too many people have become used to churning out bits of code without knowing their full impact because “Modern Browsers” handle it well. There is no great need to write invalid hacks for IE6 anymore, and if you don’t want to support that browser for any reason, then thats cool. But to simply write code and never test for it is really daft – it takes 30 seconds.

    Sadly, i see an awful lot of spoilt people on this page; so ready to jump on someone with a different opinion from the norm that they didn’t even read what the Author had actually said.

  99. 99

    I agree with you completely. I’ve stopped supporting IE6 in my sites as well.

  100. 100

    #1. I don’t even put IE6 into consideration, if we keep catering to the IE6 users they will never upgrade.

    #2. This is actually a question, what about reset css, like the one that comes with the Are these any good?

  101. 101

    Yeah, like the Smashing Magazine redesign not working in IE6 and telling us it was a conscious decision. Really shows the benefits of the mindset of ignoring an old browser and coding something that only modern browsers can interpret.

    The sensible thing to do really is locking out a fairly high percentage of users. It’s a wonderful mindset. Just evolve it a bit more and you don’t even have to look at IE6 anymore, because it’s IE’s fault that hacking in solutions a posteriori is not as successful as could be.

  102. 102

    “What the Author did suggest was that by writing your code as normal, and looking at it first in IE6/7, you would see any potential bugs early”

    I’m not sure you really grasp the issue people are getting at here. If you develop with the intention of creating the design as it is from the mockups in IE6 then you will inevitably have to use hacks along the way, creating bloated over complicated code as the basis for the entire project. So if you develop in IE6/7 first, you will come across bugs that are not a direct result of your markup / css, but a result a browser quirk. As such, you will be forced to find workarounds and fixes, which will have a direct result on your projects code.

    That’s a bit shit really, isn’t it? Would it not make much more sense to use a browser that doesn’t have so many quirks to deal with, so if something is wrong its pretty likely to actually be a problem with your code rather than the browser.

    None of them are perfect, be aware of issues with particular browsers as you develop; jump in and check it in the usual suspects fairly regularly, write solid standards compliant code and you should have few issues, but for god’s sake don’t start the process by developing for a fucking 9 year old browser from the outset, that’s just stupid.

  103. 103

    You apparently didn’t read the entire article yourself, else you would have noticed this line:

    “It’s much easier to get a layout working first in IE6 and IE7, then fix for other browsers, than to do it the other way around.”

    There is a big difference between testing during development in all browsers, and developing to get a layout working in one browser and then going back to “fix” for other browsers. The author has explicitly suggested the latter.

  104. 104

    Mike Simmonds

    June 7, 2010 10:18 am

    Bair, with all respect, please do not judge others ‘coding skills’, you talk of not putting ‘your own ego’ but yet your comments seem to be doing exactly that.

    I think to be honest you have missed the point of a lot of the comments here. It cost time and money to support a failing browser that is nearly 10 years old.

    I’m all for progressive enhancement, but 10 years, no. Unless the client is paying.

  105. 105

    Mike @ SiteOne

    June 7, 2010 10:29 am

    I always use Firefox to design and develop with first then test against IE and tweek for IE.
    As far as IE6 is concerned just ensure as site can be read and navigated. If it doesnt line-up – too bad! Upgrade. Oh and I add a friendly notice on the homepage to encourage upgrading.

    Interesting debate…

  106. 106

    A browser’s age doesn’t matter. Its market share matters. Setting an agelimit on browser support is silly. I can’t understand you are reasoning like that. It is totally irrelevant to its market share.

    If we go back 5 years, we were all bitching about IE6, yet making websites that worked fine in IE6. It doesn’t suddenly cost more time or money to build a website nowadays than if you build it 5 years ago. But let’s say it costs more, because you charge your client for backwards compatibility – All the more reason to start from the IE6 mindset and build upwards, instead of charging for hacks.

    I offer IE6 compatibility inclusive in all my implementations. If it costs me more to develop a website through you, to make it work in IE6, then I would have been better off buying a website 5 years ago made for IE6 (that will probably run fine in modern browsers).

    What does that say about your skill level and services? I won’t suggest anything or judge you, so please answer that yourself.

    I know it is a sore spot for those who can’t code IE6 without running into bugs or needing massive exceptions and hacks. I think webdevs who have no problem with creating a IE6 implementation agree that lack of skill, ego and ivory tower standards are used as an excuse. The buggy renderer of IE is still used as an excuse for implementations that are just not up to par. You either cut it or you don’t.

    Code bloat and IE6 only go together if you don’t know what you are doing, and are patching the problems you create for yourself afterwards.

  107. 107

    Like many other people here, disagree with design for IE6 first, we have to design for the good browsers first, then fix any problem in IE.
    Also disagree with the reset CSS, in most cases it’s unnecesary. You might want to add a SET css, where you can define standard attributes to anything, but there’s no need to reset, then have to set again.

  108. 108

    You should always code cross-browser. I recommend using css resets or a css framework which pretty much always includes a reset and or conditional commenting for IE. If you really want to use your own code do it so with your own naming conventions and make it reusable.

    By the way this is quite the recent article where I read a lot of ‘Internet Explorer’ even combined with the version number 6, bloody scary! Glad to see a few stopped supporting it. With my recommendation you don’t have to do anything special to actually make it look good in IE6. I even do something special for IE6 visitors since they sometimes give me a nice coding challenge (e.g. RIA websites);

  109. 109

    With IE6, it depends on the audience for your site. At below 5% of domestic users, it’s becoming increasingly irrelevant for consumer sites – close to IE5 a couple of years back – although equally, it’s about the same as Safari / Mac usage.

    On the other hand, a lot of companies still enforce IE6 internally.

  110. 110

    Dean Faulkner

    June 7, 2010 11:20 am

    A technical standard is an established norm or requirement. It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes and practices. – source: Wikipedia.

    “Standards-compliant code build with IE6 in mind is far less bloated than standards-compliant code build for modern browsers” Source: Bair

    By understanding the definition of standard – the same code written to standards and rendered by a web browser that complies to those same standards, should give the same result. Standards are written to avoid compatibility issues – if your standards compliant code written for one piece of software does not give the same result in another, you do not have 2 pieces of software that comply or support the same standards.

    The point that some people are missing here is that IE6 does not comply to the standards that we write for. Just as building standards are created to ensure uniformity in the building of structures, web standards try to do the same for the building of websites. Using IE6 – a non compliant browser, is not the correct foundation to be building any standards compliant website on.

    As a developer I would be able to accept it if IE6 did not support parts of the CSS standards – as this would mean that the non supported code would be ignored. Just as with rounded corners, drop shadow and CSS transitions. But it does not, it renders some of the standard compliant code in a way differing from how the standards define. This is the problem we all have, its the reason we object to being told to use IE6 as the calibration method for our code.

    This problem is in existence because people are being given no reason to upgrade their browsers, they are not missing out on anything so why should they upgrade? Graceful degradation or Progressive Enhancement should be the solution to problems that occur when browsers do not support parts of the standard. Technically both PE and GD are the description of the same objective that we all want to acheive…

    Writing code that is universally and uniformly rendered by all browsers, with the final result depending on the amount of the support the browser has for the parts of the standard.

    logical enough?

  111. 111

    Dean Faulkner

    June 7, 2010 11:22 am

    Do you still drive round in a horse and cart? Or have you not accepted the wheel as a good enough technical enhancement for you to adopt it?

  112. 112

    Interesting debate :P

    I usually have FF/Opera/Safari/Chrome open and I just reload the page in all of them once I’ve finished the changes to the code. I develop sites in localhost, so the pages load up quickly and the extra trouble is minimal (+ I get to watch my beautiful sites more). Almost all the browsers have firebug-like function in them which enables easy debugging.

    But I have to admit that if you don’t do any complex stuff, the sites usually work (they don’t look exactly the same, but hopefully you get my point) the same on every modern browser. At least I haven’t bumbed up into any differences that would make a site unusable in one browser when it works perfectly in another (the fault has usually been in me). The biggest differences come into play with CSS3. Even then I really only use border-radius, box-shadow etc. which only make the site look better; when they aren’t supported the site still functions perfectly (maybe it’s a little uglier, but I give myself the right to blame the visitor with the “bad” browser).

    I absolutely loath IE. More than it deserves. It’s not that bad of a browser, but I can’t stand it. Usually I save it for last and just check that the pages look good. If there is some bad alignment I just let it be. I only work for myself so I can make these kind of “sloppy” decisions :P

  113. 113

    Not really, no.

    You base your argument on an incomplete quote. Ill write shorter sentences if you promise to quote them completely ;P

    “Standards-compliant code build with IE6 in mind is far less bloated than standards-compliant code build for modern browsers, and made to work backwards for IE6+ with exceptions, style sheet overrides or ie7.js.”

    A) compliant HTML that renders fine in IE6 and validates CSS

    B) compliant HTML that renders fine in FF3 and validates CSS + a javascript png-fix + a IE6 and IE7 specific stylesheet with some invalid CSS.

    in bloatness and hackyness.

    I am perfectly aware that IE6 completely missed the boat. I got that point rubbed in when I started developing and IE6 was the newest browser. Then it separated the people who “knew to make images appear on screen with tables and dreamweaver” and the webdevelopers.

    A design should work in IE6. That was the job, and in my opinion still is the job for a front-end developer worth his/her salt. You can complain about your job, but if you don’t do your job, well…

    You don’t solve a problem (crappy IE6) and make kick-ass websites (that work on IE6) by pointing at other problems and whining about them. You dropping support for IE6 won’t change an IT-departments mind. With progressive enhancement they don’t even have to.

    And do they have to? Who says you can somehow force how others view/consume your media. If someone visits on IE6, or Lynx or a screenreader, who am I to say they don’t deserve access to content, structure and design? Even the number of users be damned. I don’t want be responsible as a front-end engineer for a closed door to any visitor.

    My job and ideals are alike but not near:
    “Writing code that is universally and uniformly rendered by all browsers, with the final result depending on the amount of the support the browser has for the parts of the standard.”

    Writing code that is communicating its message to as many users as possible with the richest experience possible, regardless of user agent.

  114. 114

    Yup and I don’t use electricity. I’m the only Amish webdeveloper (XP SP1 IE6 5HorsePower). We tried using wheels, even a steam train, but 15.4% was afraid their heart would stop if we went over 45KM/h.

    Then after aunt Claudette got a stroke after watching an animated .gif, I can now only carve my standard-compliant HTML straight into clay tablets. Progressive enhancement might take a while though, but time doesn’t matter that much here, as opposed to you city people and the resulting accessibility is close to 1.

  115. 115

    Mike Simmonds

    June 7, 2010 11:57 am

    Well said Dean. Bair is from a different era, let him enjoy times gone by. I’m surprised he hasn’t said anything Netscape Navigator…

    At the end of the day, if it brings him in business then good for him.

  116. 116

    Christopher Healey

    June 7, 2010 12:03 pm

    If clients want their site to be ie6 compatible, they pay a lot extra for it. Even Microsoft knows that ie6 is crap, and sent flowers to the “funeral” that was held for it a month or so ago.

    I personally develop in Webkit first, then test in Gecko, then Opera, and then Trident.

    Developing in Trident first just makes me want to bang my head against a wall, long-term it’s much more difficult to maintain if you start out (simply wrong) and then tweak it to “work” in the engines that render code more correctly.

    Reward the users that have upgraded with advanced features, and have a FALLBACK for browsers that don’t support them… any other way is just counter-productive.

  117. 117

    IE6 support should always be considered an extra feature. Backwards compatibility is a good thing, just don’t start backwards!
    Triggering “HasLayout” in IE is a handy way to solve most problems. I use zoom:1 but there are other ways too.

    By coding first in Firefox you ensure that when IE9 is here, your layout will work in it. Why, because Internet Explorer 9 is anticipated to follow standards closer than any other version.

  118. 118


    June 7, 2010 12:07 pm

    Thanks for this article! You’ve provided sound knowledge of cross-browser css coding in a nutshell.

  119. 119

    Support IE6! Drop support of IE8! Take the progressive enhancement route to killing an evil browser!

    And get off my lawn!

  120. 120

    Ben MacGowan

    June 7, 2010 1:15 pm

    If you really think we should be designing for a browser which is over a decade old, then you need your head looking at.

    Yes it may be easier to have a simplistic layout which you can build for IE6, therefore working in more modern browsers. Or you can create a fantastic, visually appealing and highly interactive design (which more and more clients are wanting) – code it in the most up to date browsers and then make sure that it gracefully degrades in IE6.

    I mostly think to myself “Does this design really need a drop shadow PNG on this element? No, but it adds to the effectiveness.” No – so I’ll apply the PNG to browsers which support it, then serve a gif background without drop shadow to IE6.

  121. 121

    Ben MacGowan

    June 7, 2010 1:17 pm

    Well said Andrew.

  122. 122

    I agree completely with the opinion on IE.

    I develop all my sites in webkit (Google Chrome) first, and then get them running in firefox, then Opera.

    Once i finish that, i get it to the point where it at least doesn’t break in IE.

    If you use a shitty browser, you get a shitty experience. Simple as that

  123. 123

    I’d have to agree with the others that starting in IE seems stupid. I just feel like doing that would be way more work in the end.

  124. 124

    I build my site in Firefox because of the great tools they provide, but ALWAYS check it periodically while building it in IE6-IE8. I also check it in Safari and Opera as well.

  125. 125

    Daniel Evans

    June 7, 2010 2:06 pm

    In this day and age we shouldn’t even be having this discussion.

  126. 126

    Count yourselves VERY blessed that you don’t have corporate environment clients who are stuck in IE6 for company reasons.

    I am lucky to have been able to educate my clients that IE6 is like expecting your VHS to play DVD or Blueray quality, and they accept graceful degradation as long as its not at the expense of their commercial value.

    Whereas if you code well and don’t cut corners, you are unlikely to have too many IE6 issues, you should be careful.

  127. 127

    Wait, are you really suggesting that we go backwards and support 3 versions (soon to be 4) of IE? I really hope you’re trolling. If not, here’s a tip:

    7% market share (and I’m sure it’s much smaller on Smashing) isn’t enough to make a developer who values his time want to support it (unless they’re getting paid extra). Are you also mad that Google, Youtube, MobileMe, etc have also dropped support?

  128. 128

    IMO, code with Firefox as it is the easiest to code for (mainly because of Firebug) and if you code properly, you design should render pretty much the same in all modern browsers. Then all you need to do is allow graceful degradation for older browsers and perhaps a few bug fixes. Building for IE6 and then up seems backwards to me. Especially as we should be encouraging web users to update to latest browsers rather than encouraging them to keep their old browsers because we’ll bend over backwards to make our site work the same for IE6 as though it were a modern browser. I believe graceful degradation and obeying web standards is the best way to provide an optimal experience for modern users whilst not completely ignoring the dinosaurs.

  129. 129

    First of all you should never use hacks in CSS. You should always use browser specific style sheets along with conditional statements. Second, properly designed and coded CSS will require little to no alternate style sheets. You are correct in saying that you shouldn’t wait until the QA stage to start testing IE, however I still believe that it is backwards and in my opinion, slower to code for IE first and then incorporate modern browser support. Not to mention trying to develop with Microsoft’s developer tools is highly inefficient in itself and just plain frustrating.

  130. 130

    Start with IE first? HAHAHAHAHAAHA

    Even with the added disclaimer Smashing mag just lost a lot of credibility with me. The author obviously is a newbie who has no clue. You guys must be really struggling to find good authors.

    Pay authors more and you’ll get better quality articles from better authors.

  131. 131

    Everybody is allowed to express their opinion, but I too find starting out with IE6/7 as your development browser to be stupid, dangerous advise which will actually achieve the total opposite of the advantages mentioned in the article:

    “Multiple hacks will be required, needing separate stylesheets for different versions of IE, making the code bloated and less maintainable and making the website slower”

    Well duh. It is a BEST PRACTICE to seperate CSS hacks from your main site. This makes it MORE maintainable, not less.

    “The layout in some spots may have to be reworked, multiplying development time”

    Yes, that is the whole point of cross browser compatibility and why we hate it so much. You will have this either way, no matter which browser you start on. However, when you start with a compliant browser, your design will work in all but one or two browsers. You have a head start.

    “Testing time will increase, sometimes exponentially, leaving less time for more important tasks”

    I don’t see how starting with IE will lead to less testing? You have to test all major browsers anyway. When you start with a compliant browsers, you need to test less. Almost everything you build that works in one compliant browser works in other compliant browsers. That’s why we have web standards.

    Its like building a house from mud and then adding bricks to it at the end. I do agree however to check results in those browsers early on, but dear god, please remove this IE first mentality. I thought we were beyond this point.

  132. 132

    Louis Lazaris

    June 7, 2010 5:45 pm


    Thanks very much for posting this comment, because it says exactly what I wanted to say, but even better. Unfortunately, lots of people who comment on Smashing Magazine don’t actually read the articles, and will often comment based on headings or the title alone.

    Of course, I will admit that I always gear my titles and headings towards controversy intentionally, because I’m trying to grab people’s attention to get them to read. But it tends to have the reverse effect at times.

    Thanks very much for this comment, I hope those who have posted here will read your comment and read the article again, to see that my view is very balanced, and, as you put it, “common sense”.

  133. 133

    Louis Lazaris

    June 7, 2010 5:47 pm

    Peter, this would still be early in development, and would not require that you wait until the end. Maybe it wasn’t that clear in that particular sentence, because I’m speaking as if the “layout” is done. But that’s not what I meant to convey. All I was saying was that the early stages of the layout can be done in IE, and checked in other browsers when convenient.

  134. 134

    Louis Lazaris

    June 7, 2010 5:52 pm

    LOL… thanks for the laugh, Bair.

    In no way was I trolling anyone. I sincerely think that using IE early in development will contribute to a cross-browser experience.

    People need to realize that this article was about “cross-browser CSS”. CSS hacks “after the fact” do not equate to “cross-browser CSS”.

  135. 135

    Louis Lazaris

    June 7, 2010 5:58 pm

    For those who want to read my response to the negative comments about the “IE first” section, please go to this comment.

  136. 136

    Louis Lazaris

    June 7, 2010 6:25 pm


    I take all the blame for any incorrect statements made, or bad advice given in the article. Smashing Magazine made their position clear with their addition to that section. This issue is a matter of opinion, and I can tell you from many of years of experience, that (in my opinion) it’s not difficult to get a layout to work in IE6/7 using clean, standards-compliant code with a few hacks where necessary.

    If you do it the other way around (and only check IE6/7 at the end), you will end up using way too many hacks for problems that aren’t necessarily the fault of IE.

    As a side point to all of this, it is actually not difficult at all to get IE7 to behave with good code, so really the only problem exists with IE6. If you can limit your conditionals and hacks to IE6 alone, you’ll have code that is much cleaner and more maintainable.

  137. 137

    Louis Lazaris

    June 7, 2010 6:28 pm

    It’s not true that you should never use hacks.

    If you require only a few lines of code to get IE6 to work, then you should put it in the main stylesheet using the star-html hack. There is no point adding an extra HTTP request for a single line of CSS, or for only a few lines of CSS.

  138. 138

    IE6 Is almost 10 years old which is a millennia in terms of computing and the only reason a web person would be using it is for testing. I see no reason for SM to support IE6 when such a tiny percentage of us reading this article would actually use it.

  139. 139

    Louis Lazaris

    June 7, 2010 6:40 pm

    This is one of the many comments that has misrepresented what I’ve said in the article. In no way did I say or imply that we should develop with non-standard methods to get IE6 to work.

    IE6 is perfectly capable of handling most standards-compliant code, and with a few small hacks, can get almost any layout to look pretty good.

    That being said, as I mentioned in the article, if your client-base is IE6-heavy, then it may be necessary in a few small cases to do something non-standard. Perfect code is not necessarily the desired end result; Increased website conversions is. If your users are on IE6, and it takes non-standard code to get them to buy your product, then by all means, do it.

  140. 140

    Louis Lazaris

    June 7, 2010 6:42 pm

    It’s just easier to do it that way. I was using arrows in the examples, so that would have taken much more code to get it to look right. It was the principles that mattered for this article, not the actual CSS.

  141. 141

    It’s amazing to see people talking about how many browser a developer “have to” support. I believe that in most cases, some developers let your personal side speak up over their client needs. I am not talking about which browser is better, I am talking about real world websites for real clients. In my hyper tiny small company, we decide which browsers will be supported studying our client target market and of course asking directly for the client. So, if a visitor access my client website`s with a browser that wasn’t planned to be supported, the visitor will receive a polite warning. By default, we support Chrome, FF 3x and IE 7,8. A sorry guy, but Opera with a market share of less 3%, doesn’t worth the effort, unless it’s important for the client.
    It’s important to make your decisions logically and not emotionally. Since our clients are small and medium sizes companies, time is crucial factor to us. We have to be fast. But in the end, this is only my humble option based in my day by day working life.


  142. 142

    You are obviously not a web designer. Developers tend to think a certain way but if you had the mind of a web designer, you’d understand you’re completely wrong.

    So sad that they even allow people as yourself (with such mentality) to write on here.

  143. 143

    Hastimal Shah

    June 7, 2010 8:39 pm

    I Always build my site in Firefox first
    then i go for checking in IE6/7/8,chrome and opera.
    Firefox provide great tools for web development as addons.
    Thanks for great article and many many things from comments also.
    Once again thanks a lot Louis Lazaris.

  144. 144

    Great article. In practice I prefer an iterative approach, where I check results periodically in all relevant browsers. Starting only with one browser and then adjusting for the others could be problematic because then you have to investigate the cause of the problem. And that could be very time consuming.

    I also use a CSS framework like floatz ( because it encapsulates many of the mentioned principles.

  145. 145

    I do NOT agree with the author to test with IE first. I always stay with standard compliant browsers like FF or Chrome. In the end I fix IE specific problems using conditional comments. IE 6 will die soon (even Microsoft is forcing this now) and you could end up with a lot of refactoring work!

  146. 146

    Smashing Editorial

    June 7, 2010 10:26 pm


    well, that’s unfortunate. You don’t have to agree with everything published on Smashing Magazine. We are a platform for design-related discussions, not a single unified voice. And everybody is entitled to his or her opinion. I am really sorry you feel this way.

  147. 147

    Easiest way to kill IE6 is stop supporting it and I mean completely! Just put a message to the users saying that they should update their browser. It’s all in our hands really..

  148. 148

    I guess it always depends on what business you’re developing for. It would be completely useless if the Smashing Magazine would render correctly in IE6, ’cause its users are mostly webdesigners and -developers who will NOT use IE6 for sure.

    If you’re developing for something like a real estate company whose users will work at financial institutes or banks who often still use IE6 (’cause it’s too expensive to update the browser ;) ) you’re better off testing as early as possible in IE6.

    We all hope IE6 will die soon. But as long as this doesn’t happen, you have to make several websites work in this browser correctly. But as I said, it really depends on the audience.

  149. 149

    Chris Lopez

    June 7, 2010 10:41 pm

    Interesting discussion about cross-browser consistent design. From the overall discussion, i summarize that design should focus on accessibility/navigation for people with different browsers/clients and then on the embellishments for each of those clients. Although a longer process and requiring more effort … this approach ensures consistency for anyone with even a non-confirming client to be able to use the website without any navigational glitches. Some people who like to design for FF and then tweak those for IE — its a good approach … as long as the end objective for universal user accessibility is achieved i.e. anyone can access the site content easily.

  150. 150

    Sam Granger

    June 7, 2010 11:33 pm

    input::-moz-focus-inner {
    border: 0;
    padding: 0;

    ^^ The above is a reset snippet for Firefox input fields, especially handy for trying to vertically align/line-height text in an input button for instance. Shame and frustrating that they have this turned on automatically but every browser has its quirks.

  151. 151

    Harry is correct with the iterative approach, you learn more, create better code and estimate your time accurately. Assuming you code in a team you also don’t leave the IE6 job to some other poor developer to clean up in the small hours of the morning before go live !! It’s irresponsible coding practice to leave it till last minute.

  152. 152

    I checked my website Analytics and only 6% of the visitor using IE, and from that 26% use IE6. I stopped supporting IE6, and never look back (not even try to look at the browser check/capture services).

  153. 153

    Michael Pekarek

    June 8, 2010 12:31 am

    I have to say that spending to much (or more than 30 minutes) on IE6 support is imho counter-productive. I mean, that browser shouldn’t even be alive anymore. The company I’m currently working for doesn’t develop for IE6. It’s such a relief… I’m also glad to see that more and more freelancers / companies stop supporting it. Makes us one step closer to forgetting IE6 forever. (Yay!!!!)

  154. 154

    Good article and great collection of thoughts about cross browser development!

  155. 155

    Stefan, are you suggesting that we tell all our corporate clients to ignore 10% of their web users on the basis that it would make some user interface developers life a bit easier. In the greater scheme of things, your time is cheap so lets be honest, it’s not really in our hands…

  156. 156

    So why don’t you all forget the stupid time-eating div boxes and use simple tables without any browser problem?

  157. 157

    7% could easily be millions of users on a high profile website , and you can’t only say “update your browser” .
    Especially when most of IE6 users are corporate fellas that cannot update the browser.
    Google did it, though. So in a way it really depends on designer here, but i’m not really keen to let people with old browsers down

  158. 158

    progressive enhancement… thats the only way!

  159. 159

    dude that marketing tip of engaging users by giving strong opinions is really working

  160. 160

    hi metal-gear-solid m agree with you…thats right..(jeetendra)

  161. 161

    I code in chrome. Used to code in Opera, before that in Firefox.
    If you mark it up good, style it up good afterwards you’ll have way less problems.

    No problem.

  162. 162

    Maybe it’s was right with the development in IE first. But it’s depends on where we gonna deploy our site. Like he said that in most corporate users that primarily use the IE as their browser. An intranet web application in a company would work well with this approach. But it could be very different when we create a website for consumed by public. This approach may become not effective. And what others said to develop in other browsers first (FF, safari, Chrome, etc) would be correct as well.

  163. 163

    Louis, apart from the IE debate, your article also failed to mention anything regarding a DOCTYPE and how Quirks mode affects the box model. Was there a reason you didn’t mention it, or was it just an oversight? I think when you’re talking about cross browser CSS and you start talking about the box model, the first thing you should mention is the importance of making sure the browser is not in Quirks mode.

  164. 164

    I was going to write:
    1. Start for FF/Chrome etc as one solution will normally work in all of them (and hopefully IE8 too).
    2. Make compatible for IE6 and IE7 using as few conditional tags as possible. (Not possible to use these if you start the other way round.)

    But it seems that everyone else has had the same idea.

    I’m pleased you the editorial at least states that Smashing Magazine disagrees with the author, but should you be publishing bad advice?

  165. 165

    Well said! Some of the comments here are uncalled for just plain arrogant. Please people, its a point of view, and from a great free resource.

    That said.. i personally do test early on in the development with ie6.. I find it easier and quicker to fix the issues as i go, ( code for standards early, see how IE stuffs them up, and gain a better understanding) as opposed to trying to figure out what went wrong at the end stages.

  166. 166

    Unless it’s company policy to support until it becomes 5%

  167. 167

    Totally agree with the majority of comments here. It just makes sense to code properly then add any fixes that are needed once complete. FF is my browser of choice, the others are only useful for testing in my opinion.

    Over time you pick up the ongoing niggles of IE etc. anyway, and apply them as you code. It’s very rare I have to make any changes for any browsers once finished. But it has taken me over 8 years to get to that point lol…

  168. 168


    I start out by building all of my sites in Firefox but I make sure to check in IE6 as I go along. However there are those who develop that won’t check frequently in IE6. Four weeks down the line, you have a complete mess and you have to effectively ‘re-create’ the correct look for that browser too.

    I can actually see where you are coming from and I think your approach deserves an attempt to see this could potentially stop this from happening.

    Great article, a very interesting one also! Keep up the great work.


  169. 169

    David Hucklesby

    June 8, 2010 6:37 am

    On the subject of resets, I am wondering if this attitude that “all browsers are different” is a bit out of date? I have been doing some automated testing in as many browsers as I can get hold of, on Windows and Mac, and find *very few* differences–mostly confined to browsers older than IE 6.

    Personally, I do like most browser defaults, and see little reason to make a lot of changes. So, for me, a reset would add a lot of unnecessary bloat.

  170. 170

    I agree with most of the comments above. Chopper made a fine point of it.

    I always start basing XHTML and CSS in Firefox, moving on to Chrome, followed by Safari and then the lesser browsers like IE8, IE7, Opera and Konquerer. As a owner of a business, I’ve decided not to support IE6 anymore. This could cost me money, but save me money in the long run. I’d expect that most developers are often bugged with IE6 problems which take up more time than the client is willing to pay for. After all – you screwed up – the PC always works fine. (in other cases when those people make mistakes, it’s always the computer).

    Well worth the read, even got two useful links out of it! (ST CSS Ref, Google Font API)

    @David Hucklesby; seriously? I love the CSS Reset I am currently using. I rather force style my lists (ul, ol) afterwards. Gives me a lot more control over the typography and ensures me that I myself did the styling, and not the browser. In the end, it won’t look diffirent on browsers like IE. After all – we all strive for symmetry.

  171. 171

    jitendra vyas

    June 8, 2010 7:48 am

    Agree with you after making a base columns structure of layout we should check on IE , if we are providing support for IE.

    We can see if there is any box model, double margin bug etc

  172. 172

    I find a lot of the comments here interesting. While I understand the sentiments about “designing for the standards” and for compliant browsers, most people here aren’t mentioning the most important point:

    You’re not designing for browsers. You’re designing for users.

    The whole reason you’re doing everything is for people to use it. What people are using and how they’re using it is your ultimate master, not a personal ideal or your favorite browser. The random people out there using IE6 are more important than you using the latest version of Firefox and thinking everyone should.

    If you’ll notice, I’m not disputing the technical approaches advanced by most here. Just wanted to include a reminder of why all of us, and the entire Internet, are actually here.

  173. 173

    jitendra vyas

    June 8, 2010 7:51 am

    True in my 6 yrs career no one asked me to make site compatible on Opera. I would like to give my time to test for iPhone/ipad

  174. 174


    Yes, and users want their sites to work in their browser of choice. For long there was hardly any choice, but now there is a lot. If you include mobile platforms, the list is only going to grow. The need for the usage of web standards and for vendors to support them is now more important than ever.

    All of this is in the interest of the end user. Web standards lead to faster sites that are cheaper to build and usable everywhere. If we were to take IE as a standard, we will forever be on an outdated, slow and incorrect platform.

    Do not debunk web standards as merely a personal preference of designers. Web standards are an improvement for the entire web, its designers and its users.

  175. 175

    Great read, many thanks. Will be sending this URL to a few people that is starting off with CSS. At least it will put them on the right path.

  176. 176

    Louis Lazaris

    June 8, 2010 8:27 am


    Yes, that’s a good question, and I believe someone else mentioned that.

    The truth is, there is really nothing all that practical that can be said about the doctype at this point in the web design industry’s history. I don’t think anyone that reads Smashing Magazine develops websites using Quirks Mode, so I really don’t think it’s much of an issue.

    To be honest, it didn’t really cross my mind to mention anything about it, but even now that you mention it, what would I write? All I can write in that regard is “Use a doctype that renders in standards mode”.

    I think it’s safe to assume everyone who reads SM is doing that. I generally cover stuff that’s more practical in my articles, and I think that area has been covered quite well for years now. (Of course, you could say that the “box model” itself has been covered well, too, but I decided to put that in here anyhow.)

  177. 177

    Oleg Puzanov

    June 8, 2010 9:09 am

    Great article, thanks man. Usually, I use Firefox + Chrome to build site and regularly check it under different IE versions. But when it comes to build intranet corporate pages that use MS Sharepoint (different controls based on ActiveX) – IE is the first browser to use.

  178. 178

    I’ll agree with your statement in that if you can use a simple * html workaround for a few IE6 related issues it may be more beneficial than using up an HTTP request, however I think “hacks” should be seen as a last resort as many issues arise from improper coding and can be fixed by simply thinking about how your code is rendered in the browser.

  179. 179

    Oh boy, should I go there? (First of all, I’m on a Mac and usually develop for Safari before testing Firefox & IE via VMware Fusion.)

    Now I’m not saying that IE doesn’t have bugs. But when you’re talking about box model, a lot of the differences in IE 6 and earlier was merely a difference of opinion.

    And frankly, I prefer IE6’s box model when dealing with text. You set the width of the box that holds the text, then you can adjust the padding inside. WIth the standards box model, when you want to add more padding around your text you have to keep changing the width number as well.

    But I know, when dealing with another element like a photo, the width of the photo itself is the hard number and any box numbers outside of that are what have to “grow.” I get it. :p

  180. 180

    Ok, so basically you’re assuming that no one who is just learning CSS is going to read Smashing Magazine. You know what they say about assuming?

  181. 181

    Be sure to tell them how to avoid Quirks mode, as the author apparently did not intend for anyone that is starting off with CSS to read this article (see that conversation above).

  182. 182

    Craig Anthony

    June 8, 2010 1:17 pm

    Personally, I develop in Firefox. Then I return to IE6/7 to correct any issues.

    After coding html / css … I sure do appreciate Flash and AS3. It lets me focus on the design and less on the plumbing. Too bad browsers can’t get their crap together.

  183. 183

    Louis Lazaris

    June 8, 2010 1:38 pm

    Teresa, I have no idea what you’re talking about. If you have a problem with something I’ve said, then please be specific, and avoid useless generalizations that only cause flame wars.

    Thank you.

  184. 184

    Louis Lazaris

    June 8, 2010 1:46 pm

    Peter, this is my opinion as to what’s important to include. If you feel differently, that’s fine. There’s no way I can write an article that pleases everyone, or includes every bit of information that everyone thinks should be in there.

    I’m sorry you think that a discussion of doctypes was pertinent to this issue. The thing is, a doctype is one of those things that doesn’t need to be understood: You just put it in your document, and it works. So, your comment alone was enough to remind people of the doctype, should they read that far. Nothing more is needed (in my opinion).

    If you feel it’s important, then submit an article idea to SM that will cover doctypes in detail. That would be more constructive than calling me names.

  185. 185

    Louis Lazaris

    June 8, 2010 1:52 pm

    Peter, I also didn’t discuss code validation, semantic markup, and other related items.

    The reason I didn’t do that was because I tried to present some fresh and practical tips that haven’t necessarily been covered before in this context, and/or haven’t been covered on SM.

    There’s no reason to mention the doctype. This article doesn’t claim to provide an exhaustive reference in cross-browser CSS.

    Dealing with quirks mode is (in my opinion) an old-school problem that is avoided by pretty much all modern HTML editors that will automatically put in the proper doctype for you. Not to mention that a validator will remind you to use one, as well.

  186. 186

    Guys, the formatting of this page is all messed up. I happened to be developing a site in IE 6 when someone sent me this link, and…..

    Hahha, J/K. This was a great read, both the article and the comments, very educational for this relative n00b. I am small-time, my income doesn’t depend entirely on site development, and thus I have the luxury of telling my clients: “IE6? Too bad.”

  187. 187

    Louis Lazaris

    June 8, 2010 3:28 pm

    Ben, as was mentioned by a few who paid close attention to what I said in the article, my intent here was not for developers to always use IE6/7 to start.

    The article basically said that if your audience has a large percentage of users on IE6/7, use IE first. If not first, then check it early, and fix stuff as soon as possible, rather than waiting until the end where the only way to fix stuff is via hacks and conditionals.

    I specifically mentioned in the article that you shouldn’t use IE first for web apps, personal projects, or other projects where the IE user base is low. So, what this all boils down to is:

    Why is there so much commotion about a point in the article that was qualified with “only-ifs”, and was not really as dogmatic as has been represented here in the comments?

  188. 188

    Louis Lazaris

    June 8, 2010 3:30 pm

    Excellent points, Alejandro. Thanks for adding some constructive advice. I totally agree: Use IE early, especially if the IE user base is high.

  189. 189

    Rahman Kalfane

    June 8, 2010 3:33 pm

    I just think it’s a matter of objective.

    If your objective (or your client wish) is to build a website that look EXACTLY the same in all browsers including IE6 then it makes sense to start with the worst browser.

    If your goal is the build a website or an application with a mininimal compliance with IE6, then you should do that using a good browser and write some clean code.

  190. 190

    maria porto

    June 8, 2010 4:34 pm

    If you do it right, you’re doing it to fit chrome, opera and firefox. Later you work on IE, that’s my opinion, that’s how I get the job donw. Also I always check what is the client browser first. Happened more than once, major clients are still on IE6 and that’s something they can’t change because it usually depends on the tech team and corporate issues. Then you have to think differently and work differently. Unfortunately tweaks and hacks will keep going for a long time. Browsers will always be different as OS and people needs. I agree with Kevin, we are not designing for browsers, we are designing for users. Basicly we must stand for the client target audience not always for the most correct way to do it. That’s what I think.

  191. 191

    Just a question about non ‘IE6 v the world’ related discussion dominating this article.

    The screen grab from the “Use a CSS Reset” section shows all the elements with 0pt. I was always of the opinion and have read multiple times online and in books, that there was no need to use pt/em/px to describe a value as zero. A value of zero is, well zero. No need for pt/em/px.

    Can someone please enlighten me ?

  192. 192

    Smashing, you guys did another bang up job. You found a topic that hits home to nearly everyone in this industry on the design and development side. Which seemed to have brought out a lot of emotion. Thanks for the educational value of this article as well as the entertainment value of reading these comments for the past hour.
    Thank You :)

  193. 193

    Louis Lazaris

    June 8, 2010 6:15 pm

    The web *has* gone nowhere fast — because of IE.

    It’s time we deal with reality and just accept that IE has a large market share, and develop our sites as early as possible in that browser *with standards-compliant code* (where possible). That is a realistic solution to a real problem. The wishful thinking that IE will go away if we ignore it is … well.. wishful thinking.

  194. 194

    jitendra vyas

    June 8, 2010 6:33 pm

    Agree with you. people taking article in a wrong way.

  195. 195

    Nick Krambo

    June 8, 2010 7:43 pm

    Great article. Have to say that I always develop in Firefox and tweak for versions of IE and other buggy browsers. Using a modern browser like Firefox first ensures that your build renders in the other major players the same, then I usually hack for IE versions 6 and up, pffft what a pain.

  196. 196

    Louis Lazaris

    June 8, 2010 8:38 pm


    It is not “best practice” to separate hacks from your main site; it’s “best practice” to not use any hacks, nor conditionals, if possible. The only way that is possible is if you start with IE. I’ve coded many sites that have zero hacks/conditionals for IE7 and only a few for IE6. All those were the ones I started in IE6/7. The sites I started coding in FF or Chrome always end up with IE6 and IE7 hacks/conditionals, which make the site slower, and the code less maintainable.

    Also, the “IE first mentality” was not “exclusively first”, but early development, as you mentioned. People are getting upset here over nothing. Read that section carefully, please, and you’ll see that I make no definite statements, but only offer the advice as a possibility under special circumstances.

    It’s a shame that many like Ben MacGowan and others on here have largely misrepresented what I’ve said, and have instigated quite a furor over nothing.

  197. 197

    Great article, but I do not agree on starting with Internet Explorer first (or not at all)..
    In my opinion you should just start coding a semantic and standards-complient website, and at the end make it compatible for IE through conditional comments.

  198. 198

    @Louis, thanks for another great article. Very useful tips.

    I am shocked to see negative mindset of the community here, which seems to be focused on spinning things in totally wrong direction.

    I agree with your advise regarding use of IE as development / test browser because: If you succeed in achieving your objectives with a cross-browser subset (supported by least compliant web browsers) of standard CSS your code will work every where.

    @Vitaly, with all due respect – I am really sorry to see the disclaimer by Smashing Magazine regarding IE usage advice. You should have a general disclaimer – but not in between the articles unless you are sure that author is misleading your users. Although, what Louis suggested here is not new and practiced by a large number of experienced developers; your disclaimer may discourage other authors to propose new or unique ideas.

    If at first the idea is not absurd, then there is no hope for it.”- Albert Einstein

  199. 199

    Ivan Pierre

    June 9, 2010 2:28 am

    The best way in this case is having multiple wears. Anyway you have to if you’ve got some AJAX and no Javascript.

    One normal, following standard theme, with gracefull falling support for evolution of the CSS implementations.

    One oldtimed written, for Lynx and other IE users. Anyway you can make nice UI too with that, and they won’t be disapointed as they probably already use in their corporate COBOL programs in a DOS window. They still exist too and have to be respected too, but we will not write exclusive DOS program for them (except if they overwhelmingly pay for that).

  200. 200

    Recep Kütük

    June 9, 2010 3:26 am

    Well, this post seems like a good opportunity to ask a question that has been in my mind for a long time.

    I take advantage of conditional comments for more than simple hacks. Here is what I do:

    (I forgot SM does not let us paste html codes here, so I took a screenshot of what I mentioned)

    style.css is the file that honours standards and all browsers except (any version of) explorer will use. I also go crazy with all the css3 goodness I can get. Then for the explorer:

    Then I save this standards-compliant css file and rename it as ie8.css first. I tweak the file for explorer (get rid of border-radius, multiple backgrounds, etc.) Then I rename ie8.css as ie7.css and tweak again and finally the same thing for ie6. When it comes down to ie6, I forget everything about standards and do anything necessary (say hacks) to make it look ok.

    This approach gives me a lot flexibility. I benefit css3 where applicable, I benefit png’s with alpha channel and I don’t have to worry about what the “hack” I will do with ie6.

    Everything is perfect and this approach works like a charm until this point. However, the question in my mind is: even though I use conditional comments, am I causing all browsers to HTTP request all of the 4 different css files? Does this approach cause performance issues? Because, if not, this solves all my problems and I can advice everyone :)

  201. 201

    Maybe, if you know CSS and HTML really well, and understand the limitation of IE6 & 7, and why your code works or doesn’t in those browsers, then you might start with IE6… but then, if you do you won’t be needing this article. If you did understand it well, you’d probably skip straight to a browser that supports the development process, because its quicker, simpler and easier.

    But given that any developer who might benefit from this article doesn’t have that skill, they would be better off building for a standards compliant platform THEN using conditionals to target the only browsers that support (and need) them

  202. 202

    Mart Gordon

    June 9, 2010 5:35 am

    I strongly disagree with frietkot about starting with the bad and making it good. Every developer should start with standards compliance and a correct DTD regardless of rendering in different browsers. The first priority should be a semantically correct document that reads well as an HTML document in as concise a way as possible. I suggest writing the HTML first without any CSS and trying to utilise the existing code to hang the CSS off of. This will help you to truly separate content from style as you will use less extraneous markup.

  203. 203

    Louis, I apologize for any name calling.

    I do feel that your article should have at the very least mentioned that the box model would be different when in quirks mode. In an ideal world, no developers would be developing pages that put the browser in Quirks mode, but that’s just not the case. I don’t think you needed to have a full discussion of doctypes, but a simple mention would have been sufficient.

  204. 204

    ehh… basics… ;/

  205. 205

    Louis Lazaris

    June 9, 2010 9:29 am

    You’re right. Tell you what — later today I will add a point about that in the box model section, in the bulleted list.

    Thanks, and no hard feelings, I realize people are passionate about what they believe, so I’m not holding any grudges for things said here.

    Not to mention that (I think) you’re a fellow Greek, so shouldn’t we make sure we get along? :)

  206. 206

    jitendra vyas

    June 9, 2010 6:05 pm

    @Saud – Agree with you. It’s superb article. People over reacting here.

  207. 207

    The article was really great. and I also don’t prefer I-E (any version) to test the site. I prefer Mozilla and chrome to test sites Design. I dont know why internet explorer team is not modifiying the ie to support all features of CSS3…………..

  208. 208

    Ivor Padilla

    June 9, 2010 11:47 pm

    “Do not see the messenger, see the message”

    Althought I dissagree with Louis about starting with Internet Explorer (I use mainly Firefox to start) his information is not innacurate, he covers the very basic principles and the easy way to Cross-Browse your web designs.

  209. 209

    sorry to say but i prefer to build sites in FF first, and then go through other browsers. If css is correct for 100% than i dont think there would be any alignment problems, regarding the problems of only rendering.

  210. 210

    There’s only one way:
    Doing it the right way first (using Firefox and Firebug) and fixing IE problems after. If you know what IE is able to render, you avoid using this kind of CSS anyway. I normally use two conditional comments for IE7 and IE8 css files and around 10-15 lines of CSS for them. I quitted supporting IE6 some month ago. My clients are ok with that…

  211. 211

    Blair… all I can say you are probably a very gentle and very patience person (for being nice to IE6), and I think you should rewrite this article that because you make better points than the author. Whether I use the practice or not is another story, but “progressive enhancement” is something that should be pointed out and a great discussion topic. Not because your client uses IE6, start with IE… I’m gonna go find a puppy to play with now…

  212. 212


  213. 213

    I always start in Firefox, which usually always means Safari and Chrome will render beautifully.

    IE just needs to go away. Period.

  214. 214

    Firefox with Firebug really save my lot of time & also give me time for experiment at the test time. I always used Firefox first & after 10% of code I have checked in IE.

    Remove unused reset property save render time.

    I have question about how to write CSS property, whether write one after other in one line OR write every property on new line.

  215. 215

    Some paragraphs are controversial.

    I never code for IE first. It’s much easier to code for good browsers first, and write hacks in separate stylesheet for IE6 and IE7 (2 different css’).

    but generally for CSS (especially early in development) you won’t need Firebug.

    It’s much easier and faster to write right styles with Firebug and Pixel Perfect, you can adjust margin/paddings and width/height, and then copy-paste to code editor.

  216. 216

    how about IE??

  217. 217

    I also don’t understand all the comotion, IE6 is still widely used so we sometimes have to design for it, unfortunately.

    I always test against IE6 very early in the development since I once made a nice and standard based (but complex) layout which was impossible to recreate in IE6. It made use of css-positioning using declarations for top, left, right and bottom simultaneously. Providing top, left, right and bottom (the 4 simultaneously) for one element doesn’t work in IE6. I had to start all over again.

    So I check very often in IE6, even when the implementation of the design is not finished. I could think of some situations where developing in IE6 would be reasonable although I sure would miss firebug.

  218. 218

    Nice one i really like this.

  219. 219


    June 14, 2010 3:03 am

    if i get this similar problem, what will be the solution?

    any one can help me out in this!

  220. 220

    First of all, IE6 is 10 years old and if you’re stuck using it because of an I.T. department that doesn’t or can’t upgrade the network, it sucks to be you. Sorry, but you probably shouldn’t be browsing the internets at work anyway.

    Second, starting development with IE is just a dumb, dumb idea.

    It’s time to move on and stop supporting something that is holding back progress and has been for years.

    If I could get away with just not supporting IE at all, I would.

  221. 221

    Darren Williams

    June 15, 2010 4:18 am

    Another example of Smashing Magazine publishing utter nonsense… down the hill we go!

  222. 222
  223. 223

    I skimmed this article when it first came out and thought nothing of it. It was a good review for me. However, when reading Louis’s article on impressivewebs, Coding in IE6, the first paragraph references this article so I popped back over hear and gave it a more thorough read, then I dug into the comments.

    You are entitled to share your techniques ON A SITE THAT IS/WAS BUILT ON SHARING TECHNIQUES! People suck, their all happy to read every other article and skim all the information from them they can and put it to use, but as soon as they hear something they do not like… WHOA!!! Look out!! LOL.. Everyone is entitled to their opinions..

    I do develop for FF/Safari/Chrome first and have for years, but today, I think I’ll try it your way. I mean heck, if I don’t like it what’s lost but a few hours. If it works better, whats gained, a new technique & the possibility of dev’ing faster.

    Louis, dude, your a great writer and I hope the heck SM keeps having you write. you are entitled to develop how you wish. I appreciate the time that you took to write this article.

  224. 224

    I almost finished a project developed with modern standards and tested in firefox. When i saw the site in IE7 6 5, the results were surprising including disappearing content, float’s really floating around the screen, layout breaking etc… It took me some days, after swearing M$ shitty product and marketing policies to realize that the spread of IE6 and 7 can not be controlled and that almost 30% of the visitors would be excluded from the site and that i had to deal with this issue.

    M$ Miracle
    We cannot put the blame on the end users cause we want people to access internet services, despite if they are computer fans. For many people the computer is just a word processor or a means to send email, find information on the web and use online services. They do not have any idea of what is the difference between IE and Firefox (i.e. it does not make any difference for them which browser to use). Computers ARE complex machines. All this is m$’s miracle. (Don’t forget that the most popular OS for PC on the world at this moment is WXP, which even it ServicePack3, the last release of the OS, includes IE6)

    Co-developing with IE
    This means that an accessible site MUST support IE6 support.
    I disagree designing starting from IE6,7 though. Design for today’s standards and support IE with hacks that will stack up as the development continues, in seperate ie-only css leaving the original layout and css clean. But in order to avoid headaches *early and constant* testing (that is mentioned on the article by the way) is a good way of supporting IE. This is an iterative process until the project is finished.

    Hacks are your friend.
    And probably that’s the opinion of IE developers. They implemented conditional comments ( <!– [if lte IE 6] and friends ) because they knew that they violated W3C and other standards by including a lot of proprietary CSS extentions or by *incomplete implementation of the standards*.

    For example layout is the core of every design. When you design the skeleton of a layout (without any particular content, image or color) this is a good moment to verify IE compatibility and start solving issues (with material that is mentioned on the article) with conditional css hacks going from IE7 to IE6, creating on file for each version. Or when you add a new component (like a form) or when modifying layout (padding, margin, border, *float*) go and check what happens with IE and solve. Finally (and hopefully) the hacks will not be a lot.

    Case: Containing floated elements
    I want to close with a topic that worth your attention, and tainted me a lot. It happens when using floating elements inside a container. The container does not by default and in all browsers expands to enclose the floating childs. A correct method for clearing floats, thus making the parent expand should be used. This method should also be browser combatible. One of them is the clearer div method. Note that this could in some cases be source of IE6 bugs. In my opinion easy clearing is the most elegant one. Here you can find more information on the subject:

  225. 225

    I absolutely agree with you

  226. 226

    The percentage of IE users are decreasing day by day. I have my google analytics data to back this statement. My data over a period of 2 years has brought me to this inference.

  227. 227

    Jeremy Carlson

    July 6, 2010 6:12 pm

    LOL….wow, I am LOVING this discussion. While I agree with Bair’s technicality on the border being just as hacky (meaning TECHNICALLY not at all), I can’t agree using something like that only because I would feel…so dirty. I will 100% agree with his point though. How about we just display inline the stupid div and the double margin goes away? Then you can margin and pad the crap out of it all you want.

  228. 228

    Jeremy Carlson

    July 6, 2010 6:20 pm

    “Developers tend to think a certain way but if you had the mind of a web designer, you’d understand you’re completely wrong.”

    What in the hell does that even mean? Are you damaged? What way do we think exactly??

    I might not agree with the author, but at least back up whatever it is you are saying. Bair, above ,actually makes comments that made me think about this. I’m glad for the article just for the discussion that followed. So right on Louis.

  229. 229

    its a nice tips to understand the browser problems. so please update more topics on this issues. thank u.

  230. 230

    It’s always good to refresh yourself on little things like the box model. The Sitepoint reference and CSS reset were great tools, thanks!

  231. 231

    Vibe Tutorials

    July 21, 2010 11:14 am

    I gotta say that this is really good

  232. 232

    I find the best way is to develop in Firefox, yet, regularly test any major design stages in IE6. Although, this is for commercial projects mostly, as for personal projects like my portfolio i often leave out IE altogether.

  233. 233

    I totally agree even big companies are using IE-6 these days.. don’t know why but sometime i feel like to Kill IE-6 lol

  234. 234


    August 8, 2010 5:55 am

    I’m prefer to use Chrome | Chromium for take a look the result.
    So I must learn more about cross-browser coding.

  235. 235

    Jasper Van Proeyen

    August 25, 2010 4:51 am

    *more applause*

  236. 236

    It takes a lot of coding time and patience to deal with the many layout problems of the current Microsoft based IE6-IE8 rendering engines. Firefox has become the web designer / engineer’s main tool and design template; – along with the merging CSS3 practices. The are so many ‘abortion practices’ and common CSS methods (and 1,000’s of hacks) to PATCH ‘known’ problems presented with IE6-IE8. One helpful addition is the use of the [] Progressive Internet Explorer at; []

    PIE makes Internet Explorer 6-8 capable of rendering several of the most useful CSS3 decoration features. I use this VML to gain back some of the ‘lost’ css3 enhancements (radius corners and shadows).

    For now ‘IE hacks’ and the bloat of conditional practices for supporting IE is based on 10 years of designers merging the missing standards! Some IE degrading of support in CSS is likely to be ‘acceptable’ by most professionals.

    IE9 ‘may’ be the first Microsoft rendering engine to place the Windows Public where we designers wanted to be 6-8 years ago. ‘Patience Mr. Microsoft’ – we do have – years of it!

    Thankfully, for most designers (sigh) supporting the MS release of IE6 is not so important (@ year 2010). This IE6 died along with Windows 98, ME, 2000 and early versions of XP!

    Current users of Windows XP are 90% likely to be using at least XP Service Pack 2 (with inclusive support for IE7).

    Firefox is one of the few easy to get design / test / debug tools that allows us to create and test common standards. Additionally, Firefox is supported by Linux, MAC OS X, and Windows.

    Soon IE7 will be ‘dead’, then next IE8 = Hooray!

  237. 237

    “””Current users of Windows XP are 90% likely to be using at least XP Service Pack 2 (with inclusive support for IE7).””””

    Unfortunately not exactly..
    Abstract from WXPSP3 release notes:

    “””Microsoft is not adding significant functionality from newer versions of Windows, such as Windows Vista, to
    Windows XP through XP SP3.

    For instance, Windows XP SP3 does not include Windows Internet Explorer 7,
    although Windows XP SP3 does include updates to both Internet Explorer 6 and Internet Explorer 7, and it will update whichever version is installed on the computer. For more information about Internet Explorer 7,

  238. 238

    yui tools are really useful
    *Start with IE/Firefox depends on kind of project if the project is targeted at global audience i think start with Firefox first but as mentioned above if it is targeted certain client who uses IE then Starting with IE will be the way to go.
    Using stuffs like
    IE8.js –
    YUI Grids, YUI Reset solves major problems

  239. 239

    hi all, I’m from Kazakhstan. Only start in the web developinge, with English is not very prevozhu via Google transleyt just amazed how many very best articles produced on this blog, and more books, advise me how to make your theme for WordPress, thanks in advance

  240. 240

    “If a block element contains floated children, it will “collapse””

    it seems that using the br clear:both fix does not clear tables after floated elements (tables inside a div, which supposedly was cleared by br clear:both).

    any ideas?

  241. 241

    Terese Christou

    April 26, 2011 12:13 pm

    Watch your thoughts; they become words. Watch your words; they become actions. Watch your actions; they become habits. Watch your habits; they become character. Watch your character; it becomes your destiny.

  242. 242

    Thanks, this has always been mysterious to me and now I know.

  243. 243

    Thanks for the marvelous posting! I definitely enjoyed reading it, you can be a great author.I will make sure to bookmark your blog and will often come back from now on.

  244. 244

    It took me time to view most of the responses, but I must say I enjoy the article. It turned out to be very beneficial to me and I am sure to all the bloggers right here! It’s definitely nice when you’re able to not just be told, but you will also entertained! I’m confident you had felt happiness penning this article.

  245. 245

    i am also same for ben.because, ie is everytime changed the code.but, according to me,firefox is best for compare other browsers.not only that,does have include firebug is very useful(simple handling).

  246. 246

    I have been a loyal reader for sometime now, this will likely be my 1st comment. I thought it was eventually time. Thanks

  247. 247

    I totally agree re Internet Explorer. Unfortunately I spend about 75% of my time agonizing over the problems dumped on me through Microsoft’s patent stupidity. What a tragedy. Over the past 10 years IE has probably cost the global internet industry tens of millions of completely unnecessary hours — or more. I don’t doubt for a second that their programmers are capable of fixing IE’s shortcomings, but of course we all know the motivation. When nature has run its course and Microsoft begins to struggle, it will probably still assert that IE users need a “compatibility mode” to overcome everyone else’s problems.

  248. 248

    kelly johnson

    May 20, 2012 11:40 am

    Recently, I’ve been using Firefox w/SelectorGadget and JQuerify to build the bones all in the browser, then paste into a doc and finish out. It’s a different process but sure speeds things up in the long run.

    To the point of doc types.. I never understood how anyone would ever use anything but a valid doc type to begin with? Even back in 1997 when I started all this, I would have a valid doc type and that alone bypassed quirks mode. Thankfully, I never jumped on the bandwagon for 1.0 strict nor any xhtml unless I specifically had xml in the document, getting picky there, but now I guess everyone is just sticking the HTML5 doc type even if their page isn’t structured as an HTML 5 document… in the end, as many have mentioned, it’s incomplete understanding or bad-copy/pasting that causes most issues…not the technology itself!

  249. 249

    Wow, there is some level of arrogance and plain stubbornness in some of these comments. Let’s first try to keep in mind that the author is HUMAN, not an instructional manual. And that in being human, he is entitled to opinions, as the rest of us readers do. That, however, doesn’t mean we should resort degrading, non-constructive comments simply because we don’t agree. Seriously, fellas, that’s 2nd grade behavior.

    Also, in order to write an effective article on the modern-day internet for a broad audience, it doesn’t make sense to cover every little thing, otherwise we’d get articles looking like scholarly documents. I think the author can afford to assume that readers of this article would have a basis in understanding front-end coding. If not, it’s just a few searches and a couple additional browser tabs away from finding out.

  250. 250

    The only thing missing from these comments is someone mentioning Hitler.

    Loved the article. I was able to understand what the author meant about using IE at the beginning of the process instead of the end and not get in a self-righteous tizzy and call the author names. It’s a nice piece of advice.

    A friend of mine has stopped reading any comments on Teh Internets and I think this proves his point. I think I’m done, too.

  251. 251

    I wanna say that above one is a great effort and I’m very pleased that you did this for all of us.
    Thanx a bundle bro

  252. 252

    It’s sad that this article has to exist, but I’ve been bitten by many bugs listed… I hate IE, thank god the % is dropping rapidly for 7/8…


  253. 253

    Jason Groenewald

    January 31, 2013 2:20 am

    Personally I think IE can go to hell; all of the hours wasted trying to fix mistakes and bugs that Microsoft was too daft to correct themselves. Even IE’s debugging tool is antiquated, clunky and does not afford you the kind of microscopic analyis of page elements the way modern browsers can, making the solving of all these massive IE problems even more tiresome of. A global boycott and ban on all Microsoft products should be put forward. We, as developers and designers, need to say enough with Microsoft’s B-Grade software, we are going to use something from this decade.

  254. 254

    I think explorer is now coming with different issues, all of my progaming i first test it in mozilla. My website came out really good when i tested in Mozilla and it showed really bad in Explorer, but now its fixed andit looks really good. It’s Called distance calling

  255. 255

    Nachiket Bhandarkar

    May 24, 2013 7:32 am

    IE is is the most pathetic browser I have experienced coding in until now. The same code works differently in newer versions of IE. Fierfox and Chrome are good to start your work. Agree with Ben.

  256. 256

    Cross browser compatibility is more important when talking about client-side scripting like javascript than css. Few end users will even see the same webpage in different browsers. If they are a FireFox user they will use, you guessed it, FireFox, and so on…

  257. 257

    Dusan Marinkovic

    November 10, 2013 1:53 pm

    Let IE rest in peace already.


↑ Back to top