Typically when I construct a website design, I'll focus on one browser (Chrome) and build it out to completion before opening another browser. Once complete, I'll then test it in other browsers while crossing my fingers and hoping that everything looks okay.

I'm aware of the available CSS normalizers that help with consistency across browsers, but I sometimes prefer to abstain from using one to prevent unnecessary bloat.

I only have concern for the latest browsers, and pixel-perfect designs aren't a necessity. What design (both visual and under the hood) considerations should I be aware of to prevent any potential headaches or "CSS hacks" as a result of cross browser compatibility issues?

  • 1
    A good answer to this would hopefully talk about progressive enhancement/graceful degradation.
    – TylerH
    Commented Sep 24, 2014 at 15:22
  • I would think the only answer to this would be to know the capabilities and limitations of each browser, using what you can but having a fallback for what doesn't work cross browser Commented Sep 24, 2014 at 17:11
  • Not enough for a full answer, but caniuse.com is a super-useful tool for checking cross-browser compatibility. Commented Sep 24, 2014 at 20:47
  • Keep in mind, a minified normalize.css is under 2kb, a very small price for the gains. Commented Oct 13, 2014 at 18:03
  • Why was this migrated FROM webdesign? Seems like a much better fit over there than here.
    – DA01
    Commented Oct 13, 2014 at 20:06

3 Answers 3


Considering you are targeting only the latest browsers (at the moment of writing Chrome 37.x, Firefox 32.x, Internet Explorer 11 should cover main latest rendering engines), you can accomplish cross-browser compatibility fairly easily and for most cases - hack free, since all of the mentioned browsers support most of the newest HTML and CSS properties.

A few questions you should ask yourself before starting:

1.) How will I benefit from the time/money spent to make my website look the same cross-browser?

If the many hours you spent optimizing your website and making it look the same in all browsers won't pay themselves back in a reasonable amount of time, it's obvious that you are wasting your time achieving cross-browser compatibility (example: does it make sense/pay off to optimize an intranet website for Chrome/Firefox, if the library you are working for has a 10-year contract with Microsoft to run on their software?).

2.) Is it important for the content of my website to look the same in all browsers (pixel perfect)?

If there is no specific reason that you need a dashed line to look the same in all browsers, you should not bother with it - leave it to the browser to render it by it's rendering rules. It won't look the same in every browser, but no common user will ever go check if your website did render the dashed line the same in Firefox or in IE. Users tend to use one browser to browse the content - as long as all of your website functionality work and look visually appealing you are good to go. Pixel perfect designs are very rarely needed (you may want to achieve them to show-off your skill - specially in personal developer portfolio websites).

3.) Can the functionality of my website work in any browser?

Many of the latest HTML/CSS(/JavaScript) techniques will not work in all browsers, since the latest HTML/CSS specifications are still far from being finished, and browser vendors often decide to include test features without following the specification OR the specification changed, while the vendor still did not release a new version of their browser. If that's the case, you have two options:

  • implement a polyfill that will mimic the desired unsupported feature
  • provide a fallback. Fallbacks usually have limited functionality, but they will provide the minimum support so your website does not fall apart when the feature is not supported (even showing a "Your browser does not support this feature" message is better than showing a blank page).

A few considerations when building your website:

  • Think of your websites as modules. When you complete the design for one module (let's say website navigation), test it in all of the browsers you intend to support at the same time. If you see any problems try to fix them before moving on to the next module - it is easier to debug smaller chunks of code than debugging the completed design and not knowing which part exactly is causing the problem.
  • Keep your code to the minimum. If you only need to show/hide a div, then you don't need to implement a third-party framework to achieve it ("not enough jQuery") - plain JavaScript can do it perfectly.
  • Refactor early and refactor often. You may often realize that you have written too many CSS rules for something that could have been done in a much simpler way. Don't be afraid to refactor your code; it will make your life and the life of the potential developer that is going to work on your code later much, much easier, since there will be less code to read, so less margin for error.
  • Use vendor prefixes. Many of the latest CSS features still require specific browser prefix to run even in the latest version. Provide the vendor-prefixed property names before the regular CSS property name to make it work in the desired browser.

These would be my main considerations to think about before starting the work.

  • Regarding vendor prefixes: Autoprefixer makes thinking about it utterly unnecessary. It automatically checks caniuse.com and prefixes, according to your rules about which browser versions should be supported (e.g. current and 2 versions back) Commented Oct 13, 2014 at 17:59
  • "Making your site look the same across browsers" is not the same as "cross browser compatibility"--which I think you hint at by bullet 3. So that's good.
    – DA01
    Commented Oct 13, 2014 at 20:07

One you need to be aware of is how compatible certain elements of HTML, CSS, etc are with different browsers. Newer HTML5 elements (and even some bits of CSS3) don't work in some browsers, causing issues with areas of the design.

You can check this by looking up many possible references (Mozilla Developer Network, CSStricks, CanIUse , w3schools (see also w3fools)). These generally have a browser compatibility section, which shows which browsers a element will work in, and whether any alternatives or prefixes can be used to aid compatibility - for example:

Example screenshot from MDN

Conditional code can also be used to add things to make it work for a particular browser - e.g. to get versions 8 and less of IE to use HTML5shiv (to get HTML5 elements to work):

<!--[if lt IE 9]>
    <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></sc/>

Though making a thing that will work properly in the first place is good as well.


I only have concern for the latest browsers, and pixel-perfect designs aren't a necessity.

Then you're likely good-to-go. As long as you build to standards, there shouldn't be any huge surprises across browsers if you're only targeting the latest and greatest. Just don't depend entirely on any one CSS feature that isn't widely supported yet without fallback planning.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.