we're currently maintaining an enterprise application based on ASP.Net 3.5, MS Enterprise Lib 4.1 and Telerik ASP.Net AJAX 2010. The application consist of 2 different part, intranet and internet portion. We announced compatibility with IE6 and above and Firefox, back in 2011. It's been fine so far until IE10 and 11 came into the picture. Since launch, we've advise users to turn on compatibility mode for IE8 & 9. But for IE10, we found that we need to add App_Browser, and it still break certain pages.
Now we plan to provide support to IE9 and above so we've decided to update Telerik ASP.Net AJAX to the latest version. But during this transition period, we notice a lot of UI issues when switching between browsers. To minimized effort on updating every page, we want to try using "ua-x-compatible" in web.config to force all browser to render with the best fit rendering mode. But there's no mentioned of setting IE=6. We're wonder how to configure it so that all new IE browser switch into Compat view mode used by IE8. Another thing we notice is that with IE=8, there's minor differences in terms of look and feel when compare to using IE8 Compat View. We're trying to minimized the differences as much as possible, to preserve the user experience.
We also understand that in intranet, newer IE browser will fall back to Compat View automatically, but that doesn't seems to be the case for us.
If there's a direct answer to this, then I would really appreciate it, otherwise some direction would be a good starting point.
Thank you
We should no longer as community keep support for IE6
Several communities are promoting to remove total support for this browser.
http://www.ie6death.com/
But I understand this not always I call we can make. I would recommend you to try :
http://modernizr.com/docs/#support
This will polyfill your javascript and will help you with your browser support.
In order to test CSS in different browsers, do I have to result to installing each browser on my development system? Isn't there a useful program where you can just load an html+css file and view how it's rendered in different modern browsers?
If you're after a professional solution, take a look at Litmus.
Nope, you have to have those browsers installed in some form, although there is software such as IE Tester which will allow you to open tabs as IE5.0 - IE8. There are also online services such as:
https://browserlab.adobe.com/index.htm
Free Service
Limited # of browsers Available
http://crossbrowsertesting.com
Paid Service
http://browsershots.org/
Free Service
Supports INSANE # of browsers
It can take a long time - I've had it take an hour to return screen shots during peak usage. Can be as fast as 2 minutes for a dozen browsers.
Which will let you view your site in multiple browsers.
If you want 3 engines in one browser check Lunascape.
Additionally for all Internet Explorer versions you have IEtester.
By that I mean if Firefox renders exactly in the same way on win/mac/linux and Safari on...
If not, what have you experienced?
There are differences - a really obvious one is the usage of native controls by default. There can be size and sometimes layout differences between the Windows/Mac controls (i.e. Mac OS file upload looks very different from Windows).
The usage of native control and font rendering mechanisms is where you'll see the most differences in FireFox.
In Safari, while not officially acknowledged, there does seem to be some deliberate changes in the port. One was exposed a while back in a vulnerability report - Safari could be commanded to silently download files (including exes) to the users default download folder (the desktop in the Windows version) on both Mac and Windows Safari. However the vulnerability was much worse on Windows because when Apple ported Safari to Windows, the code that set the untrusted file security attribute was removed or disabled, resulting in no warning when you double clicked that "My Computer(.exe)" or "Apple Safari(.exe)" icon.
Other than different font smoothing methods between OSes which makes the text look a bit different and different font availability (not all *nix platforms have Verdana), they should behave the same.
Under Safari-Win, you can enable Mac-style font smoothing.
There are some differences, but those are attributed to bugs and are being fixed.
They have been known to not render perfectly the same with specific versions, but they were bugs in the rendering engines. They should mostly be rather similar across OS, this also goes with chrome (linux version is in testing) and konqueror (there is a windows version) and any other cross platform browsers.
If you have the suspect, that there is a specific rendering difference between platforms (e.g., because a customer insists on experiencing some), I'd recommend Browsershots to clear the situation.
However, this is nothing for testing and debugging while developing. So I'm also curious to read the answers.
Cheers,
Fonts look a little different, because of different font metrics, font availability, and rendering algorithms. Obviously missing fonts have a major impact.
I've had bugs with differences in Flash on the platforms, which is not the browser, but relevant to the question. Linux has a z-index problem with flash movies.
Never seen a JS difference between the same versions of both platforms
I need to upgrade a ASP.NET website for IE8. it works fine in IE6, but not in IE8. I don't want to run it in any backward compatibility mode. I would like to make any code changes that are required to make it fully compliant with IE8/Firefox. what is the best and/or easiest way to do that? is it just a case of going through each of the things that are broken and fixing them one by one or is there a more efficient way to fix these issues (some kind of utility??). thanks in advance.
Well there is no tool or utility to fix cross browser compatibility issues. You can make use of firebug(firefox) and IE developer toolbar to identify the points where the website is breaking.
But the good part is that you are upgrading from IE6. I dont think there will be major hiccups or problems making the website compatible with IE8 since its much better in rendering HTML as compared to IE6.
If you have expression web, you could use SuperPreview: http://expression.microsoft.com/en-us/dd565874.aspx
THis is a great tool that allows you to compare you site in different browsers.
Yes, you do have to go through each browser incompatibility bug and fix it for that browser. A bug can be fixed in 3 ways (listed in my order of preference):
Start with a very compliant browser, then look at the page in other browsers (I focus on Chrome/Safari/Firefox/IE6-7-8-9)
Use different CSS technique, that ends up rendering the same in all browsers
Use IE Conditional Comments to bring in another CSS for that browser leveraging the CSS "Cascade"
Use CSS Hacks as a last resort (usually only for Firefox or something)
But "go through each browser" can be the tricky part! There are some tools to help.
#Brian mentioned SuperPreview for Expression Web (+1), but there's also a free version of SuperPreview for Internet Explorer for those who don't have Expression Web.
You can compare different versions of IE on the same machine (hard before this product). Microsoft claims this sub-set of the Expression Web product will always be free (since they feel bad about IE6!).
IE6-7-8-9 tool is good enough for me, because I tend to focus on all versions of IE, but only the latest versions of Chrome/Safari/Firefox.
But if you must test against multiple versions of other browsers:
Expression Web SuperPreview
How to Use Multiple Browsers on a Single Machine
10 Helpful Resources for Cross Browser Testing
(Although Litmus seems to have dropped general web page support, and instead focuses on email client compatibility and campaign analytics.)
Short version: What is the cleanest and most maintainable technique for consistant presentation and AJAX function across all browsers used by both web developers and web developers' end-users?
IE 6, 7, 8
Firefox 2, 3
Safari
Google Chrome
Opera
Long version: I wrote a web app aimed at other web developers. I want my app to support the major web browsers (plus Google Chrome) in both presentation and AJAX behavior.
I began on Firefox/Firebug, then added conditional comments for a consistent styling under IE 6 and 7. Next, to my amazement, I discovered that jQuery does not behave identically in IE; so I changed my Javascript to be portable on FF and IE using conditionals and less pure jQuery.
Today, I started testing on Webkit and Google Chrome and discovered that, not only are the styles inconsistant with both FF and IE, but Javascript is not executing at all, probably due to a syntax or parse error. I expected some CSS work, but now I have more Javascript debugging to do! At this point, I want to step back and think before writing piles of special cases for all situations.
I am not looking for a silver bullet, just best practices to keep things as understandable and maintainable as possible. I prefer if this works with no server-side intelligence; however if there is a advantage to, for example, check the user-agent and then return different files to different browsers, that is fine if the total comprehensibility and maintainability of the web app is lower. Thank you all very much!
I am in a similar situation, working on a web app that is targeted at IT professionals, and required to support the same set of browsers, minus Opera.
Some general things I've learned so far:
Test often, in as many of your target browsers as you can. Make sure you have time for this in your development schedule.
Toolkits can get you part of the way to cross-browser support, but will eventually miss something on some browser. Plan some time for debugging and researching fixes for specific browsers.
If you need something that's not in a toolkit and can't find a free code snippet, invest some time to write utility functions that encapsulate the browser-dependent behavior.
Educate yourself about known browser bugs, so that you can steer your implementation around them.
A few more-specific things I've learned:
Use conditional code based on the user-agent only as a last resort, because different generations of the "same" browser may have different features. Instead, test for standards-compliant behavior first — e.g., if(node.addEventListener)..., then common non-standard functions — e.g., if(window.attachEvent)..., and then, if you must, look at the user-agent for a specific browser type & version number.
Knowing when the DOM is 'ready' for script access is different in just about every browser. A good toolkit will abstract this for you.
Event handlers are different in just about every browser. A good toolkit will abstract this for you.
Creating DOM elements, particularly form controls or elements with attributes, can be tricky with document.createElement and element.setAttribute. While not standard (and kinda yucky), using node.innerHTML with strings that contain bits of HTML seems to be more reliable across browser types. I have yet to find a toolkit that will let you use element.setAttribute to add a 'name' to a form element in IE.
CSS differences (and bugs) are just as important as JS differences.
The 'core' Javascript features (String, Date, RegExp, Array functions) seem to be pretty reliable and consistent across browsers, especially relative to the DOM/CSS/Window functions. There's some small joy in the fact that the language isn't entirely different on every platform. :-)
I haven't really run into any Chrome-specific JS bugs, but it's always one of the first browsers I test.
HTH
Chrome is actually a little different to Safari, it uses a completely different javascript implementation and problems have been reported with both prototype and jquery. I wouldn't worry about it too much for now, it's still an early beta version of the browser and such inconsistencies will probably be treated as bugs. Here's the bug report.
One "silver bullet" you may consider turning to is Google Web Toolkit (GWT).
I believe it supports all the browsers you are interested in, and gives you the ability to code your UI in a Java-compatible IDE such as Eclipse. The advantage of this is you can use IDE tools for code completion and compile-time error checking, which greatly improves development on large-scale UI projects.
If you use GWT UI components, it will hide a lot of browser-specific nastiness from having to be dealt with, but when you compile, will create a compact, deploy file for each browser platform. This way you never download any IE-specific code if you are viewing the app in Firefox. You will also have a client-side stub generated which will load the appropriate compiled bundle of JS. To sweeten the deal, these files are cacheable, so perceived performance is generally improved for returning visitors.
The landscape has evolved considerably to accommodate cross-browser development. jQuery, Prototype and other frameworks exist for cross-browser Javascript. CSS resets are good for starting on a common blank canvas for all browsers. BluePrint and 960 are both CSS frameworks to help with layouts using CSS grid layouts techniques that seems to be getting very popular these days.
As for other CSS quirks across the different browsers, there is no holy grail here and the only option is to test you website across different browsers and use this awesome resource and definitely join a mailing list to save up soem time.
If you are working on high volume production site then you can use a service like browsercam.com in the end game to ensure the site doesn't break horribly in some browser.
Lastly, don't try to make the site look the same in every browser. Your primary design should target IE/FF and you should be okay with reasonable compromises on others. Use the graded browser chart to narrow in on browser support.
As for best practices, starting using wireframes on blank paper or a service like Balsamiq mockups. I am still surprised how many developers start with an editor instead of a wireframe but then again I only switched a year back before realizing how big a time saver it is. Have clean seperation of layout (HTML), presentation (CSS) and behaviors (Javascript). There should be no styling elements in HTML, no presenation in Javascript (use .addClass('highlight') instead of .css({'background-color': 'red'});).
If you are not familiar with any of the bold terms in this post, Googling them should be fruitful for your web development career and productivity.
If you're starting from a base reset or framework and have accounted for IE and it's still all freaky, you may want to recheck the following:
Everything validates? CSS and HTML?
Any broken links to an included file (js, css, etc?). In Chrome/Safari, if your stylesheet link is busted, all of your links might end up red. (something to do with the default 404 styling I think)
Any odd requirements of your js plugins that you might be using? (does the css file have to come before the js file, like with jquery.thickbox?)
For UI, check out Ext.
It's great as a standalone library, though it can also be used with jQuery, YUI, Prototype and GWT.
Samples: http://extjs.com/deploy/dev/examples/samples.html
I've found four things helpful in developing JavaScript applications:
Feature detection
Libraries
Iterative Development using Virtualization
JavaScript: The Definitive Guide, Douglas Crockford & John Resig
Feature Detection
Use reflection to ask if the browser supports the desired feature. If you want to know what event handling a browser supports, you can if(el.addEventHandler) for W3C compliance, if(el.attachEvent) for the IE-type, and finally fall back on el.['onSomeEvent'].
ONE BIG BUT!
Browsers sometimes lie about what features they support. I can't remember, but I ran into an issues where Firefox implemented a DOM feature, but would return false if you tested for that feature!
Libraries
Since you're already working with jQuery, I'll save the explanation. But if you're running into problems you may want to consider YUI for it's wonderful cross-browser compatibility. They even work together.
Iterative Development with Virtualization
Perhaps my best advice: Run all your test environment's at once. Get a Linux distro, Compiz Fusion and a bunch of RAM. Download a copy of either VMWare's VMWare Server or Sun's Virtual Box and install a few operating systems. Get images for Windows XP, Windows Vista and Mac OS X.
The basic idea is this: Compiz Fusion gives you 4 Desktops mapped onto a Cube. 1 of these desktops is your Linux computer, the next your Virtutual Windows XP box, the one after that Vista, the last Mac OS X. After writing some code, you alt-tab into virtual computer and check out your work. Plus it looks awesome.
JavaScript: The Definitive Guide, Douglas Crockford & John Resig
These three sources provide most of my information for JavaScript development. The Definitive guide is perhaps the best reference book for JavaScript.
Douglas Crockford is a JavaScript guru (I hate the word) at Yahoo. Lookup his series "Douglas Crockford Theory of the DOM", "Douglas Crockford Advanced JavaScript", "Douglas Crockford Theory of the Dom", and ""Douglas Crockford The Good Parts" on Yahoo! Videos.
John Resig (as you know) wrote jQuery. His website at ejohn.org contains a wealth of JavaScript information, and if you dig around on Google you'll find he's given a number of presentations on defensive JavaScript techniques.
... Good luck!
Just so you've got one less browser to worry about, Chrome uses the same rendering engine as Safari. So if it works in Safari, it should work exactly the same in Chrome.
See this post on Matt Cutts' blog.
Google Chrome uses WebKit for rendering, which is the same rendering engine as Apple’s Safari browser, so if your site is compatible with Safari it should work great in Chrome.
Update: Looks like this is now out-dated info. Please see Vox's comment on this answer.
If your very top priority is exactly consistent presentation on all the browsers listed with no disparities, you should probably be looking at AS3 and Flex.
Personally, I use Mootools as a simple lightweight javascript framework. It is simple to use and supports all the browsers above (except Chrome, but that seems to work too as far as I can tell).
Also, to ensure consistency across the browsers, I get a feature/style/behaviour/etc. to work in one browser first (usually Firefox 3 with firebug), then immediately check to make sure it works in all the other browsers (leaving IE6 for last). If it doesn't, I inveset the time to fix it right away, because otherwise I know I won't have time later (in my experience, getting things to work cross-browser takes about 50% of my dev. time ;-) )
Validating your javascript with a "good parts" + browser on JsLint.com makes it less likely to have JavaScripts behaving differently in FF, Safari etc.
Otherwise - using standards and validating your code as well as building on existing techniques like jQuery should make your site behave the same in all browsers except IE - and there's no magic recipe for IE - it's just bugs everywhere...