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."

How about making server side only apps?

[dygital]

Apps should be made via server side processes eliminating the end user's browser to be compatible.

Or the other way around...

[Sebby]

Getting IE to confirm closer to Mozilla for CSS, there's always IE7 [edwards.name]

First rule of thumb

[d2_m_viant]

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.

innerHTML, the big enemy

[asapien]

Even though mozilla support innerHTML, its still the wrong thing to use. This is a valuable article because there are a lot of differences that can make things complicated, differences with DOM handling and limitations with IE. Sometimes it might be necessary to create a switch that will serve innerHTML to IE when it refuses to do DOMII correctly, esepcially creating and inserting nodes. But you still want to have it detect IE for that because Safari, Opera and Mozilla handle DOMII in a similar fashion, but I always have problems with IE.

Tried it with Mozilla about a year ago ....

[Jerry]

and it didn't work because IE could enter and display dollar amounts in text boxes, right justified, and Mozilla could not ... without a lot of javascript putzing. Even then, it never looked good or worked well. So, we abandon the idea.

Anyone try making a web page with right justified textboxes and have it run OK on Firefox?

Re:How about making server side only apps?

[rogueuk]

That's not always possible when you develop an app. If you want to minimize the number of post backs to a server, you might be using a lot of crazy javascript which may not be cross platform (like assuming IE's DOM instead of checking). If you are using display components that uses a lot of css/dhtml stuff that works "properly" in IE, chances are it may not be positioned properly in in Mozilla. (due to various fudge factors to get it to work the way you want in IE to begin with)

Re:How about making server side only apps?

[jellomizer]

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.

Re:Tried it with Mozilla about a year ago ....

[arkanes]

<input type="text" style="text-align: right">

This should have worked a year ago, too. Maybe not 2 years ago.

One of the best moves I made

[JPyObjC Dude]

Converted about 40,000 lines of JavaScript from IE to Mozilla 3 years ago and never am looking back.

Debugging JavaScript applications in Mozilla is a dream with error.stack and if necessary the Venkman JS debugger.

Great move for any developer to do as they will not only support more open structures but will also be more knowledgable of standards based programming. The latter helping those developers move around in their career as they would not be locked down to the blue e.

Another great reason to do this is that you could now hack your pages on a Mac without having to depend on the stupidities that are in the OSX MSIE with CSS, DOM and JS.

JsD

[ long live the moz ]

Re:ASP.NET

[Anonymous Coward]

Hmmm. I do not think that was your problem. ASP.NET will render HTML to the browser...some javascript for some controls. But it does not use the .NET framework on the client side.

Incorrect

[DaHat]

... 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.

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 .NET on the client is if you are hosting a .NET control in a web page similar to ActiveX.

Mistakes

[Linus Torvaalds]

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".

Missing - DevEdge Sidebar

[JPyObjC Dude]

Unfortunately, the IBM doc is missing a good description of the DevEdge sidebar which is available at:
http://lachy.id.au/dev/mozilla/sidebar/sidebar.xul [lachy.id.au]

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/ [oreilly.com]

JsD

Re:ASP.NET

[el_gordo101]

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

Incorrect. It does not use anything from the .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.

Material Possibly a little dated...

[jsight]

I saw this in the article:

Mozilla uses almost standards mode for the following conditions: ...
        * For the IBM doctype (<!DOCTYPE html SYSTEM "http://www.ibm.com/data/dtd/v11/ibmxhtml1-transit ional.dtd">)

This has not been true for quite a while. These days, the IBM doctype actually triggers "Quirks" mode, rather than "almost standards" mode.

innerHTML replacement

[vivin]

Righto. Also, the W3C doesn't support the innerHTML property.

innerHTML is the wrong way to go, especially in XHTML documents. That's because you can potentially insert badly formed XHTML into the document.

There is, however, a way to do it. I figured it out while trying to make my site XHTML valid. I've written about it [vivin.net] on my website. Please note that the site is currently down (problems with my ISP) but it should be back up soon today. Basically it involves parsing the code with the XML parser, and then importing the node into the DOM. My initial solution involved walking the parsed tree (which was a little more involved and longer/complicated). However, you can use the importNode function instead and just import the entire parsed DOM tree into the main document's tree. It works pretty well and ensures that the inserted code is valid XHTML.

Re:The forgot something...

[Lumpy]

so when your biggest client says " no we will not use IE as it is a security risk."

will you tell them to go away as you do not want their money?

because this is starting to happen. we did it here to a vendor who swore up and down that they cannot switch to support firefox, after our CTO called them and said, "we are going to have to no longer do business with you because of this" they magically lost the snotty attitude and started fixing their applications.

if you can afford to lose your biggest client, then by all means stay with what you have.

Re:ARGH slashdot ate my code. Here is it again.

[Anonymous Coward]

Use first-child selector from css2:

tr td:first-child
tr td:first-child + td + td ...

Re:Web Forms...

[Deinhard]

Well...it doesn't have all the functionality of Excel, but ActiveWidgets [activewidgets.com] does a good job.

Re:How about making server side only apps?

[CowboyBob500]

Javascripting is still needed to keep the interface working smoothly and un annoying.

No. There are two reasons why you should never rely on Javascript.

1) It's against disability accessibility regulations because it confuses screen readers (at least that's the case in the UK, I assume it's similar in the US). If you're doing a public sector project, it is forbidden (i.e. against the law) to use Javascript for anything that is visible. You want to do DHTML or "dynamic control of your controls", you have to use CSS.

2) It can be disabled. So it's pointless doing something like validation on the client side when you're going to have to do it on the server side anyway to keep the application robust.

Bob

IE

[Jim Haskell]

You're probably having trouble with addEventListener because IE doesn't support it. [quirksmode.org] As always, there's a proprietary solution, but it doesn't support capturing/bubbling like the W3C solution does.

You can half-ass it in IE with the traditional model (element.onclick = function;), but, y'know, it's half-assed.

Stick to the standards

[Anonymous Coward]

I recently did a web application which was both client -and serverside (AJAX, DHTML and PHP).
Right from the start I wrote valid XHTML and CSS as specified by W3C standards and in the end the application worked great in IE, Firefox and Safari.

Re:Not priter friendly

[rsadelle]

Mozilla and Firefox have a "Shrink to Fit Page Width" checkbox under Page Setup. IE does not.

Re:How about making server side only apps?

[turkeywrap]

Well put, but you forgot one important note: end users can turn off Javascript, rendering any error checking done client-side worthless.

Furthermore, malicious users can attack your site with handcrafted HTTP requests, so server-side security is of paramount importance. Here are a couple examples:

http://www.snort.org/pub-bin/sigs.cgi?sid=1080 [snort.org]

http://www.securiteam.com/securitynews/6S00O1561M. html [securiteam.com]

Here's the google search:
http://www.google.com/search?hs=hNY&hl=en&lr=&safe =off&client=firefox-a&rls=org.mozilla%3Aen-US%3Aof ficial&q=%22handcrafted+HTTP%22+request&btnG=Searc h [google.com]

Re:Windows authentication

[Anonymous Coward]

NTLM has been supported since 2003.

http://www.mozilla.org/projects/netlib/integrated- auth.html [mozilla.org]