What are common Cross Browser Issues and how to handle them?

ADMEC Multimedia Institute > Web Design > What are common Cross Browser Issues and how to handle them?

All the Web designers and developers must be very much familiar with the term cross browser issues, the below given article will surely be helpful for those who are new to web designing field or for those who are confused between some of the web terminology.

A brief Overview of term Cross browser and Multi Browser

Cross-browser refers to the capacity for a website, web application, HTML or client-side script to support all the web browsers. The term cross-browser is often confused with multi-browser , I would like to clear this confusion, Multi-browser is a new standard in web development that allows a website or web application to offer more functionality over several web browsers, ensuring that the website or web application is accessible to the largest possible audience without any loss in performance. While Cross-browser capability allows a website or web application to be properly rendered by all browsers. The term cross-browser has existed since the web development initiated.

Cross-browser compatibility ultimately has very little to do with what a web site looks like, and a lot more to do with how it functions. It also has relatively little to do with browsers, and perhaps could better be explained as multiple user-agent compatibility.

“Compatibility” (in this context) is not a term which means “looks and behaves identically”?—?instead, it may be better described as “performs equivalently under alternative conditions.” But developers and designers tend to most immediately seize upon appearance as the guiding line for cross-browser compatibility.

Of course, let’s be honest there are a lot of very good reasons for this. Completely disregarding what we may know about the behavior of a site, clients tend to be very visually oriented. They pop their new site open at home one day during development and notice a whole variety of differences which they’re suddenly concerned about. If you’re lucky, they’re opening up Internet Explorer 6after you’ve gone through the painstaking process of correct its inability to cope with standards-compliant code, rather than before you’ve gotten around to it. That can be awkward…

Introduction

When a software program is developed for multiple computer platforms, it is called a cross-platform program. Similarly, when a website is developed for multiple browsers, it is called a cross-browser website.

The job of a Web developer would be much easier if all browsers were the same. While most browsers are similar in both design and function, they often have several small differences in the way they distinguish and display websites. For example, Apple’s Safari uses a different HTML rendering engines than Internet Explorer. This means the browsers may display the same Web page with slightly different page and text formatting. Since not all browsers support the same HTML tags, some formatting may not be recognized at all in an incompatible Web browser. Furthermore, browsers interpret JavaScript code differently, which means a script may work fine in one browser, but not in another.

Because of the differences in the way Web browsers interpret HTML and JavaScript, Web developers must test and adapt their sites to work with multiple browsers. For example, if a certain page looks fine in Firefox, but does not show up correctly in Internet Explorer, the developer may change the formatting so that it works with Internet Explorer. Of course, the page may then appear differently in Firefox. The easiest fix for browser incompatibility problems is to use a more basic coding technique that works in both browsers.

What is Cross-Browser Compatibility

Browsers parse code differently. Internet viewers use a variety of browsers. It is a good idea to design your website in a way that vast majority of viewers can get the full benefit of your site. The best website designs are compatible with the most popular browsers, thus being cross-browser compatible.

The browsers that have the fewest problems with style sheets are those that do not support them at all – they will not be caused to crash by them; they will not cause unreadable documents, etc.

Approximately 5% of browsers do not support CSS (about 80% of these older browsers are Netscape 3 installations), and almost all of these support some kind of graphics or color, etc. Therefore, if these users come across your page that uses style sheets alone, they will think that you don’t know how to change the page from black on gray to something more attractive, and will probably be less inclined to buy your product, and might not bother to read your page at all.

Most commonly used browsers?

Are you aware of the most commonly used web browsers today..? Well! Internet Explorer (IE) is the most widely used browser. Next in popularity is Firefox. One that is gaining in use is Opera. Each of these browsers has different versions which also read code differently.

If a web page is completely cross-browser compatible, it will look more or less the same in all of the existing web browsers. The table below shows their usage as of November 2005.

Each one of these browser implements HTML, JavaScript and Cascading Style Sheets (CSS) a little differently. Some difference only create cosmetic difference others can break the webpage. The situation gets worse because each browser is free to implement “enhancements” to the W3C standard version of each of these formats.

How can I be sure my website is cross-browser compatible?

As you probably know, cross-browser testing is an important part of any developer’s routine. As the number of browsers increases, and they certainly have in recent years, the need for automatic tools that can assist us in the process becomes ever greater. In this article, we present an overview of different cross-browser testing applications and services. Surely, you are already familiar with some of them, and you may have even stumbled across another overview article, but this one takes a different approach.

