Multi-Browser Viewer Logo

With IE Rapidly Losing Marketshare, Cross Browser Testing is No Longer a Luxury

clock May 17, 2010 03:30 by author jamesmelvin

After many years spent building content management solutions for many of the Top 100 countries in the world (Including a stint working for Microsoft), I find it interesting how little validation goes into ensuring sites are cross browser compatible. Most developers are aware that testing the cross-browser compatibility of a website is something they should do, and although we all have own preferred browser, it is a given that your website visitors will probably not be using the same web browser as you. Cross browser testing is a type of compatibility testing designed to ensure that a web application behaves correctly (sometimes identically) in several different browsers and/or browser versions.

In the 90’s, there was a stage where Microsoft had over 95% of the browser market and no one cared about ensuring a site worked correctly in multiple browsers. The slow, steady decline of Microsoft Internet Explorer continues apace with the Internet Explorer charting another market share low in April with 59.95 % of the browser market–down from 60.65% in March and 67.77% from the same time last year. Clearly, IE 8, while largely well-received, hasn't done much to reverse the overall decline of Microsoft’s browser. Hard to believe that IE held an estimated 95% of the browser market in 2003, isn't it?

 

 

This is the first time IE’s share has ever fallen below 60%. What this clearly shows is that cross browser testing is now more important than ever before. Ensuring your site works on Internet Explorer means that at best, you are confident that your site works on 6 out of 10 visitors browsers. This of course is also incorrect because as any developer can tell you, IE 6, 7, 8 and even the IE 9 preview are vastly different rendering engines altogether.

So looking at the fact that Internet Explorer 8 has 24.66%, Microsoft Internet Explorer 6 17.58% and Internet Explorer 7 12.50%, even ensuring you reach around 6 out of 10 customers means you need to have at least done cross browser testing on 3 different browsers.

 

Meanwhile, Mozilla’s Firefox, Apple’s Safari and Google’s Chrome all made small gains at Internet Explorers expense. Chrome posted the largest gain, rising 0.6 points to 6.73%. Firefox’s market share rose 0.07 points to 24.59% and Safari’s increased just 0.06 points to 4.7%, a surprisingly under whelming gain for a browser that ships not just on the Mac, but on the iPhone, iPod touch and now the iPad as well.


So assuming that you built your website to reach the largest possible market, or if you are redesigning an existing website, you could look at the website stats for your website and see which browsers (and operating systems) the past visitors have been using. Understand, this is not a recommendation to ignore the less frequently used browsers of your visitors, but an exercise to show you what browser your website visitors are using, this would be a good place to start.


A safe policy to have is that each web page is viewable in as many browsers possible. The best way to do that is to ensure your code is as W3C standards compliant as possible. Of course you can use Multi-Browser Viewers Html validator to help there. (A shameless plug of one of our more powerful but obscure features).

So how do you make a Site Cross-Browser Compatible and is screenshot testing enough?

Firstly, to create a cross-browser compatible website ensure you follow the following simple standards:

   1. Use only standard compliant coding.

   2. Don't use browser specific (proprietary) HTML tags and features. (These only work in the browser they were created for and may even break your web page when viewed in another browser.)

   3. Validate your web pages.

  •       Validate your HTML/XHTML coding using the Multi-Browser viewer’s  or the W3C’s free validation service.
  •       Validate your cascading style sheets using the W3C free validation service.

 

 4. Given the interest in HTML 5 and the lack of interest in XHTML 2, develop HTML 4.01 Strict and follow these practices: (which are recommended in HTML 4, and required in HTML 5 and XHTML 1.1)

  •   All elements and attribute names must appear in lower case,
  •   All attribute values must be quoted,
  •   Non-Empty Elements require a closing tag,
  •   No attribute minimization is allowed,
  •   In Strict mode, all inline elements must be contained in a block element.

 

Some people may have the "You can't please everyone" attitude. Yes, your site will look different in each browser because each one interprets the coding differently. The goal with cross-browser compatibility is to make your site viewable in the major browsers available and have the pages render correctly. One thing that will drive visitors away is a site that doesn't work in their chosen browser. Of course you wouldn’t be reading this blog if that was the case so we now get to the steps I tend to follow to ensure compatibility.

      Test browser screen shots to identify initial layout issues. (Don’t just rely on screen shots as this is only a visual guide.) It doesn’t mean your website works. It only means it looks okay.

Test actual browsers to ensure that all menus, css, post backs etc. work. Remember that just because your site works in IE 8 doesn’t mean it will in IE 6.

Test mobile devices.

Cross-browser testing is a hassle. Most of the time you can follow standards and get a decent looking website working cross browser, but there's always variations. All browsers have their quirks and older IE's have more than their fair share.
As I see it, there's basically two sections to cross-browser testing.

 

Pros

Cons

Breadth
ScreenShot Service

Get screenshots of your site on multiple browsers and platforms

No interaction with the browsers, no way to debug interactions.

Depth - Interaction
Virtual Machines

You really get to see how your site looks and works on many browsers.

Typically, you have to maintain a bunch of Virtual Machines, or a be aware lot of browser installations. Please note that this is not the case with Multi-Browser Viewer

