Archive for the ‘Cross-browser’ Category

15+ Techniques And Tools For Cross Browser CSS Coding

Making your website compatible with a wide range of browsers is probably the hardest task of a front-end developer. To make your coder life easier, here is 15+ tools and techniques for crossbrowser CSS development.

Part 1 – Techniques

Of course, efficient crossbrowser CSS development starts with techniques and good practices. In the first part of the article, I’ll show you X techniques that will make your crossbrowser development easier.

Reset CSS

Due to the fact web browsers define different default styling for html elements, the first thing to do is to always include a CSS reset in your stylesheet. By using this code, you’re already eliminating lots of future headaches.

html,body,div,ul,ol,li,dl,dt,dd,h1,h2,h3,h4,h5,h6,pre,form,p,blockquote,fieldset,input,hr {margin:0; padding:0;}
h1,h2,h3,h4,h5,h6,pre,code,address,caption,cite,code,em,strong,th {font-size:1em; font-weight:normal; font-style:normal;}
ul,ol {list-style:none;}
fieldset,img,hr {border:none;}
caption,th {text-align:left;}
table {border-collapse:collapse; border-spacing:0;}
td {vertical-align:top;}

Internet Explorer conditionnal comments

Let’s face it: Internet Explorer, especially the dinosaur IE6, is the front-end developer nightmare. In order to minimize their errors, Microsoft implemented conditionnal comments in their browser, which allow you to link a stylesheet that will be interpreted by a browser alone.

<!--[if IE]>
  	<link href="ie.css" rel="stylesheet" type="text/css" />
<![endif]-->

You can also target only a certain version of IE:

<!--[if IE6]>
  	<link href="ie.css" rel="stylesheet" type="text/css" />
<![endif]-->

Internet Explorer hacks

While conditionnal comments are better, you can also target some versions of Internet Explorer using the following syntax:

.class {
  width:200px; /* All browsers */
  *width:250px; /* IE */
  _width:300px; /* IE6 */
  .width:200px; /* IE7 */
}

This technique is not W3C compliant (this is why you should use conditionnal comments instead) but sometimes, it is a real time saver.

Targeting Opera only

Opera isn’t the popular browser, but that isn’t a reason not fix problem that may occur. The code below will only target Opera, allowing you to add CSS rules only for this browser.

@media all and (min-width: 0px){
    .classname {}
}

Targeting Safari only

Safari is one of the most standard-compliants browsers, so it is rare that you have to fix Safari-only problems. But it can happen sometimes. Here is a nice hack to write Safari-only CSS rules.

html:lang(en)>body  .classname {}

Targeting Google Chrome only

After Opera and Safari, here is finally the same kind of hack, to target only Google Chrome:

body:nth-of-type(1) p{
   color: #333333;
}

“Browser Detect” PHP Class

While Internet Explorer is most of the time the reason of crossbrowser compatibility problems, sometimes you may need to detect a wide range of browsers

If you’re working with the PHP language, the Browser Detect class is a very useful tool for detecting more than 20 different browsers.
Get the class

JQuery browser detection

Another great piece of code to detect the most common browsers (Safari, Firefox, Chrome, IE and Opera) is the browserdetect.js Jquery plugin.
Once you inclued JQuery and browserdetect.js in your html file, the script will automatically add a css class to the body tag.
For example, your body tag will look like this if the visitor browser is Firefox 3:

<body>

Get the code

WordPress browser detection

A while ago, I’ve explained on my other blog WpRecipes how WordPress can detect the browser used by your visitors. The code below will automatically add a CSS class to the <body> element of each page of your blog. Simply paste it on the functions.php file of your theme.

