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
A good first step would be to make browser-specific code compliant with W3C standards.
Standards-compliant code works on all modern browsers, and offers much greater accessibility than old, structure-less code.
"Ask not what your country can do for you." --John F. Kennedy
The most important rule for any web developer: seperate design from content
If you do this, then any adjustments needed to make another browser functional should be minimal, and shouldn't affect your application.
I often have to make my apps work in both, simply because I find the Firefox DOM inspector to be indispensable for tracking down screwey CSS behavior. It really hasn't been that tough to make the apps work in both IMHO.
True developers test for compatibility.
Not if the requirements document says build this app for IE only and don't worry about interoperability.
Being IE-specific is the mark of lack of foreseight. I speak from experience, unfortunately. To be cross-browser compatable between the latest versions of IE and mozilla is exceptionally simple if a little care is taken upfront. Unfortunately massive, hand-written, IE-specific sites are likely not worth the cost to rewrite. Consider your lesson learned and do it right NEXT time, forget porting.
IE has some advantages for businesses that have already standardized on using Windows, but for companies that aren't diehard supporters, why bother? The "debugger in IE," if you can even call it a debugger at all, is horrible as is the browser in general these days.
.NET development when you have free access to Visual Studio.
Any sane company that doesn't need the IE-specific features would be insane to not build on Mozilla with its excellent debugging tools and then test with standards-compliant browsers like Opera and then test with IE. IMO, build on IE first instead of using Firefox or Mozilla is akin to using Notepad and nAnt for Windows
Click here or a puppy gets stomped!
Yes and No.
While you should put the bulk of the processing server side. Javascripting is still needed to keep the interface working smoothly and un annoying. Example if you are filling in text boxes you want one to give the total as you enter in data. Vs. Forced screen reloads every data you type or having to hit a calculate button. Also dynmamic control of your controls making some controls enabled or not is very important to help the users use the program without putting in bad data.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
... ASP.NET only requires the .NET framework on the server side, for the actual generation of the pages. Remember, ASP.NET is not unlike PHP, Perl (when server side) and old school ASP, all dynamically generate pages on the server that are fed back to the client, and if a designer so wishes, they can tailor their pages to specific browsers and features.
.NET on the client is if you are hosting a .NET control in a web page similar to ActiveX.
Don't get me wrong though, ASP.NET generated pages do tend to work better IE as there are a number of added features that it can take advantage of (scripting, authentication, etc), however ASP.NET is designed to generate pages that are compatible with any modern browser, Firefox included. If you had issues getting your pages to work under browsers other than IE than you were running into issues created by the builder of the web page/application, not ASP.NET.
The only time you really require
Help Brendan pay off his student loans
Legacy browsers introduced tooltips into HTML by showing them on links and using the value of the alt attribute as a tooltip's content. The latest W3C HTML specification finally standardized tooltips, and uses the value of the new title attribute rather than the deprecated alt attribute. Mozilla will only show a tooltip for the title tag, per the specification.
This is wrong. Firstly, the alt attribute is not deprecated. In fact, it was optional in HTML 3.2 and required for all <img> elements in HTML 4 and newer.
Also, the title attribute isn't "for" tooltips, and the specification doesn't say that they should be displayed as such. The title attribute is for supplementary information, which can be displayed in the most appropriate manner for the circumstances. It just so happens that in most cases this is best accomplished with a tooltip, but that's merely incidental and not required behaviour.
Finally: it's the title attribute. The <title> tag is a completely different thing and does not work the way they describe.
The Javascript object detection versus browser detection bit was decent enough though. It's just a shame they used invalid code in the examples they gave. People will be copying these examples, so they only cause more invalid code to be written.
As far as using onload is concerned, you need to keep in mind that it only fires once all the parts of a page have been loaded - so, for example, if you have ads and the ad server is a bit slow, your onload element might fire thirty seconds after you think it should. This is a big deal when you are manipulating the page content - imagine typing something into an input control, only to have the onload set the focus to the control - in many browsers this will automatically select the text, which means you'll be typing away and suddenly the second half of what you are typing overwrites the first half.
Where such timing is a problem, you have no choice but to insert <script> elements directly after that part of the document you are manipulating. This won't change until browsers implement more load type events.
Last thing: the author should learn what a tag is and isn't. 98% of the time he says "tag", he means "element", 1% of the time he means "attribute", and 1% of the time he means "element type". I only skimmed the article, but I think I only saw once instance where he actually meant "tag".
Unfortunately, the IBM doc is missing a good description of the DevEdge sidebar which is available at:l
http://lachy.id.au/dev/mozilla/sidebar/sidebar.xu
DevEdge toolbar is the perfect tool to link to often buried resources on the w3c website. It is ok for JavaScript but that, a good book is always a good idea:
http://www.oreilly.com/catalog/jscript3/
JsD
I guess ASP.net uses the .net framework on client-side also making it impossible to make the app compatible with Firefox unless you get rid of .NET
.NET framework on the client-side. ASP.net simply produces a combination of HTML and JavaScript. Now, this HTML/JavaScript code that it produces may not be standards-compliant, therefore it may not work correctly in non-IE browsers. Within the Visual Studio IDE you can select which browsers you wish to code for using the targetSchema property within your aspx page, but this doesn't work very well. If your application did not work correctly in other browsers, it is because it was coded poorly, or you used some of the ASP.net controls that don't work very well in other browsers, such as the form validation controls.
Incorrect. It does not use anything from the
TODO: Insert witty sig
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
Why should I make the sever process this.
Javascript has plenty of uses, but relying only on client-side code to validate data is a recipe for disaster.
On the server side, it's usually an extremely simple action to check the validity of the data.
The server MUST have functions to check for data integrity.
You should also enforce the rules in the database.
If you rely on the client to do all this, you'll need to deal with buggy clients, or people who copy your page, create their own cracked version of the page, and use the cracked version to screw with your server.
There's plenty of use for client-side javascript, but you shouldn't use it as an excuse to exclude server-side security.
94% of Repubs and 21% of Dems voted to renew the Patriot Act
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!
You should buy a wider printer.
XML causes global warming.