Neither are mutually exclusive and you really do need both to ensure cross Browser computability. Having a site look the same is the start, but ensuring the site actually works is certainly just as important, if not more important.  

Hope that helps.

James Melvin

 

 


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


Multi-Browser Viewer 2.0.4 Released

clock January 18, 2010 09:33 by author

The most comprehensive cross browser testing software application just got better!

Version 2.0.4 brings with it the following new features:

  • CDN integration: All sandboxed browsers and application updates are now delivered via a new world class CDN. This should provide much faster download speeds, and generally improved performance.Version 2.0.4 Main features - Click to download trial
  • Code optimization: The UI and basic scripting code have undergone some optimization, so the application should behave better.
  • Minor bug fixes: thanks for reporting any bugs to us, a number of minor bugs have been fixed.
  • Less Restrictive Evaluation version: More screenshot browsers are now available for testing, including IE6.

These new features build on Multi-Browser Viewer's existing main features like:

  • 16 Virtualized Sandboxed browsers – test using real sandboxed browsers locally on your own PC, no VNC or remote desktop connections needed.
  • 48 Screenshot testing browsers – high quality, full page screenshots of any URL, using our wide, always updated, selection of browsers on Linux, Mac or Windows.
  • Built-in HTML validation and auto-correction to help you identify possible HTML problem areas.
  • All files saved locally for future reference, including the HTML source code, web archive file and all screenshots images.
  • Multi-Browser Viewer is updated continuously to ensure you always have access to the latest web browsers.

Why don't you give Multi-Browser Viewer a try today and tell us what you think. You can download a full trial here.

 


Location: PostList


Multi-Browser Viewer receives 5 Cow rating!

clock December 18, 2009 14:09 by author

We are very happy and proud to announce that Multi-Browser Viewer just got a 5 Cow rating from Tucows! Thanks for everyone's input in making the product what it is thus far! With your support we'll keep on improving and innovating!

Check it out - http://www.tucows.com/preview/611775 

Also we still have a our end of year special running, if you were thinking of getting a license for the best cross browser testing software, simply use the coupon code - MBV-IUSW for 20% off.

 


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


Multi-Browser Viewer 2 Released!

clock December 4, 2009 19:12 by author

Multi-Browser Viewer 2 has just been released! After months of hard work and having listened to your feedback we have finally launched the next major version of Multi-Browser Viewer.

We still have to update some of the documentation, and other sections of the site, which still only covers the basic parts of v2 at present.

The coolest feature of v2 is the standalone browsers. Utilizing virtualization technology, we are now able to run all the major versions of web browsers alongside each other on one machine, with extra installs needed. All browsers run as a single executable that run instantly, each in its own sandbox — no DLLs, data files, installations, or runtime dependencies. The virtual browsers allows the application environment, including file system and registry subsystems, to be isolated from your computer, preventing the virtual browsers from interfering with your computer. This enables a user to test secure sites, Intranets etc. It also enable a user to test functionality like Flash, Javascript and Ajax. things that simply aren't possible using screenshots and is simply to slow via a VNC connection.

We are very proud of Multi-Browser Viewer as a product and feel that it now has all the functionality required to be one of the best, if not the best cross browser compatibility testing tool available today.

Some of the other updates include an improved installer, a snappier, more responsive interface and more Apple Mac browsers for screenshot testing.

We'd love to hear your initial feedback, let us know what you think. 


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


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


Cross-Browser Shortuts...

clock September 17, 2009 17:58 by author

Cross Browser Shortcuts you would ask? What on earth am I talking about.

Well over the past few months I have been testing, configuring many different browsers on Mac, Linux and Windows for Multi-Browser Viewer. 

We all have a favorite browser or two. A browser, where know the relevant shortcuts, which enables us to browse efficiently. Well, reading up on one of my favourite bloggers - www.favbrowser.com I stumbled on a shortcut list they compiled a while back, which I found really helpful and thought you might too.

Internet Explorer, Firefox, Safari, Google Chrome, Opera

CTRL + T (New Tab) – Opens a new blank tab

CTRL + C (Copy), CTRL + V (Paste), CTRL + X (Cut) - The old favorites....better than the file, edit menu for sure....

CTRL + A - Select All content

CLTR + F (Find) – Find test on a page.

CTRL + +/- (Zoom In/Out) – Simple yet effective way to zoom in/out.

Home/End (Go to Page Top/Bottom) – A quick way to instantly go to the web page top or bottom. Useful if it requires a lot of scrolling on long content pages.

ALT + D – Moves your mouse cursor to the address bar.

F5 (Refresh) – and CTRL + F5 forces a complete refresh of the page.

 

Internet Explorer, Firefox, Safari, Google Chrome

CTRL + Click (Open Link in Background) – Does what it’s designed to do. Works great when opening lots of pages.

CTRL + D (Bookmark) – Easy bookmarking

 

Firefox, Google Chrome, Opera

CTRL+J (Transfers) – Instantly open your transfer’s window.

CTRL + Shift + T or CTRL + Z (Opera Only) – Opens your previously closed tab.

CTRL + U (View Source) – Especially helpful for designers and webmasters.

Instead of using a search box in the top right corner, you can type your search query directly to the address bar.

Visit favbrowser.com for more browser shortcuts and other browser news.

 


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