add_filter('body_class','browser_body_class');
function browser_body_class($classes) {
	global $is_lynx, $is_gecko, $is_IE, $is_opera, $is_NS4, $is_safari, $is_chrome, $is_iphone;

	if($is_lynx) $classes[] = 'lynx';
	elseif($is_gecko) $classes[] = 'gecko';
	elseif($is_opera) $classes[] = 'opera';
	elseif($is_NS4) $classes[] = 'ns4';
	elseif($is_safari) $classes[] = 'safari';
	elseif($is_chrome) $classes[] = 'chrome';
	elseif($is_IE) $classes[] = 'ie';
	else $classes[] = 'unknown';

	if($is_iphone) $classes[] = 'iphone';
	return $classes;
}

IE6 crash

Sometimes (Who said always?) Internet fucking Explorer 6 gives us, developers, lots of headaches. Although this is definitely not the best method to make your clients happy, it can be really fun to implement on your own website.

You guessed it, the following line of code will make IE6 crash. Goodbye, dinosaur.

<style>*{position:relative}</style><table><input></table>

If you’re interested in more “IE6 killer” techniques, you should definitely have a look on here.

Part 2 – Tools

Techniques are the required knowledges for efficient cross browser development, but tools can make you save time, hasle, and in three words, make your life easier.
In this second part of this article, let’s have a look at the most usefull tools freely available over the Internet.

Xenocode Browsers


This tool is what I’ll definitely call a must-have. Xenocode Browsers allows you to launch a wide variety of Windows browsers (IE 6, 7 and 8, Firefox 2 and 3, Google Chrome and Opera) directly from the Internet. You only have to install a small plugin, and that’s all.
The only weak point of Xenocode Browsers is that the tool can only run on Windows machines (XP with SP2 and later). This is a sad news for mac users like me, but the tool is still very good.
Visit Xenocode Browsers

IE6 CSS Fixer


I know I already said it earlier, but Internet Explorer is the developer’s nightmare. An experimental tool has been created to transform a “normal” css stylsheet into a “IE” stylesheet.
For example, it apply new sizes for your boxes, according to the fact that IE have this well known box model bug.
Visit IE6 CSS Fixer

Browsershots


No one can have something like 3 OS and 25 browsers on his/her office. Personally, I remember when I used to ask my friend running another OS than mine “hey, do that site looks good on your computer?“. This is exactly Browsershots purpose: You select the OS, you select the browser, you wait a bit, and the site show you screenshots of your website under the selected OS and browsers.
While Browsershots is obviously an usefull version, there are a few bad points. The worst of it is the waiting time for being able to see your screenshots, depending on how many browsers you selected.
Note that Browsershots offers a paid version, that I haven’t tried for now, which promise slow waiting times.
Visit Browsershots

Browsrcamp : How your sites looks on a Mac

MultipleIES : Run multiples version of IE on your PC


MultipleIEs is a Windows-only program allowing you to install and run multiples versions of Internet Explorer (from version 3 to version 6) on your computer.
Althought sometimes some render difference between a “real” IE and multipleIE can occur, it is still an useful tool, if for some reason you can’t use Xenocode Browsers.
Download MultipleIE

ie4osx: IE on the Mac


A similar tool to multipleIE is also available for Mac users. Sadly, it runs on X11, it is slow and buggy. But if you don’t have access to a Windows machine, it is still an interesting program to have on your dock.
Download ie4osx

Source: http://www.catswhocode.com


Cross-browser JavaScript

Actually it’s not usually the JavaScript itself that causes the problem (though there are different versions, which we’ll mention later), it’s references within the code to elements and properties of the Document Object Model (DOM) that cause everything to go wrong.

These references come into play when JavaScript is used for DHTML. You’ll find a full explanation of the DOM in our DHTML series. Navigator, particularly version 4, and Explorer build their DOMs in different ways – often totally opposing ways – with Explorer creating a hierarchy from the general down to the specific, and Navigator sometimes working the other way round.

So the properties and attributes of the two different DOMs must be referred to in different ways, otherwise you get a JavaScript error and either the code won’t run or it crashes the browser.