This is not just a list of available tools, but rather a comprehensive analysis based on my experience with each of them.

Probably the most important metric of these services is the capture delay, with the following browsers enabled: Firefox, IE, Chrome and Safari.

Test your website in different browsers. I would recommend having at least three browsers downloaded onto your computer: Internet Explorer, Firefox and Opera. The browsers listed cost nothing to download.

The more testing you do of your site while it is being constructed, the more sure you can be of its appearance to your audience. Frequent testing also reveals problems early in the design process, making them easier to pinpoint.

Cross Browsing Tools

Sometimes it is not possible to have a running browser with multiple versions (example: IE7 + IE6 on Same PC) so it is useful to have standalone browsers to help you debug and test. Here are some tools below that may be helpful for you.

Browser Lab

Browser Lab is a new offering from Adobe and was previously known as Meer-Meer. It is written in Flash and as such has the advantage of being cross-platform compatible and of having the look, feel and (most importantly) response time of an application. It is currently offered free of charge in preview mode while Adobe “is monitoring the performance.” Because it will monitor it for more than one year, one wonders whether it has other reasons for this.Browser support is modest compared to the competition. At the time of writing, BrowserLab supports only Chrome, Firefox, IE and Safari: a total of 12 browsers and OS version combinations. But it looks like the quality of the product is still at beta level; in two captures, it actually cut the image horizontally. Scroll bar support is buggy, too.

Browser Camp

Browser Camp is another well-known screenshot service. Unlike Browser Shots, this is a commercial service. The cheapest plan cost $159.80 a year and provides access for five users. The interface is nice. It allows you to create a project and specify the URL and browsers you want to capture, so that you do not have to do it all over again to re-test the page. But because it is a non-AJAX Web-based interface, its response time is not comparable to that of a native application, which is a bit annoying.

Browser Shots

Browser Shots is the oldest and best known free online multi-browser screenshot service. It supports the largest number of browsers: a total of 61 different browser versions and operating systems, which is great, but I can hardly imagine anyone wanting to test their website under Kazahakase 0.5 running on BSD Unix. Feature-wise, it allows you to enable and disable Javascript, Java and Flash and change the screen size.
The interface is not very user-friendly. Selecting the browsers and options you want takes time, and because it is a Web service you have to do it over every time you want to take a screenshot. When (and if) you finally get your screenshots, there is no easy way to compare different captures in order to find rendering inconsistencies. HTTP redirect is not fully automated: Browser Shots displays the URL you are being redirected to, but you have to start the screenshot again manually.
The biggest disadvantage of Browser Shots—which, in my opinion, makes it practically unusable for a professional developer — is the response time. In our test scenario, it was more than 45 minutes. Note that a screenshot expires in 30 minutes, unless you manually extend it. As you can see from the shot below, Browser Shots has serious bugs with scrolling (see MSIE 8.0 screenshot) and at least one browser screenshot failed, even though it said the operation was successful.

Browser Packs

If all you need is to test your website in specific browsers with and you are willing to perform the tests manually, there are a few free services and applications that could help:

  • Spoon
  • BrowserSeal.BrowserPack
  • Internet Explorer Collection
  • IE Tester

At first glance, Spoon looks convenient because it is a Web service, which relieves you from having to install many browsers locally. But I had some stability problems with this service.
Meanwhile, both the IE Collection and BrowserSeal.BrowserPack (offered free of charge, separate from the BrowserSeal commercial screenshot service) work very reliably. I did not have any issues with browsers installed by these packs. The IE Collection has every IE version you could think of. BrowserSeal.BrowserPack, which relies on the IE Collection for IE support, also supports two Firefox, three Opera and two Safari versions.

Conclusion

The following table summarizes services that were tested and analyzed in the article. You can use the separate page for the full table for a better overview. I have included some metrics for each service to make it easier for you to choose the best one based on price, features and performance trade-offs.

The Importance of Cross Browser Compatibility: Tips and Resources

