Cross Browser Testing---what is it?,Browser compatibility and strategy for cross browser testing

Browser compatibility and strategy for testing:

Different Browser Versions

The major difference between two versions of the same browser is their support for newer portions of the HTML language. A new browser is generally better at displaying Web pages than an old one.However, Internet users tend to upgrade their browser based on the addition of new features, like email integration and instant messaging. If a user doesn't care about these features, they're happy to keep surfing the Web with their old browser.If IE doesn’t quite understand something, like sloppy code or unsupported features, it attempts to do something anyway, instead of simply ignoring them, like Mozilla and Netscape based browsers. Unfortunately, this results in major headaches for CSS developers. Microsoft has attempted to help “dumb down” coding issues, resulting in more developers that write sloppy code, by having the browser anticipate the design. There are obvious problems with this concept. In my humble opinion, CSS code should be written, validated, and 100% compliant with the standards.

A best wayout is to design pages to work for the last two versions of the major browsers.

Also note that new browser versions sometimes represent major changes in a browser, and in these cases all bets on the browser's behavior are off.

For example, Navigator Version 6.1 is a complete rewrite of Netscape's browser, so a page that worked well under Navigator Version 4 may not work under Version 6. That's especially true if you use Dynamic HTML on your pages.

Different Computer Types

The Macintosh is still used by 12% of computer users, and has a very loyal following among graphic designers and publishers. In theory, if you view your page on both a PC and a Mac using the same version of the same browser, it should display the same, right?

In practice that's rarely the case. There are three reasons for this:

Font Availability. When you tell your Web page to use a particular typeface, such as "Arial," you may not always get the font you want. Fonts are a computer resource, and not all computers have the same fonts as your computer. That's true even between different PCs, but it's especially true between the PC and the Mac. If the typeface of your page suddenly changes between these computers, you've probably used a font that isn't available on both computer types.

Font Size. The Mac will generally render your typeface in a smaller pixel size than the PC will. That's especially true if you use the FONT tag to set your type size, since this tag uses abstract units to define size. You can avoid this problem is you use Cascading Style Sheets to set your font size in pixels. ac.

Internet Explorer. Microsoft outsources the development of Internet Explorer for the Mac, and so to a large extent this is a different browser from the PC version. In particular, the Mac version of Internet Explorer is prone to quirks and bugs that you won't see in the PC version. If you check your Web page under only one browser on the Mac, do so under Internet Explorer!

Different Screen Sizes

If you don't test your pages using different screen resolutions, your page may be stretched to fit a large screen, or be cropped to fit a small screen.

Many experienced Web designers use HTML tables to control their page layout, yet they design their pages on large, 1024x768 pixel screens. When these pages are displayed on smaller computer screens, the browser may not be able to fit all the content onto the screen. In these cases, the content will scroll of the right of the page. While this may not sound like much of a problem, users hate scrolling left and right to view a page.

This problem should be easy to avoid, yet a surprising number of otherwise well-designed Web sites don't fit within the standard 800-pixel PC computer screen. This is especially a problem for pages built by graphic artists using a Macintosh, whose standard screen size is 1024x768. Many designers forget that designing for an 800-pixel screen means using roughly a 750-pixel layout.

Many less experienced Webmasters design their pages without tables, or dimension their tables to fit 100% of the screen width. If you've built your Web page this way on a computer with an 800-pixel screen, you may be surprised how your page is stretched to fit a larger screen. Text and graphics that were adjacent on your smaller screen may not be so on a large screen.

To avoid this, wrap the content of your page inside a single, large, one-cell table. Set the width of this table to be about 560-pixels, if you're designing for a 600 pixels layout, or 750-pixels if you're designing for an 800 pixel layout.

Because the majority of Internet users have a screen resolution of 800 pixels or less, it's a bad idea to design your site for a larger screen.

Different Font Sizes

Most browsers allow users to customize their default font size. Many users who work on computers all day do this to reduce eye strain. As a result, user preferences may cause the typeface that you used to design your Web page to increase as much as 50% larger in a user's browser. This increase in font size can hurt many carefully-planned page designs.