Of the two, Internet Explorer is much closer to the ideal and the natural model of the DOM. The old Netscape model will in time disappear.

There are other complications for fully compatible JavaScript on top of this major battle. There are many different platforms and operating systems. We have PCs, Apples and Unix computers. They run Windows, Linux, Solaris and MacOS operating systems. The browsers may be from Microsoft, Netscape or Opera.

These are only examples, the whole picture is even more complex, especially now we have mobile telephone Internet access, which uses WAP (Wireless Application Protocol).

On top of this, the basic languages are evolving. JavaScript started at version 1.0, and now is at version 1.5. Any application designed to use JavaScript 1.0 generally cannot run JavaScript 1.5. The reverse is generally easier – if an application can use JavaScript 1.5 then it is quite likely that it can use JavaScript 1.0.

The Wars

With IE4, Microsoft trod on a few feet. It added filters, multimedia controls and a fuller implementation of DHTML than its closest competitor, Netscape. Navigator 4 couldn’t interpret these, and Netscape had also developed it’s own version of DHTML, which was significantly different to Microsoft’s.

With IE5, NN4 was left floundering. NN5 was considered too ‘buggy’ to warrant a release, and so now we have NN6. NN6 has implemented a much fuller version of Internet languages, and so cross-browser issues might eventually dwindle to a more acceptable level. Having said that, the beta version of NN6 appears to reject code that was previously considered to be cross-browser, so life remains interesting.

The whole picture is very complicated, and it takes large corporations to be able to provide full Internet access to every platform and browser. But a small business/single user can ‘maximize the odds’ of writing code that works on the maximum number of systems.

Parsing

A classic way to deal with cross-browser issues is to parse the browser version identification (recognize its type) then add conditional statements to the code, so that only code written for that browser will be interpreted and other code will be ignored. Reading the navigator object of the DOM can do this. For example,

<HTML>
<HEAD>
<TITLE>Which Browser</TITLE>
<SCRIPT>
document.write(navigator.appName);
</SCRIPT>
</HEAD>
</HTML>

IE reports Microsoft Internet Explorer, Netscape reports Netscape.

A typical example is for CSS. IE created the style object, of which all elements have their own instance. NN4 allows styles, but treats the style as a property of the element.

e.g. for the code

<P ID=”Pred” STYLE=”color:red”>This is Red</P>

If we wish to display the style of the Pred element:

IE : alert(Pred.style.color);

NN : alert(document.ids[‘Pred’].color);

We can’t write:

<HTML>
<HEAD>
<TITLE>Double alert</TITLE>
<SCRIPT>
function go() {
alert(Pred.style.color);
alert(document.ids[‘Pred’].color);
}
</SCRIPT>
</HEAD>
<BODY onload=”go();”>
<P ID=”Pred” STYLE=”color:red”>This is Red</P>
</BODY>
</HTML>

IE5 displays one alert box, containing red, and then crashes, and NN4 fails to load the page. Disastrous. This is slightly unfair on NN, IE at least gets some valid code before it crashes, whereas NN is expected to understand IE code immediately, and so crashes immediately. Try switching the order of the alerts. Now IE crashes immediately.

Writing Cross-Browser Code

To avoid this, we determine which browser we are running, and then use this information.

We have to adapt the appName code slightly to detect the browser.

<HTML>
<HEAD>
<TITLE>Internal Browser Notification</TITLE>
<SCRIPT>
app=navigator.appName.substring(0,1);
alert(app);
</SCRIPT>
</HEAD>
</HTML>

IE reports M, NN reports N.

We can use this to write responsive code for both browsers.

<HTML>
<HEAD>
<TITLE>Cross Browser alert</TITLE>
<SCRIPT>
M=false;
N=false;
app=navigator.appName.substring(0,1);
if (app==’N’) N=true; else M=true;
function go() {
if (M) alert(Pred.style.color);
if (N) alert(document.ids[‘Pred’].color);
}
</SCRIPT>
</HEAD>
<BODY onload=”go();”>
<P ID=”Pred” STYLE=”color:red”>This is Red</P>
</BODY>
</HTML>