Nowadays everyone’s using a different browser. Between popular options like Firefox, Safari, Chrome and Internet Explorer, which make up close to 98% of the internet market share of browsers, and the other little known browsers like Konqueror, there are a multitude of browsers being used to view your site.
How does your website function across all these options? It’s important that your website is usable across all major media, whether it is popular browsers, mobile devices, or any other web browsing devices. In this article, we’ll cover some basics of making sure your site is cross-browser-compatible, including snippets and resources to help you along the way.

The Principles Of Cross-Browser CSS Coding

It is arguable that there is no goal in web design more satisfying than getting a beautiful and intuitive design to look exactly the same in every currently-used browser. Unfortunately, that goal is generally agreed to be almost impossible to attain. Some have even gone on record as stating that perfect, cross-browser compatibility is not necessary.
The most important CSS principles and tips that can help both new and experienced front-end developers achieve as close to a consistent cross-browser experience as possible, with as little CSS code as possible.

Understand the CSS Box Model

This is one of the first things you should be thoroughly familiar with if you want to be able to achieve cross-browser layouts with very few hacks and workarounds. Fortunately, the box model is not a difficult thing to grasp, and generally works the same in all browsers, except in circumstances related to certain versions of Internet Explorer.
The CSS box model is responsible for calculating:

  • How much space a block-level element takes up
  • Whether or not borders and/or margins overlap, or collapse
  • A box’s dimensions
  • To some extent, a box’s position relative to other content on the page

The CSS box model has the following basic rules:

  • Block-level elements are essentially rectangular (as are all elements, really)
  • The dimensions of a block element are calculated by width, height, padding, borders, and margins
  • If no height is specified, a block element will be as high as the content it contains, plus padding (unless there are floats, for which see below)
  • If no width is specified, a non-floated box will expand to fit the width of its parent minus padding (more on this later)

Some important things to keep in mind for dealing with block-level elements:

  • If a box has its width set to “100%”, it shouldn’t have any margins, padding, or borders, otherwise it will overflow its parent
  • In block-level elements vertically-adjacent margins can cause some complex collapsing issues that may cause layout problems
  • Elements positioned relatively or absolutely will behave differently, the details of which are extensive and beyond the scope of this article
  • The rules and principles above are stated under the assumption that the page holding the block-level elements is rendered in standards
Understand the Difference between Block and Inline

Here are some basic rules that differentiate block elements from inline:

  • Block elements will, by default, naturally expand horizontally to fill their parent container, so there’s no need to set a width of “100%”
  • Block elements will, by default, begin at the leftmost edge of the parent box, below any previous block elements (unless floats or positioned elements are utilized; see below)
  • Inline elements will ignore width and height settings
  • Inline elements flow with text, and are subject to typographical properties such as white-space, font-size, and letter-spacing
  • Inline elements can be aligned using the vertical-align property, but block elements cannot
  • Inline elements will have some natural space below them in order to accommodate text elements that drop below the line (like the letter “g”)
  • An inline element will become a block element if it is floated
Understand Floating and Clearing

For multi-column layouts that are relatively easy to maintain, the best method is to use floats. Having a solid understanding of how floats work is, therefore, another important factor in achieving a cross-browser experience.
A floated element can be floated either left or right, with the result that the floated element will shift in the specified direction until it reaches the edge of its parent container or the edge of another floated element. All non-floated, inline content that appears below the floated element will flow along the side of the element that is opposite to the float direction.
Here are some important things to keep in mind when floating and clearing elements:

  • Floated elements are removed from the flow of other block-level, non-floated elements; so in other words, if you float a box left, a trailing paragraph (block level) that’s not floated will appear behind the float in the stack, and any text inside the paragraph (inline level) will flow around the float
  • To get content to flow around a floated element, it must be either inline or else floated in the same direction
  • A floated element without a declared width will shrink to the width of its content, so it’s generally best to have a set width on a float
  • If a block element contains floated children, it will “collapse”, requiring a fix
  • An element that’s “cleared” will avoid flowing around floated elements above them in the document
  • An element that’s both cleared and floated will only clear itself of elements that come before, not after

Understand Internet Explorer’s Most Common Problems