HTML Errors

Whether you're an HTML coder who builds Web pages by working with the raw HTML tags, or a designer using a WYSIWYG editor like FrontPage or Dreamweaver, the odds are your finished Web page will contain HTML errors.

An HTML error is some spot on your Web page where you've violated the official rules of HTML. For example, you may have two tags that overlap one another in a way that the standards say isn't legal.

In practice, the major browsers are robust and forgive many of these HTML errors. But not all browsers forgive the same errors. So your favorite browser may display your Web page without error, but another browser may be seriously affected by the same error.Internet Explorer forgives this error and displays the page correctly; Netscape Navigator can't recover from the errors and doesn't display the page at all!

Browser Problem:

I am gathered this info from ocportal.Credit goes to the actual author.

1) IE will try and guess mime-types based on file extension, even if the mime-type was specified by the web server. This can result in unexpected security holes – for example, if you allow users to upload files and you even take the precaution of saving them as ".dat" (which a default server config would serve as application/octet-stream ) they could be executed in IE with Javascript by anyone who knows the URL. This is a very dangerous XSS vector – the hacker just would just need to upload a malicious file, give the URL to an IE user to open, and they could steal things like passwords from that user. Fortunately in IE8 this behaviour can be disabled but it requires explicit action by the programmer/server-admin for it to be.

2) IE does not actually support XHTML, it can't display it at all. For this reason people rarely if ever have their servers configured to send true XHTML – instead they send XHTML documents using an HTML mime-type. When you view this "XHTML" on IE or any other browser it's actually just rendered by an HTML parser. Contrary to common understanding the doctype does not specify to a browser what renderer to use. Firefox and other browsers do support XHTML, but XHTML is a lot stricter than most people realise, and if it is truly enabled people find they have made a few mistakes which stops whole pages from rendering at all (true XHTML has no error tolerance). Hopefully IE9 will support XHTML, but when people update their servers to use the right mime-type they're in for a shock. ocPortal does use XHTML, but we develop it wit the correct mime-type enabled on our test servers, to ensure it'll work.

3) You can't have "disabled" list items in a select. These are incredibly useful for spacing out lists for usability purposes and it's a shame they don't work right in IE.

4) In IE if you do something like:
you get a Javascript error. Unfortunately IE can't do this pattern across it's Active-X interfaces, even though it is valid and normal Javascript. However, fortunately you can do:

which is better code anyway. Never-the-less, it's very easy to fall into the trap.


 This is a really interesting one: I checked, this will break on IE, but work on Firefox. It's due to the order in which entities and Javascript are parsed. Firefox is smarter, but arguably it may actually be Firefox in the wrong here.

6) You can't do the following in IE: Consider the 1st line of the code...due to the final comma. However, in other browsers it works.

7) This is a very common problem: Look at the last 3 lines of code On Firefox both work, but on IE only the second works. It's a real shame, but mostly it leaves a big trap to fall into if you don't test in different browsers.

8) Firefox is less fussy about semi-colons: Code

var foo1=function() { }
 var foo2=function() { }
 In IE Javascript won't parse, but it does work on Firefox. I actually think Firefox should explode too (IMO there's no good reason for missing a semi-colon even if the ECMA specification allows it – it's just sloppy) – but what matters is the difference in behaviour can lead to easy bugs.

9) IE will cache the output of it's xmlhttprequest object, for scripts not marked as cacheable, whilst Firefox will not. Unless you know about this problem it is very frustrating to debug. One solution is just to append random parameter values to the URL, so that it can't be cached; however I would guess this causes cache pollution, so in ocPortal we actually output extra explicit "do not cache" headers on the server side.

10) IE (or is it Firefox?) ignores PNG-file gamma settings, meaning unless gamma settings are stripped, images get subtle colour differences on IE and Firefox. Photoshop unfortunately always uses gamma. As I mentioned I'm not sure whether it's IE or Firefox at fault here, but I always solve this by running PNG files through a PNG compression application such as PNG Gauntlet, which kills two birds with one stone

