IE 6, 7 and 8 and other browsers. Support them all.

As you can see I’m not one for short posts, but sometimes a great article needs to be pimped. Smashing imageMagazine has lots of those and whilst I’m mostly a Web Developer and not a Web Designer (I do have an iPhone so there may be hope for me) it’s good to keep an eye on the current design trends for web applications.

Smashing, super, great, well not so great with IE6.

Their current article “CSS Differences in Internet Explorer 6, 7 and 8” is a change from the normal rant at Microsoft fare, but aims at understanding all the differences that occur in the Microsoft browser segment of the market around, in this case, their different handling of CSS. The main fact of importance is the imagecontinuing need to support all of the browser due to their market share, each browser holds almost an equal share of the 65%+ of the market (as seen on Market Share).

In fact if you break it down even more we see that IE8 compatibility mode beats Chrome and that really for public sites you should be testing for Safari as well.

Browser Market Share
Microsoft Internet Explorer 6.0 24.42%
Microsoft Internet Explorer 7.0 19.39%
Microsoft Internet Explorer 8.0 16.84%
Firefox 3.5 12.65%
Firefox 3.0 9.62%
Safari 4 2.92%
Microsoft Internet Explorer 8.0 (Compatibility) 2.30%
Chrome 2.0 1.74%

Like any large company, Microsoft has a great deal of legacy to support, people who have brought their products, people unlike myself who don’t want to upgrade at the first opportunity, who are happy with the way something works (even if it is IE6). Especially where a browser still holds such a large part of the market within the enterprise space, the cost to upgrade all of the browsers (which work for all the applications they currently use by the way!) could be prohibitive in the current economic climate.

Testing Painimage

All this leaves is a massive amount of legacy testing pain for development teams, especially when developing applications for use within an enterprise environment. It’s all very well for people on the social side of web development to trumpet the call to the new, but when part of your market is stuck in 2001, so to a certain extent are you.

At this point it’s interesting to look at the support level of browser for ArcGIS Server here. The supported browsers are Firefox 2,3 and IE 6,7,8. That’s not to say stuff won’t work in Chrome (it’s does, I’ve tested it) or Opera (I don’t know, sorry), but the official line is what is shown on the site, so when developing applications for use with ArcGIS Server it’s always good to remember what’s official supported and choose that as a baseline.

In fact many people are tempted to throw the browser out completely and fall back into the loving arms of the plug-in. Flash and Silverlight take much of the worry about browser support of the nuances of CSS imageand JavaScript but providing a nice sandbox for the application to play in. Unfortunately they are no true panacea. Often the enterprises that are still on IE6 are probably on Flash 5, if they have Flash at all and might never have considered Silverlight (although Microsoft’s positioning gives Silverlight a more enterprise-y feel allowing it to make inroads sooner within the firewall). This leaves you back at the beginning needing to support your browser based application in IE6, there is no escape, accept it and test accordingly.

And finally.

One great quote from the comments is this “You could power every house on Earth for a few hours– just from the sheer RAGE MSIE elicits from Web Designers.”. It’s not just IE, the lack of standards amongst browser has always been a frustration, Microsoft might be the current football to be kicked around, but in its day Netscape was the villain. image

Whilst most people, probably even Microsoft, want IE6 to go away, it wont soon, people image like www.ie6nomore.com have a funny campaign, but the only thing that will change that is when all the big companies have gone through a technology refresh and the
re are only a few copies of IE6 lingering left. In the non-corporate world, well as Amy Barzdukas (Microsoft IE general manager) says "Friends do not let friends use IE6”.

Know Thy Browser!

When developing any web based application is pays to know exactly what your browser can do. If imageyour developing an internal application you can make sure you maximise the website to what the browser can  support, this is Nirvana (provided the internal browser isn’t IE6, which in this case is usually is) just make sure your aware of any upgrades to the browser on the network and test early!

If your working in the more common heterogeneous environment that is more common on public facing sites then understanding which browsers your going to have to support for your application is fundamental as this will not only guide what you are going to test but also guide what technologies your able to use.

