Multi-Browser Viewer Logo

Google's Official FAQ on Cross-Browser Compatibility Republished

clock November 26, 2009 05:17 by author

I recently read this cross-browser compatibility FAQ on Google Chrome again and thought I'd re-publish it, as it may be very helpful to our Multi-Browser Viewer users. The original can be found here: http://code.google.com/p/doctype/wiki/ArticleGoogleChromeCompatFAQ

 

"This document provides a concise list of common compatibility issues with Google Chrome along with their solutions. It's aimed at Web developers trying to fix compatibility issues with Google Chrome or interested in a list of things to avoid when authoring Websites to use in Google Chrome.

 

The list is based on analysis of a large number of real-world sites with compatibility issues. It's important to note that in nearly all cases we've seen, the fixes required to get a Website working well in Google Chrome have been minimal. Developers are often surprised that problems that looked like they could take weeks of developer time were often solved in under an hour and matched closely with the list below.

Each item is described along with its solution, at the end we have a section that lists useful tools and points of reference that you may find useful in diagnosing problems.

 

Preamble - Google Chrome's rendering Engine:

Google Chrome uses WebKit (http://webkit.org/) to draw Web pages. WebKit is a mature (~9 years) open source layout engine used by Apple (Safari, iPhone), Google (Android, Google Chrome), Nokia and many other companies. Google Chrome aims to render sites exactly like Safari. This means that if your site works in Safari there is a large chance it will work in Google Chrome and vice versa.

 

Common Issues:

UserAgent Detection

 

The Symptom

Page not displayed correctly in Google Chrome, or you get a message noting that Google Chrome is not a "supported browser".

 

The problem

By far the most common problem we see is JavaScript (or server-side) code that tries to detect the browser by looking at the navigator.userAgent string. Often the checks used are buggy and do not identify Google Chrome correctly.

Recommendations:

  • On Windows, Google Chrome's useragent string looks something like the following:
  •      Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/2.0.167.0 Safari/525.13

In nearly all cases you don't want to check if you're running under Google Chrome, but if the browser is using the WebKit rendering engine (see above). If you must look at the navigator.userAgent string look for the substring 'AppleWebKit', nothing else is guaranteed to continue working in the future!!

var isWebKit =
  navigator
.userAgent.indexOf("AppleWebKit") > -1;

isWebKit will be true if you're running in Google Chrome, Safari or any other browser using WebKit.

To check the version of WebKit, use:

var WebKitVersion =
  parseFloat
(navigator.userAgent.split("AppleWebKit/")[1]) ||
 
undefined;
if (WebKitVersion && WebKitVersion > 500 ) {
 
// use spiffy WebKit feature here
}

You can find a list of Google Chrome Releases and their corresponding WebKit revisions here.

  • Avoid code like the following:
if (isChrome) {
    doSomethingChromeSpecific
();
} else {
 
// Didn't detect browser type, so assume IE.
  doSomethingIESpecific
();
}

The problem is that the above snippet assumes that any browser not explicitly identified is IE. The problem is that it's far more likely for other browsers to act alike than it is for them to act like IE. Instead make IE the special case. This helps to make your site future proof:

if (isIE) {
   
// Much Safer!
    doSomethingIESpecific
();
} else {
  doSomethingChromeSpecific
();
}

Paragraphs Overflowing/Text Cutoff

 

The Symptom:

A single line header wraps over multiple lines, messing up a site's layout. Text gets cut off or overlaps other elements.

 

The problem:

HTML & CSS can't do pixel perfect layout. So font and element sizes can change slightly between browser versions and OSs. If a site depends on a font being an exact size then text can get cut off or wrap on other browsers or OSs.

Recommendations:

Whever possible, make use of dynamically sized elements rather than specifying fixed pixel widths. This is often easier said than done, but it ensures that content will adapt well to all browsers. Test your site in multiple browsers and OSs, enlarge fixed pixel width elements to accommodate the maximum size you see. Use the white-space:nowrap css attribute to ensure that single line headings don't wrap over multiple lines.

Correct page encoding

 

The Symptom:

Your page looks garbled in Google Chrome. Garbage characters may be displayed, and RTL language pages (e.g. Hebrew or Arabic) may appear with their letters reversed.

 

The problem:

If character encoding is not specified precisely, different browsers can interpret the encoding in different ways or not at all. The impact on users is dire since it prevents them from viewing the site.

Recommendations:

  • Declare your page's content-type correctly, this can either be in an HTTP header or a Meta tag specified in your HTML.
  • The character set your page uses must be a legal value from the Official IANA List, please only use the encodings that have the text (preferred MIME name) listed next to them e.g. ISO-8859-1, Shift_JIS.
  • If you specify two different values for the character encoding in the HTTP Header and the Meta tag, Google Chrome will use the value in the HTTP Header. Conflicting declarations of character encoding in the HTTP Header and Meta tag is asking for trouble. More information on this subject can be found here.
  • We recommend using UTF-8 for all Web content. If you have to use legacy encoding for some reason, make sure to identify the encoding correctly as outlined above. For legacy situations involving Hebrew sites use Logical Hebrew encoding (ISO-8859-8-I). We strongly discourage the use of Visual Hebrew encoding (ISO-8859-8). It has no place on the Web anymore and is a remnant of old systems lacking logic for rendering RTL text. It causes many bugs and lots of confusion.

Correct Plugin Tags

 

The Symptom:

Plug-ins, such as Flash videos, Windows Media Player movies, or Java applets, do not appear in Google Chrome, but do appear in Internet Explorer.

 

The problem:

There are 2 types of plugins on Windows: ActiveX & NPAPI. IE uses ActiveX plugins, all other browsers (including Google Chrome) use NPAPI plugins. ActiveX is Windows-only, plugins on other platforms usually use NPAPI.

Recommendations:

  1. Do not use plug-ins for which only an Active-X version exists, they won't work in Google Chrome, Firefox, Safari, Opera or any browser not using the IE rendering engine.
  2. Be sure that parameters in your <object> and <embed> tags are the same. A common problem is changing the parameter in only one of the tags, for example:
<object ...>
   
<param name="src" value="flash_ad.swf">
   
<embed src="different_file.swf" ...></embed>
</object>

This embeds a flash video. IE will use the parameters in the object tag and thus will load the file flash_ad.swf. All other browsers will use the embed tag and play different_file.swf. Another common error is to specify different values for the transparency attribute when embedding flash.

Inline elements can't enclose block elements

 

The Symptom:

Page styles and layout look do not appear the same across several browsers. Styles are mysteriously not applied to nested elements.

The problem:

HTML defines what are called "block elements" (such as <div>) which represent a "square" on a page and "inline elements" which flow with the page layout (such as <a> and <span>). It is illegal to enclose a block element in an inline element. Different browsers will try to "fix" the markup for you in different ways if you do try to do so. This can cause the page style to be displayed differently between browsers.

Recommendations:

  1. Make sure to properly close inline tags such as <a> and <span>. Forgetting to close a tag can often lead to this situation. There exist a variety of tools you can run, both online and locally to validate your markup and make sure all tags are properly closed.
  2. Here are some examples of bad markup and the correct way to achieve the same effect:

 

 

 

Incorrect Markup Correct Markup
<!-- Illegal for <a> to embed <div> -->
<a>
 
<div>
     some text
 
</div>
</a>

 

<div>
     
<a>some text</a>
</div>

 

<!-- <span> is an inline element and <form> is a block element -->
<span style="visibility:hidden">
   
<form>
        ...
   
</form>
</span>

 

<div style="visibility:hidden">
   
<form>
        ...
   
</form>
</div>

 

Use of Browser-Specific CSS or JavaScript objects

 

The Symptom:

Some CSS styling does not work in Google Chrome, even though they seem fine in IE or Firefox.

The problem:

Each browser has its own private CSS selectors and JavaScript objects. Use of these types of markup is, by definition, not compatible with other browsers. These should only be used for non-critical tasks (e.g. adding text shadows). It is safest not to use them at all.

Recommendations:

Useful Tools

We've found the following tools extremely useful when diagnosing compatibility problems with Websites. Using them can greatly decrease the amount of effort and guesswork that goes into fixing compatibliity issues:

  1. Google Chrome has a variety of built-in tools to help developers track down compatibility and performance issues.
  2. Firebug - An excellent Firefox extension that can help examining markup, JavaScript and performance issues.
  3. Fiddler - A free Windows-only tool that allows you to examine and replay HTTP requests and responses. "

Also For information on development status regarding the Google Chromium project you can also visit the official blog here: http://blog.chromium.org/


Location: PostList


How to Prevent Cross-Browser Compatibility problems

clock October 12, 2009 10:30 by author

Many of the support queries we receive relates to how can you ensure that your web page design is cross browser compatible. In other words instead of going through the entire development process, then testing my design in different browsers, what standard practices should I follow to ensure web site will render correctly once it is completed.

Well, unfortunately there is no foo proof method off course, but here are a few helpful tips/best practices that should get you pretty close at least.

First off - What is a web browser??

Simple question I know, but many people still get confused to exactly what a browser is and how it functions. An Internet browser (IE, Firefox, Safari, Opera and Google Chrome for example) is nothing more than a software application, similar to a text editor, anti-virus software or a computer game. Some of the confusion comes in because IE is embedded or very much part of the Microsoft Operating system(although Microsoft is starting to clearly separate the browser from the OS). A browser is NOT a search engine and it is NOT a website. A web browser renders/displays web pages that you visit/browse. Web browsers use different rendering engines, which means HTML, CSS and other code gets interpreted and thus differently by different web browsers. And that of course where the problem lies for website owners and web designers....Sure there are supposed standards like the W3C and such, which are supposedly followed by everyone, but for various reasons, which fall outside the scope of this article, the problem remains.

Cross-Browser Compatibility Best Practices

1. Know you web user - The first thing you need to do is understand who your customers and/or web browsers will be. In other words if you are developing for a closed environment like an intranet, then maybe 90% of your users will be Internet Explorer based or if it a design firm that only uses Apple Mac machines then maybe all the traffic is exclusively Safari. Bottom line is make sure you know what the most important browser demographic is for your web application. If you have no idea, industry browser usage statistics are available in the blog post here. I would recommend however that you use a tool like Google analytics to determine the usage statistics for your own site, as the numbers can vary substantially from target market to target market.

Why is it important to know what web browsers are most important for you? Well, it helps you ensure that you optimize your design and/or development for that particular browser and if you do have a cross-browser compatibility issue, you'll know exactly how many users are affected by it.

2. Doctype and standards compliance HTML/CSS - The structure of a web page is defined by markup language standards (HTML, XML and XHTML). The DOCTYPE descriptor tells the browser what document type definition to use in validating the structure and how strict to apply validation rules. The doctype tag is the first tag at the top of a HTML page. To ensure your page is cross-browser compatible it recommended to ALWAYS USE STRICT DOCTYPE and code your web page accordingly. This is fairly easy with new pages, but could be a nightmare for pages that have been developed over a long time, which might need to be re-coded or migrated. For more information about doctype's visit w3schools.

3. Avoid resizing images using CSS or HTML Code - we've all done it. An image doesn't fit the way it should, and instead of resizing the image in an image editor, we use the quick and dirty method, setting the width and height in code. Avoid doing so, IE is especially bad at resizing images in code, usually making the image look jagged edged or squashed. If you have to resize using code for whatever reason, try using the -ms-interpolation-mode: bicubic; CSS switch. It supposedly reduces the jaggedness.

4. Use a CSS reset at the start of your CSS - If you site relies heavily on CSS then it is highly recommended to reset/zero value your CSS. Yahoo developer tools have a helpful CSS reset file that you can use as well as some other helpful information. basically the reset file doesn't necessarily ensure browser compatibility, as much as it it ensures that your code renders the way it's supposed to, removing that extra line break or padding that you know you didn't include, but yet is displayed on your page.

5. Resize text as percentage - Size all your document text as a % within the body, and as em’s throughout the HTML page. This also is also good for accessibility as much as for browser cross compatibility. A good article on text sizing is available here.

6. Font rendering - Use -moz-opacity:0.99 on text elements to clean up rendering in Firefox, and text-shadow: #000 0 0 0 in Safari - Safari 3+ has an issue with the way it renders light type on a dark background. Some would argue whether this is good or bad, but there’s a way to make it appear lighter.
Easy fix.

You need to add this to your code.

p {text-shadow: #000 0 0 0;} 
Where #000 is your background color. You will probably have to be more specific with the elements you select.
It is not recommended to use this fix on the body tag.
Other elements you might need to fix are the li, dt, dd, blockquote etc. Use this on any text element you want to appear ‘thinner’

To make this fix in Firefox, you use the opacity fix:

p {-moz-opacity: 0.99;}

You need to be careful with this fix, as it will break any Flash element that it touches in Firefox. There appears to be no workaround for it.

7.  Font Selection - Try use common fonts that you know are available in most opiating systems - For example Lucida have been known to render pretty badly in Internet Explorer, while rendering pretty well in Safari. Rather just avoid it and stick to fonts that are common to all operating systems.

8. Avoid using transparent PNG images - Internet explorer 6 does not support alpha transparency in PNG images. There are a few work arounds, which you can simply Google, most of them have a few side affects. One that I have used before is Twinhelix.

9. All layout divs that are floated should include display:inline and overflow:hidden - When you have a standard layout, with floats sitting next to each other, with set widths, but an image or long string of text is longer than this width, the layout could break in Internet Explorer 6. If you place overflow:hidden; into the layout divs, the layout shouldn't break.

10. Containers or container div's should have overflow:auto or overflow:hidden and trigger hasLayout via a width or height - This is to avoid circumstances where a div container does not wrap around all the containing div's like its supposed to. You can always test it by using a background image on the container.  You’ll also need to make sure hasLayout is triggered in Internet Explorer 6. You can do this by specifying a width or height. If you don’t have a width in your div container, you can use height:1% to trigger it, or zoom:1; if you can’t afford to give it a height.

11. Avoid using the brand new CSS 3 selectors - many of the new CSS 3 selectors aren't supported by Internet Explorer 6.  For a full list of supported selectors, check out evotech.net’s post on browser css selector support.

12. Test, Test and Test - test your site for cross-browser compatibility using the actual browsers and virtual machines or by using software such Multi-Browser Viewer. I would always recommend you test in the actual browsers like Internet explorer, Google Chrome, Firefox and opera when you first launch your site and use a service like Multi-browser Viewer to continually test your site over time for any major problems.

I would like to thanks ADM blog and webappers, which I also used for reference for this blog entry.


Location: PostList


About Multi-Browser Viewer Blog

The Multi-Browser Viewer blog pages feature Cross-Browser compatibility tips, tricks and stats. As well as
Multi-Browser Viewer related FAQ's, Support documentation and release notes.

Please feel free co comment and ask questions.

RecentComments

Comment RSS

Sign in