Browser Bugs As you've probably seen by now, building a Web page that displays well on all browsers isn't easy. To make matters worse, sometimes you've done everything right, and your page still doesn't display correctly under one specific browser.
It's not your fault - you've just encountered a browser bug. Unfortunately, browser bugs are a fact of life for Web designers.

Each browser has its own unique set of errors and quirks that you have to adapt to. That's especially true with Version 4 of Netscape Navigator, whose early editions were rushed out the door to beat Internet Explorer to market. A columnist for WebReference recently called Navigator Version 4 "truly terrible browser." For example, take perhaps the most widely encountered browser bug in existence.

 The HTML standards say that when you build an HTML table, you don't have to explicitly close each table cell with a closing tag. This closing tag is optional. Yet unless you explicitly close your table cells, Navigator 4 will not display your table if it is nested inside another table. Since nesting tables is common practice to control page layout, this bug wrecks many well-designed pages. Netscape isn't the only browser prone to bugs. Internet Explorer for the Macintosh has a number of bugs and quirks in the way it handles text spacing. When you encounter a browser bug, it often means resorting to trial-and-error debugging to remove the problem.
Set a Goal First, understand that it's hard to build a Web page that displays perfectly on every version of every browser running on every computer. And doing so may require you to leave out features that you really, really want to have on your Web page. Building a Web page that's compatible with Version 1.0 of every browser would mean building a bland page filled with plain text. So the first step to solving browser compatibility problems is to determine which browsers really matter to you. Avoid the Cutting Edge The Web is hip; it's hot and exciting; it's radical.

So many Web designers feel they have to build cutting-edge features into their Web page. That's a bad idea, because cutting-edge features are rife with browser compatibility problems, not to mention the impact they have on your page load time.

Pay Attention to Your Browser Compatibility Report While HTML Toolbox can solve many browser display problems, there are some problems it can't address. That's especially true if these problems are caused by browser quirks and bugs. In these cases you'll have to track down your HTML problem yourself.

Be patient; you can expect this process to take anywhere from one to four hours. Try following these steps to track down the cause: Make a copy of your Web page so you can restore it to its original form if you need to. Debug this page, not your original Web page. Isolate the problem on your copied page. Do this by eliminating as much of the page as you can. Is the problem at the top of your page? Then throw away everything but the top section of the page. View the pared-down page in the problem browser (use Browser Photo to do this if you need to).

Is the problem still there? Then remove more of the page. Eventually you'll get to a point where the problem disappears. In that case, the last part of the page you deleted probably caused the problem. Now go back to your original page (or create a fresh copy of it and work with that). Look at the section of HTML that may have caused your problem. Change it.

Now start a new Browser Photo session for your page. View the results and see if you've corrected your display problem. If so, then it is ok. After you've fixed the problem, be sure to review your Browser Photo snapshots for other browsers too. It's a common mistake for HTML coders to fix a problem under one browser, and in the process break the page under another browser. Don't expect your first guess to solve the problem. More often you'll have to try a number of different things to see if they solve the problem. Again, be patient with yourself; this takes time.

 Why do you care about Browser Compatibility? Web sites reflect the company's professional image. If your site renders improperly or not at all, your company's reputation can be tarnished. If your site has browser display problems, visitors and potential customers will leave your site and not look back. In contrast, a professional looking site will make visitors feel more comfortable, stay longer and browse more pages. And because of this increased credibility, they are more likely to purchase the products and services that they are looking for from you. Now the ultimate point Write correct markup - make sure it validates Make sure your markup is in standards mode Write correct CSS - make sure it validates You can use a CSS framework, like Blueprint,, YUI CSS library For Internet Explorer -related issues, there is ie7.js and ie8.js
Cross Browser Testing---what is it?,Browser compatibility and strategy for cross browser testing Cross Browser Testing---what is it?,Browser compatibility and strategy for cross browser testing Reviewed by Animesh Chatterjee on November 21, 2009 Rating: 5

No comments:

Powered by Blogger.