Slashdot Mirror
Migrating IE Web Apps to Mozilla
PabloHoffman writes "Have you ever wondered what would it take to make your (unfortunately) IE-only web app to work on Firefox?. IBM published an interesting article about migrating Internet Explorer specific web applications to Mozilla-based browers. It covers basic cross-browser development techniques, and some developing strategies for overcoming the differences between both browsers."
Porting IE-only apps to Mozilla/FireFox is easy thanks to the extensive set of DOM and JavaScript debugging tools. It's going the other way that's the hard part. IE is completely unhelpful in diagnosing issues with document.addEventListener (a standard that IE doesn't support), or passing an event instead of using the stupid document.event, or showing you the DOM to find out where (or why) that specific DIV isn't showing up right.
Meh. Somebody needs to either fix IE, or take it out back and shoot it.
Javascript + Nintendo DSi = DSiCade
The title of the article should say "Migrate apps from Internet Explorer to Mozilla ... with valid business reasons". ... Might be easy to do so with small apps.. but with the size of the apps we've written for intranet based sites... there's no reason to make the switch to Mozilla. We simply tell our clients (who are all windows users anyway) to use IE. Not giving further choice means less headache for us when it comes to supporting our product.
_Vishal www.squad9.com
True developers test for compatibility.
Not if the requirements document says build this app for IE only and don't worry about interoperability.
Having server processes deliver content does nothing to eliminate browser compatibility issues.
These issues lie with the developer at heart, and the QA engineers. One needs to ensure compatibility at the unit-testing stage, having followed standards (as in the IBM article) in the design and coding stages...
Don't forget the cardinal rule of data validation: "Use javascript to make things work well for the user and server side validation to prevent hacks."
I pity the pour souls who were forced to use your "huge and widely used" web app that was compatible only with IE. It's clear you didn't do your homework before starting the project. ASP.NET web apps do not require having the .NET runtime on the client any more than PHP web apps require installing PHP on the client. (read: they don't)
.NET equivalent of browscap.ini). The default values stored in the machine.config basically only recognize 5.x+ versions of IE as "uplevel" browsers.
All of the native framework web controls have two distinct rendering modes. One is for "uplevel" browsers which includes any javascript/DHTML/etc. goodness that the latest browsers support. The other is for "downlevel" browsers and basically renders everything in something like HTML 3.2 compatibility. The server runtime detects which mode to use based on a section of the machine.config called browserCaps (essentially the
Updated versions of the browserCaps info can be found here:
http://www.codeproject.com/aspnet/browsercaps.asp
It should be noted you can choose to either replace the data in your machine.config to make it a system-wide update, or just add the same data to your app's web.config file.
On a related note, you can find an updated version of the original browscap.ini here:
http://www.garykeith.com/browsers/downloads.asp
Websites that require IE only are very unprofessional IMHO.
If I have to use IE to use a website, my opinion about the company's website I'm on is usually changed. In this day in age, you have to be proactive, not reactive.
Valkyrie is about to die! Wizard needs food -- badly!
Standards-compliant code works on all modern browsers,
Bwahahaha!
You obviously don't do professional web design. Getting the code to validate at W3C is the easy part!
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Don't rely on it, and don't dare trust it. Think of it as a service to your users. Oh, and add it on last, once the rest of the system works.
Client-side validation of a big long ugly form that the user has to submit along with, say, a few MBs of files - is a way of saying "We don't hate you, and don't want you to hate us".
Don't dare trust it though. Don't trust a damned thing - make no assumptions about the correctness of anything the client sends.
cyn, free software and *nix operating systems enthusiast.
Let's say you are implementing a feature and are faced with two approaches, the IE-only approach and the standards-compliant approach.
Even if you know your audience is IE users with no choice in browsers, it would still be unwise to choose the IE-only approach. You may be relying on some undocumented side-effect of IE that will get "fixed" in their next release/patch.
As an example, I had to support an app that provided a list of items as anchor tags. IE did not require the anchor tag to be closed since it would automatically close it on the next "</p>" tag. After upgrading to IE 5.5, this "feature" started causing stack overflow exceptions.
Most people, when they say "IE-specific" they actually mean "IE version x/windows verion y/service pack level z"-dependent.