If you’re going to start with IE in your development, or at the very least check your layout in IE early on, then you should understand what things Internet Explorer (usually versions 6 & 7) has problems with, or what its limitations are.
A detailed discussion of every possible problem that can occur in Internet Explorer, and a list of all of its CSS compatibility issues are certainly beyond this article. But there are some fairly significant inconsistencies and issues that come up in relation to IE that all CSS developers should be aware of. Here is a rundown of the most common problems you’ll need to deal with:

  • IE6 will become problematic if floats are overused, causing (paradoxically) disappearing content or duplicate text
  • IE6 will double the margin on floated elements on the side that is the same direction as the float; setting display: inline will often fix this In
  • IE6 and IE7, if an element doesn’t have layout, it can cause a number of problems, including backgrounds not showing up, margins collapsing improperly, and more
  • IE6 does not support min- and max-based CSS properties like min-height, or max-width
  • IE6 does not support fixed positioning of background images
  • IE6 and IE7 do not support many alternate values for the display property (e.g. inline-table, table-cell, table-row, etc.)
  • You cannot use the :hover pseudo-class on any element in IE6 except an anchor (<a>)
  • Certain versions of IE have little support for certain CSS selectors (e.g. attribute selectors, child selectors, etc.)
  • IE versions 6-8 have little support for CSS3, but there are some workarounds

There are many more bugs, issues, and inconsistencies that can arise in Internet Explorer, but these are probably the most common and most important ones to keep in mind when trying to create a cross-browser experience. I encourage all developers to do further research on many of the issues I’ve mentioned above in order to have a more accurate understanding of what problems these issues can cause, and how to handle them.

Finally The Problems

There are already enough web technology standards to sink a battleship. The arsenal includes HTML 4.0, CSS1, CSSP, ECMA-262, W3C DOM, RDF, XML, CSS2, and every other three- and four-letter permutation of ASCII.
With so many standards, why is compatibility still an issue? Here are some of the key sources of difficulty:

  • Until Mozilla and Netscape 6 no browser had such high degree of support of many of the existing standards (e.g. HTML 4.0, CSS1, CSSP, W3C DOM level 1).
  • Web technology standards often leave room for differences in interpretation and implementation.
  • Standards often include suggestions or recommendations which vendors are not required to comply with.
  • Standards often permit vendors to add enhancements not defined by the standards.
  • The standards definition and ratification process often lags behind the implementation of functionality by the vendors.

The practical approach for building applications is to study the standards, study each vendor’s implementation, find the common functionality, and build on top of that.
This TechNote focuses on client-side techniques for achieving backward compatibility. It explains how to create a single page which degrades gracefully for older browsers. However, you can also address this problem on the server side by detecting the user’s client and delivering one of several pages that have been optimized for different browsers and versions. If you are comfortable with both client-side and server-side development, often a combination of the two approaches is most efficient.

Explanation of Cross-Browser Issues with Solutions

Browser bugs with CSS can be an incredible source of frustration for Web designers and developers. The Solutions to CSS-Related Browser Bugs, CSS Bug Fixes, and Cross-Browser, Cross-Platform Issues section below includes links to articles, tutorials, and resources to help you find CSS bug fixes (solutions to CSS bugs and browser rendering differences), CSS workarounds, hacks, and how to create cross-browser, cross-platform CSS – Cascading Style Sheets. Especially popular are IE7 CSS hacks and bug fixes, which are also included below, along with IE8 CSS bug fixes and more. All or nearly all CSS bug fixes, solutions listed below will still validate to W3C Recommendations, and if they don’t, they’ll say so with a warning at the particular Web site.

CSS Bugs, CSS Bug Fixes, Solutions, Workarounds for All Browsers:

Avoiding Hacks:

CSS techniques to help your site work the best cross-browser, cross-platform while avoiding using CSS hacks. Covered: using margin instead of padding on parent elements, letting font-size inherit from the root element.

Box Lessons: Bugs and Workarounds

Owen Briggs is documenting bugs, cross-browser problems and workarounds, primarily for CSS boxes, but also other layout issues with CSS. Lots for Internet Explorer, especially IEWin 5, IEWin 5.5, IE5 Mac, Netscape 6. Fabulous, helpful resource with lots of documentation, illustrations, links to more helpful information.

Clearing Floated Images in Body Text

“occurs when an image is floated left or right, and there isn’t enough text to exceed the height of the image … If the body text and the document byline are each contained in a div element, any floats in the body text div may stick out of the bottom of it and intrude upon the byline div, which doesn’t look too good.” Discussion/tutorial, thought process of figuring out a workaround, CSS code, links to other resources, and much more. Covers a cross-browser, cross-platform approach for a multitude of browsers, including IE5 Mac. Discusses clear:both and uses the Holly hack, display:inline-block and display:table for workaround. Also discusses other possibilities depending on your layout needs. Be sure to also read the comments following that, too.

