Multi-Browser Viewer Logo

IE marketshare declines, while Chrome keeps growing

clock May 5, 2010 05:50 by author

The latest monthly browser usage stats indicates an even sharper drop in marketshare for Microsoft's Internet Explorer since the browser ballot was launched in the European Union on 1 March 2010. Although Internet Explorer's marketshare still dominates, it is certainly under growing threat, especially from the likes of Google's Chrome browser, who's marketshare has essentially exploded since it was launch not even 2 years ago.

 As you can see on the chart below, Google Chrome accounts for almost 7% of the browser market share and is climbing steadily. Internet Explorer has dropped below 60% marketshare. It is interesting to note how many users are still using IE6. According to hitslink, approximately 18% of worldwide users still use IE6. This figure obviously include large coorporations that have not gone through the upgrade path yet, as well as users who are unable to upgrade due to bandwidth restrictions or Microsoft copyright infringements(illegal copies of their Windows OS etc).

 

There are many different browser usage statistics sources available on the web. I used http://marketshare.hitslink.com/ .


Location: PostList


Google Chrome 4 for Windows now available for screenshot testing

clock January 29, 2010 10:56 by author

As you know Google officially released version 4 of their Google Chrome browser for Windows on the 25th of January 2009.

Some of their new cool features include:

  • Support for extensions: Extensions are little programs, created by developers, which add useful functionality to the browser and to the websites you visit.
  • Bookmark Sync: For those of you who use several computers for example, a laptop at work and a desktop at home, you can now keep your Google Chrome bookmarks synchronized and up-to-date across computers.

You can read more about Google Chrome v4 here: http://chrome.blogspot.com/2010/01/over-1500-new-features-for-google.html

Chrome 4 for Windows is now available for cross browser screenshot testing in Multi-Browser Viewer, bringing the total number of screenshot browsers available for testing to 49.

 


Location: PostList


Opera 10 & Chrome 4 Beta for Mac OS added

clock December 14, 2009 13:32 by author

With the official release of Chrome 4 beta for Mac OS last week, Multi-Browser Viewer is very happy to announce that we now fully support both Chrome 4 beta for Mac OS and Linux for screenshots.

As far as we are aware that makes Multi-Browser Viewer the first cross crowser testing software to support Chrome for both Apple Mac OS as well as Linux. Currently this is only limited to a few machines as we stress test the solution, but will be rolling it out to more machines when we are comfortable that it is stable and scalable. We have also rolled out the long awaited Opera 10 for Mac OS.

This brings the total amount of screenshot testing browsers available to 48 major browser versions accross the 3 major operating systems, Windows, Apple Mac OS and Ubuntu Linux.

If you would like to read more about the Google Chrome for Mac OS: http://www.google.com/chrome?platform=mac&hl=en

 

 


Location: PostList


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


Google Chrome 4 for Mac OS Beta to be released in Dec09

clock November 18, 2009 12:21 by author

A beta version of Google’s Chrome browser for the Mac is set to become available in December.

Google had already gone on record to say that the test preview would arrive before the end of 2009.

In a developer thread, the company’s Chrome product manager Nick Baum revealed that Google plans to release the beta early December.

The current iteration of the browser - Chrome 4.0 - is only available in beta form for Windows users. Linux and Mac OS X fans only have access to a rough-round-the-edges developer preview of the surfing tool for now.

Multi-Browser Viewer already allows you to test your site against a pre-release of the Google Chrome for Linux browser.

 


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


Google Chrome 3 Final Released

clock September 16, 2009 13:22 by author

As you might have heard, Google released Google Chrome Browser yesterday.

Multi-Browser Viewer have been supporting Chrome 3 througout the stable Beta releases and is in the process of updating our network to support the final version. In fact you can also test the latest Beta version of Chrome on the Linux Ubuntu Opearting System using Multi-Browser Viewer.

Some of the main features accoring to Google:

  • Much Faster Javascript performance
  • Themes Support
  • New Tab Page
  • An much improved Omnibox

For full details check out the official Google Chrome Blog

 


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