Now the code runs in both browsers.

Note that this line:

if (app==’N’) N=true; else M=true;

implicitly sets IE as a default browser for the code, i.e. there are only two types of browsers, Netscape, and everything else, which we give to Microsoft.

To set Netscape as the default browser use:

if (app==’M’) M=true; else N=true;

Page Selection

Some people prefer the page selection technique when they write cross-browser code. This involves sending the viewer to the page that has been written for their browser. This code can prove easier to debug and maintain.

This technique would use three pages instead of one. The first redirects the viewer to an appropriate page.

<HTML>
<HEAD>
<TITLE>Redirection</TITLE>
<SCRIPT>
app=navigator.appName.substring(0,1);
if (app==’N’) location.href=’redN.htm’;
else location.href=’redM.htm’;
</SCRIPT>
</HEAD>
</HTML>

Then we have two distinct pages for each browser.

redN.htm

<HTML>
<HEAD>
<TITLE>redN</TITLE>
<SCRIPT>
function go() {
alert(document.ids[‘Pred’].color);
}
</SCRIPT>
</HEAD>
<BODY onload=”go();”>
<P ID=”Pred” STYLE=”color:red”>This is Red</P>
</BODY>
</HTML>

redM.htm

<HTML>
<HEAD>
<TITLE>redM</TITLE>
<SCRIPT>
function go() {
alert(Pred.style.color);
}
</SCRIPT>
</HEAD>
<BODY onload=”go();”>
<P ID=”Pred” STYLE=”color:red”>This is Red</P>
</BODY>
</HTML>

This is only the beginning of cross-browser programming. If you consider all browsers and platforms and JavaScript versions, there’s a lot of code to write. We need to know all the variations for each system.

There’s certainly a need for more standardization, to avoid cutting people out of the Internet and to allow further progress to be made in a civilized method. It would be nice if the head honchos of all the relevant companies felt the same way.

Source :  webdevelopersjournal.com

10 Tips for Building Cross-browser Websites

10 useful tips to ensure your Web pages look good across all browsers and attract more visitors.

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 ul andli elements to create a menu; don’t use a table or a series of p elements.
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.

10 useful tips to ensure your Web pages look good across all browsers and attract more visitors.

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 ul andli elements to create a menu; don’t use a table or a series of p elements.

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 Hilbrand Edskes’ Internet Explorer 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 VirtualBoxto 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

Sometimes, no matter how hard you try, it’s impossible to make your otherwise-beautiful site work in Internet Explorer without resorting to some serious CSS and/or JavaScript hacks. However, there is an alternative. By including IE-only markup with conditional comments, you can serve up additional HTML, CSS or JavaScript just to IE, allowing you to work round any issues. Much cleaner than using hacks.

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

While most Web browsers support Flash and JavaScript, and nearly all support images, it’s a good idea to provide fallbacks in case these features aren’t available on a visitor’s browser. For example, I’ve seen many sites with Flash navigation menus that are completely unusable on browsers that don’t support Flash (such as Mobile Safari on iPhone).

  • Images: Make sure that each img tag contains an alt attribute describing the image.
  • Flash movies: Don’t use Flash for essential stuff like site navigation — or, if you do, provide a non-Flash alternative.
  • JavaScript: Again, try to avoid using JavaScript for essential functionality. Using it to make things easier or faster is fine. Use the noscript element to provide a non-JS alternative (or at least to display a message asking the visitor to turn on JavaScript).

10. Code by hand

This last one’s a bit controversial. Many folks these days use WYSIWYG editors like Dreamweaver andKompoZer. 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).

Wrapping up

It’s worth taking a bit of extra time to make your pages work across as many browsers as possible. By doing so, you not only increase your audience reach, but you also keep your visitors happy, which is always good!