During the creation of a website — especially if your aim to make its structure responsive — one of the most important and frequent problems that a web designer has to face involves cross-browser compatibility, that is, compatibility across different browsers.
What does “compatibility” stands for? The designer of a website must ensure that their design works properly and that its appearance is error-free and functional on any platform used to view it. It ‘s definitely one of the most complicated and frustrating aspects you must consider when designing a new project, but it’s essential that the you do not leave anything to chance and keep cross-browser compatibility in mind throughout the design process.
Many of the new CSS capabilities introduced in the new CSS3 version are still not widely supported by all major browsers. In fact, some are not recognized and therefore ignored completely, which can pose major problems if your design relied on unsupported CSS. It’s not just a variety of browser types either; different versions of the same browser can support (or fail to support) various design techniques, which complicates cross-browser compatibility even further.
Let’s get back to image management, which probably is the weak point of the RWD approach, especially for browser compatibility issues. Photos and media need to be flexible and adapt to different devices, and at the same time, it’s crucial that they don’t slow down page loading in the process. Therefore, there is still no definitive, ideal solution to problems such as different screen sizes, restricted bandwidth (in cases of mobile browsing), performance on high-resolution (“retina”) displays, and so on.
It is clear that using a single image (the largest possible version) for all devices is not an advisable solution. Think about the time a poor smartphone-2G user would take to load your design. After your ultra-slow image loads, those high-resolution images will probably display at about one quarter of their original size.
The first solution is also the simplest one — I’m talking about a script called respond.js, which enables the older browser versions to understand and execute CSS3 media queries. Here’s all it takes to get started.
This script is called on the page (as shown above) and adds support to media queries, min-width, max-width, and all media types (e.g. screen) for older browsers. This script can help your CSS3 instructions work properly, even for older browsers.
Respond.js may seem like it’s too easy to be an ideal solution, but for many projects this is an great solution because the code is read from the latest CSS3 PC browser and all browser designed for smartphones. The sole purpose of the script is to make older browsers read the CSS3 instructions within media queries. Nothing more, nothing less.
Modernizr supports these browsers: IE6+, Firefox 3.5+, Opera 9.6+, Safari 2+, Chrome, Mobile Safari, Android WebKit browser, Opera Mobile, and Firefox Mobile.
You can download the full version of the library and implement it according to your specifications. However, if you only needs to test the compatibility of CSS3 in your browser, you can set the various options offered by the library and create your own compressed code. Paste the code into an external .js file and include it at the tag of your HTML document. The Modernizr team recommend to include the library just after importing CSS.
You should have this code:
You should see something like this:
<html class="js flexbox canvas canvastext webgl no-touch geolocation postmessage websqldatabase no-indexeddb hashchange history draganddrop websockets rgba hsla multiplebgs backgroundsize borderimage no-borderradius boxshadow textshadow opacity cssanimations csscolumns cssgradients cssreflections csstransforms csstransforms3d csstransitions fontface generatedcontent video audio no-localstorage no-sessionstorage webworkers applicationcache svg inlinesvg smil svgclippaths"> .... </html>
The third solution that we consider is very different from the previous two, especially because it does not make use of CSS3 and accordingly of media queries. However, the concept is very similar to the CSS3 media queries.
If we use CSS3 in a single file, this library requires us to separate the code into several CSS files, one for each device type. The library parses the resolution of the device and calls the CSS designed for that specific screen resolution.
We can download the script and see immediately how it works. Activate the library on your page with the following line:
Then, copy the following code:
We see the list of CSS files within the “range,” one for each group of resolutions. Each of these files contains CSS properties related only to a specific device, just as the code enclosed within the CSS media queries.
The common CSS—that is the CSS that should apply to all screen sizes—should be included in a different CSS file, which for convenience we can call master.css and retrieve it before the integration of this library, just like normal CSS file:
<link href="assets/master.css" rel="stylesheet" type="text/css" media="screen" />
Which of the three solutions should we adopt? They are all valid, sensible approaches. If you choose to apply the first solution (respond.js), you’ll have to write and manage a single CSS file, unlike adapt.960.js, which requires multiple CSS files. Finally, if you choose to try Modernizr, you’ll take advantage of new CSS3 capabilities in the browsers that can support them and still have easy and reliable means of controlling the situation for the browsers that cannot.
Remember that there are also web-based services to test a responsive website and simulate resizing of the browser window. Two of these are responsive.is, which is very easy to use, and studiopress.com, which, after entering the web address, makes different views of your website appear side-by-side.
In addition to web-based solutions, there are also applications that can be installed directly on your personal computer. Among them, we find Opera Mobile Emulator, which is available for Mac, Linux, and Windows. After installing and opening the application, you’ll have a list of devices that it can emulate (with the unfortunate exception of Apple devices).
To conclude this article, I’d like to share a very useful online tool to test the compatibility of your live website: crossbrowsertesting.com. You must choose an operating system and a web browser, and that’s all. A series of well-organized screenshots on multiple browsers will allow you to have a complete view of your site, and in this way, it will be easier to understand on which elements you should modify to make your project perfectly compatible with any platform.
TEN TIPS FOR BUILDING CROSS BROWSER WEBSITES
In theory, building a Web page is simple: Throw together some HTML, test it in your browser, and upload. HTML and CSS are standards, so a page tested in one browser should look the same in all other browsers.
In practice, of course, things aren’t that simple. Different browsers display HTML and CSS in subtly different ways, while some browsers (we won’t name names) veer wildly from the standards.
It’s best to build your Web pages so that they look consistent across a range of browsers. This is often known as cross-browser (or multi-browser) coding.
While there’s no “magic bullet” that will make a site look great on all browsers, there are a number of things you can do to improve your chances. Here are ten useful tips for cross-browser coding.
1. Keep it simple
The more complex your markup and CSS, the more there is to go wrong. Keep your layout simple at the design stage: a header, a couple of side-by-side columns, and a footer. If your design has 7 free-floating sidebar boxes then you’re creating headaches for yourself down the line.
Don’t use too many nested elements in your markup, and use the right element for the job. Use
li elements to create a menu; don’t use a table or a series of
Place all visual formatting in your CSS. Your HTML should be for content, not style.
2. Validate your code
Run your HTML and CSS through validators before uploading your site. Valid code might not make your page magically work in all browsers, but invalid code can produce all sorts of unpredictable and hard-to-debug problems.
The W3C HTML Validator and CSS Validator are good places to start. You can also use browser plugins, such as the Html Validator Firefox add-on, to check pages automatically while you’re viewing them in the browser.
3. Avoid browser quirks modes
Many browsers feature a “quirks mode” that emulates an older, buggier version of the browser. This allows older Web sites to work with modern browsers without having to recode their pages. However, quirks modes can cause headaches if you’re building a modern, standards-compliant page, because a browser in quirks mode will render your page in its own unique, non-standard way.
Generally speaking, a browser switches to quirks mode if your page doesn’t include a DOCTYPE (document type declaration), so to avoid quirks mode, make sure each page of your site includes a valid DOCTYPE. More details in this Quirks mode Wikipedia article.
4. Use CSS reset rules
Many browser engines have slightly different default values for things like line height and padding around elements. Since these defaults can affect other CSS rules, this can be a real pain. You’ve probably lost count of the number of times you’ve had to add
margin: 0; padding: 0; to a CSS rule to make it consistent across all browsers.
To avoid this hassle for each and every CSS rule you code, you can instead do all this resetting at the start of your CSS file (or in a separate file). Eric Meyer has put together a bunch of CSS rules to do just that. He also lists his reasons for using CSS resets. Once you’ve included these rules at the start of your style sheet, you can be reasonably sure that you’re working from the same start point across all browsers.
5. Develop in Firefox
Most Web coders tend to test their site in one browser as they develop the site, then test in other popular browsers (and tweak as necessary) towards the end of the job. This is a good approach, because it’s quicker to test in one browser as you go than five.
Personally I’d recommend testing in Firefox as you build your site, then when you’re happy with it, testing the site in other browsers — particularly Internet Explorer — to fix any compatibility issues. Firefox is very developer-friendly (thanks to its large range of add-ons) and is fairly standards-compliant. If your site looks good in Firefox then it’ll probably look pretty much the same in Opera and Safari.
No doubt your Firefox-tested site will have a few issues in IE, but in my experience it’s better to write standards-compliant HTML and CSS that works in Firefox, then tweak for IE later. If you develop your site using IE then you’ll end up coding for all of IE’s little foibles, which will mean a lot more work later when it comes to tweaking your site for other browsers.
6. Test in as many browsers as possible
Since pretty much all modern browsers have their little rendering quirks, it’s important to test your creations across a wide range of browsers. Here’s a suggested minimum at the time of writing:
- Internet Explorer 6, 7 and 8
- Firefox 3
- Safari 3
- Opera 9
Testing in all 3 versions of Internet Explorer can be a challenge, as only one version of IE can theoretically be installed on one copy of Windows. There are a number of ways round this problem:
- Have 3 PCs for testing. You can then install IE6 on one PC, IE7 on another, and IE8 on the third. Obviously space or money might make this impractical.
- Hack IE6, 7 and 8 to work on one copy of Windows. There are various programs that can help you install multiple versions of IE on one copy of Windows. For example, check out TredoSoft’s Multiple IE and Utilu’s IE Collection. However, doing this can make your Windows setup unstable, and the different versions of IE can behave in strange ways, so this approach is not for the faint-hearted.
- Use virtualization. A nice approach is to use virtualization software such as VMware or VirtualBox to run 3 separate copies of Windows on one PC or Mac. You can then install a different version of IE on each Windows copy. This results in stable, independent versions of IE. The drawbacks are cost (3 Windows licenses needed) and performance (you’ll need a powerful computer to run 3 versions of Windows plus your host operating system).
One way round these drawbacks is to use the snapshots feature of software such as VMware. Install XP with IE6 and take a snapshot; upgrade to IE7, take a snapshot; upgrade to IE8, take a snapshot. Now you can flip between IEs by reverting to your 3 snapshots, all while using one Windows licence.
- Use an online testing service. Sites such as Browsershots and Browsercam let you capture screenshots of your site on a wide variety of browsers and operating systems. The screenshots are then displayed in a Web page for download, or can be emailed to you. Sometimes you have to pay to use these services, and the screenshots can take a while to come through, but it does let you test on practically any browser under the sun without needing to have it running locally.
7. Fix IE issues by using conditional comments
8. Make IE6 work with transparent PNGs
Transparent PNG images are wonderful things — they let you have up to 256 levels of transparency in an image, which means you can do neat tricks like translucency and smooth borders on any type of background. However, Internet Explorer 6 doesn’t properly display transparent PNGs by default, instead displaying ugly boxes where the transparency should be.
The good news is that, with a bit of tweaking, you can get transparent PNGs to work perfectly in IE6, without having to make major changes to your markup or CSS. A good solution is IE PNG Fix from Angus Turnbull.
9. Provide fallbacks
- Images: Make sure that each
imgtag contains an
altattribute describing the image.
- Flash movies: Don’t use Flash for essential stuff like site navigation — or, if you do, provide a non-Flash alternative.
- Images: Make sure that each
10. Code by hand
This last one’s a bit controversial. Many folks these days use WYSIWYG editors like Dreamweaver and KompoZer. Such editors can save a lot of time and are good if you don’t know HTML. However, there’s a bit of an art to creating flexible, elegant, cross-browser HTML, and page editors don’t always do a great job of it.
My personal preference is to code all HTML, XHTML, and CSS by hand. That way I have full control over what I’m creating, and can easily fine-tune the code as necessary to work in a range of browsers.
If you find coding by hand tedious, there are many excellent text-based Web page editors out there to make your life easier. Take a look at CoffeeCup (Windows) or Coda (Mac).