What do you need to support?

Often you start a project with some lofty goal of support all known browser type, or you’ve worked on a project before and stipulate that you’ll only support one or two of the main ones. Then you start getting calls about problems with your site, some oversight of a major browser or a newly released browser imageversion has caused problems with your site, making it look uglier at best or stop working at worst. How do you know what to support or who is using your site? Often a lot if this information can be captured by analytics software such as Google Analytics. This can then monitor who accesses your site and determine the browser they are using by capturing their information. For many clients this information already exists for the main website and can be provided as part of the requirements of any project. For this limited site the output is as follows for a certain period.image Now monitoring this list for changes and increases in new browsers types or updated types of existing browsers should allow you to plan your ongoing testing strategy and make any changes to the site before they become more commonplace. This is preferable to when you see betas of new browsers start accessing your site obviously. So now you know what you need to support how to find out information about what these browser can do (without endless testing of your own).

If you have endless time there is a full list of many browsers is available from Wikipedia.

Help at hand, ironically in a browser.

With a variety of browsers out there it helps to have a set of tools to tell you what is or isn’t supported and how they might perform. There are a number of tools to do this.

Browserscope provides a collaborative list of what a particular browser supports by profiling your browser and adding it to the list of browser that are ‘out in the wild’. If you see from your analytics that a new browser type is often accessing your site then you can check Browserscope for what it supports, which is very useful. More information can be got at Steve Souders blog here.

We all know about CSS and JavaScript issues and browsers. A number of websites have been dedicated QuirksModeto this for years, such as Quirksmode with it’s browser compatibility tables (now with updated HTML 5 information yay!). One area which is popular with a certain section of online advertisers but is often not considered by many developers is the CSS support of email clients.

It is often the case with spatial analysis, either using a map or not that the output might be emailed to imagepeople who fall within a certain location and the application your developing might need to send a html formatted email to customers. Making sure you use the right sort of formatting in this case is as important as support within a browser. This list, from CampaignMonitor of CSS support in email clients can give a quick overview of what you need to be supporting within any particular email system. Obviously testing will always be the final arbiter.

ArcGIS Browser support

Whilst Flex (Flash) and Silverlight clients are protected by their individual hosting components, the WebADF and JavaScript API clients both run within the browser. As with any library that is itself built on other libraries you need to be careful what the whole stack supports, especially when you use non-core imagecomponents such as though provided by DojoX. There are a number of resources that should be checked once you know the level of browser you should support with any website.

ArcGIS Browser System Requirements : note this is for the 9.3.1 library, it should be seen that there are compatibility issues with the newest version of IE, IE8. Checking how a site works in the compatibility mode of IE7 might be able to make any site work in that browser, this can be forced using the IE=EmulateIE7 meta tag you can find more details and caveats at the IE blog here.

Dojo Browser Support : This is important if your aiming at rolling out additional components (Dijits) with the Dojo 1.3 is supported fully in only certain browsers and should be checked before any project is started.

ASP.Net AJAX Browser Support : Again this is useful to know if your deploying components with the WebADF. It seems the site suggests that you don’t use Linux when browsing ASP.NET AJAX based sites, although I would assume they would work fine in Firefox on Ubuntu or other systems.

Support Everyone (maybe) with Graceful Degradation

One of the issues when using modern technologies, especially on public sites that need to provide data to all users regardless of browser being used. This can often be achieved by providing a view of the data on a page that has only basic content and search facilities. For many components, such as those provided by Dojo or ASP.NET then the degradation is often provided within the component, sites should be tested with a variety of browsers, information about how and what each browser supports can be then given to the users of the site, rather like Yahoo does with their graduated browser support and rating for their YUI (Yahoo! User Interface) library.

Browser support has always been a complicated issue, over ten years ago I wrote a column about the the same compatibility issues within browsers. Today’s libraries handle a lot of the issues about browser support both at the client level and with communication with the server, but they are not perfect and it’s only through understanding the requirements of the users of the system and the capabilities of the minimum browser to be supported will the right choices be made.