CSS – Auto-height and Margin-collapsing …or…miraculously shrinking containers!

Fantastic, easy-to-understand explanation with plenty of examples along the way that show how browsers render auto-height and margin-collapsing. He uses a simple example of adding 20-pixel top and bottom margin style rules to a paragraph element and shows how it’s rendered in various browsers, why, and what you can do to get the result you want and also help cross-browser consistency – no hacks, and validates to W3C.

Cross-browser strategies for CSS

The author’s approach: good cross-browser coding is to find the set of standards that are supported and then use them. He writes about how to do exactly that.

Good CSS Hack

If a CSS hack is used at all, it’s important to use only what’s considered a “good” hack. This article explains the qualities of a good CSS hack and examples. Topics cover: future-proof, valid syntax doesn’t make a style sheet difficult to maintain.

Microsoft Internet Explorer CSS Bugs, Bug Fixes, Hacks, Solutions, Workarounds:

Although you’ll find plenty of approaches to workarounds, hacks, filters, and conditional comments below, conditional comments are currently the recommended way, the “best practice” approach to manage IE’s CSS quirks and bugs. What are conditional comments? Here’s an example that tells IE to use the content if it’s IE6. Other browsers will ignore conditional comments.
The above example will then serve only IE6 with the link to the ie6hacks.css file. Several articles and tutorials below explain in more detail what they are and how to use them. You’ll also find plenty of links to CSS bugs, solutions (not just conditional comments!), and workarounds.

Microsoft Internet Explorer: Conditional Comments:

Conditional comments for IE8, IE7, IE6, IE5…

Conditional Comments

Explanation of Microsoft conditional comments to use to target or exclude specific versions of Internet Explorer. Includes code examples, suggestions of how to use them effectively. Direct from Microsoft.

CSS Cutoff of Older IE

An easy way to hide, or “cut off” older versions of IE using conditional comments. Shows how to implement negative conditional comments effectively, “less/greater than” operators (gt/gte/lt/lte), tips to watch out for, examples, links to resources, and more.

#IEroot — Targeting IE Using Conditional Comments and Just One Stylesheet

Easy-to-implement approach to targeting IE or hiding from IE, too. The article says the combined approach using conditional comments and child selectors works for any version of IE, too. Worth checking out. The article’s summary: “The Star-HTML hack was a very elegant way to easily target style rules at IE and apply fixes. Internet Explorer 7 has fixed the Star-HTML hack, taking away the elegance. This article introduces a simple method for targeting CSS rules at IE that uses only one stylesheet and works for all versions of IE. It will require some minimal markup using Internet Explorer’s conditional comments and CSS descendant selectors.”

Summary:

Ideally, describing a page or script as cross-browser means that the script works identically not only in browsers from different vendors, but also in all the available versions of each vendor’s browser and in all the versions of each browser that run on different operating systems (such as the various flavors of Windows, the Mac OS, and Unix). This is why many people prefer the broader term cross-platform.

Those are some pretty big shoes, and, in practice, they can be filled only by the simplest page that uses only the most basic of tags. In the real world, achieving cross-browser status requires making compromises:

  • You might have to support only a subset of the browser population. The more sophisticated the effect you want, the more browsers you have to leave behind.
  • You might have to implement only a subset of the available browser functionality. Most newer browsers contain features that simply can’t be duplicated in older browsers, and those features have to be abandoned to achieve the cross-browser label. (Although you’ll see that there are ways around this, in some cases.)
  • You might have to be satisfied with creating effects that work substantially the same in your browser subset. It’s often possible to create a script that works identically, but “close enough” sometimes has to be good enough. What all of this really means is that your cross-browser scripts will support only the lowest-common browser denominator. In the DHTML world, this usually means Netscape 4 because it has the most limited object model.

That’s it for today, for all of those who are interested in making their career in web; courses like Web Master and Web Master Plus are recommended to join. Being one of the renowned web design training institutes in Delhi, ADMEC Multimedia offers a comprehensive teaching methodology in the form of its diploma programs.

Feel free to contact us today to get to know more about these courses.

Related Posts

Leave a Reply

Talk to Us