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."
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.
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)
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
Well...it doesn't have all the functionality of Excel, but ActiveWidgets does a good job.
Successfully condensing fact from the vapor of nuance since 1998.
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.
Well put, but you forgot one important note: end users can turn off Javascript, rendering any error checking done client-side worthless.
. html
e =off&client=firefox-a&rls=org.mozilla%3Aen-US%3Aof ficial&q=%22handcrafted+HTTP%22+request&btnG=Searc h
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
http://www.securiteam.com/securitynews/6S00O1561M
Here's the google search:
http://www.google.com/search?hs=hNY&hl=en&lr=&saf