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