The utopia for any designer is to have a 100% bug-free site; the reality though is that while this will always be at the back of the developer's mind, it is impossible to achieve!

Why? One key consideration is the use of CSS3 (and those elements of CSS4 that now exist); although support is constantly improving, there is still a way to go before every browser offers consistent support for all CSS3 attributes. In the same vein, support for responsive media and media queries are not supported by older browsers, so we must consider how much support we can afford to offer for these browsers.

Considering possible solutions, we've touched on three elements which are key considerations for responsive sites, to work around them, there are a number of options open to us.

We can (and should) consider constructing our site using the base content that will work on any browser; we can then progressively enhance the experience, by adding extra features that may only work for some browsers, but are not key to the overall user experience. In comparison, we could take the view that we build our site around the latest technologies and browsers, but then add in support to allow content to degrade gracefully, when used on older browsers.

Can we work around these issues? Absolutely, there are a number of different options on offer. There is one point we should consider though, using a JavaScript solution isn't necessarily the best solution; there are a number of tips and tricks we can use to help retain compatibility. Before we touch on these, let's take a moment to consider some of the options available when using JavaScript as a solution:

Although these solutions will work perfectly well, they all suffer from one inherent drawback—JavaScript! In this modern age, most browsers are likely to have this switched on by default, but there will be instances where this is not the case; let's explore why using JavaScript isn't always the right solution.

During the construction phase of any responsive site, we will naturally need to work out which breakpoints we want to support. This will be based on statistics such as Google Analytics. The normal route would then be to use media queries in our CSS style sheet to load elements when needed. This works fine for recent browsers (anything within the last year to eighteen months), but with older browsers this will prove an issue.

We can support them using JavaScript-based solutions:

Clearly these drawbacks make for a less attractive option when using JavaScript! Two key questions we should ask though are: do we really need to support older browsers, such as IE8, and use JavaScript to support them?

The question of which browsers to support is one that will divide both developers and designers; on one hand, we will have creatives that want to take advantage of the latest functionality, while others will state that we must support as wide a browser population as possible.

The latter might normally require the use of JavaScript for older browsers; given that this requires extra resources that we must call from the server, it makes sense to use CSS where possible. To this end, we can consider using the relatively new @supports feature, (or feature queries, to give it its technical name). This works in a similar way to media queries and allows us to style elements based on whether the chosen style is supported in the browser. This has gained great support in most recent browsers (except of course IE, which always likes to be different!):

We can then create code such as this in the main markup:

<article class="artwork"> 
  <img src="myimg.jpg" alt="cityscape"> 
</article> 

And style it using code such as this, when it is supported:

@supports (mix-blend-mode: overlay) { 
  .artwork img { 
    mix-blend-mode: overlay; 
  } 
} 

However if it isn't supported, then we simply add a feature query to allow it to gracefully degrade:

@supports not(mix-blend-mode: overlay) { 
  .artwork img { 
    opacity: 0.5; 
  } 
} 

The beauty of this is that we're not reliant on any external libraries to help support what might be core functionality; we can use this to support new CSS3 styles and existing properties. Granted, it means that our style code base will increase, but this is tempered as the increase is in an existing file that is already cached, than having to call an additional new resource from the server!