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."
Apps should be made via server side processes eliminating the end user's browser to be compatible.
AC comments get piped to
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.
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.
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?
Running with Linux for over 20 years!
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 ]
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.
... 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
This has not been true for quite a while. These days, the IBM doctype actually triggers "Quirks" mode, rather than "almost standards" mode.
Throw the bums out!
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 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.
Vivin Suresh Paliath
http://vivin.net
I like
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.
Do not look at laser with remaining good eye.
Use first-child selector from css2:
...
tr td:first-child
tr td:first-child + td + td
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.
You're probably having trouble with addEventListener because IE doesn't support it. 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.
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.
Mozilla and Firefox have a "Shrink to Fit Page Width" checkbox under Page Setup. IE does not.
NTLM has been supported since 2003.
- auth.html
http://www.mozilla.org/projects/netlib/integrated