Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Internet Explorer Mozilla The Internet

Migrating IE Web Apps to Mozilla 407

Posted by Hemos from the moving-it-over dept.
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."
This discussion has been archived. No new comments can be posted.

Migrating IE Web Apps to Mozilla More

Migrating IE Web Apps to Mozilla

Comments Filter:
  • If you want to hear about my own personal attempt to migrate the company webapp to firefox. Haha.

  • Or the other way around... (Score:3, Informative)

    by Sebby ( 238625 ) on Wednesday July 27, 2005 @01:46PM (#13177833)
    Getting IE to confirm closer to Mozilla for CSS, there's always IE7 [edwards.name]

    • Yeah it makes sense if your enterprise distribution is Win2k - Nothing like re-imaging 1000+ computers with XP to run IE7.

      I'd rather have the web-developers chained in the burn room and have them perform the imaging to show them what they've accomplished by making IE only pages.
      • Nothing like re-imaging 1000+ computers with XP to run IE7.

        Nothing like... doing your... job???

        Seriously... Why do IT people stonewall all patches and software upgrades? I've seen IT people running versions of apache with security holes because they need to "validate" the next upgrade. In the meantime they are vulnerable to attack.

        Good gawd people, give it up! I know upgrading servers and workstations is a pain, but that's your job!!!
      • Yeah it makes sense if your enterprise distribution is Win2k - Nothing like re-imaging 1000+ computers with XP to run IE7


        IE7 [edwards.name] (in this context) is NOT an updated version of IE, check out the link.

  • That's Easy! (Score:5, Insightful)

    by AKAImBatman ( 238306 ) * <akaimbatman AT gmail DOT com> on Wednesday July 27, 2005 @01:47PM (#13177838) Homepage Journal
    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.

  • First stop: W3C standards (Score:4, Funny)

    by goldspider ( 445116 ) on Wednesday July 27, 2005 @01:47PM (#13177846) Homepage
    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.

  • First rule of thumb (Score:5, Informative)

    by d2_m_viant ( 811261 ) on Wednesday July 27, 2005 @01:47PM (#13177849)
    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.

  • ObDuh strategy 101 (Score:2, Insightful)

    by Travoltus ( 110240 )
    It's wise to free your web based product from proprietary stuff like MSIE. That way if MicroSoft turns on you, so what? Life carries on.
  • 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, bu

    • innerHTML replacement (Score:3, Informative)

      by vivin ( 671928 )
      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 imp
    • While I agree with that modifying the DOM tree is always better than using innerHTML there are important performance differences.

      For a recent project some initial tests showed that (especially on IE) generating an HTML string (preferrable building the string into an array and getting the result string with array.join('')), was 100-1000 times (!) faster than modifying the DOM tree. Marking the difference between something that works and something that's unusable.

  • Firefox tools (Score:5, Interesting)

    by coflow ( 519578 ) on Wednesday July 27, 2005 @01:48PM (#13177865)
    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.
    • I do the same thing. The development tools available in Firefox are valuable enough that it's worth the (usually minor) futzing I have to do. EditCSS alone is worth the effort. The only time it's really annoying is when I get some CSS working just right in FF and then IE completely screws it up.

      The only feature that I find desirable in IE that I can't implement in Firefox/Mozilla is the ability to show modal & non-modal dialogs. These can be very handy for certain types of async behavior, and are much

    • ``It really hasn't been that tough to make the apps work in both IMHO.''

      But that's different from, and a lot easier than, changing apps that contain lots of IE-specific code so that they'll work on Firefox. If you develop the code for both right from the start, you write the right code once, and don't do things that can't be done in both browsers.

      My prefered solution is to Keep It Small and Simple, and just make web interfaces that work pretty much no matter which browser you use with them.

  • The forgot something... (Score:3, Insightful)

    by pickyouupatnine ( 901260 ) on Wednesday July 27, 2005 @01:49PM (#13177872) Homepage
    The title of the article should say "Migrate apps from Internet Explorer to Mozilla ... with valid business reasons". ... Might be easy to do so with small apps.. but with the size of the apps we've written for intranet based sites... there's no reason to make the switch to Mozilla. We simply tell our clients (who are all windows users anyway) to use IE. Not giving further choice means less headache for us when it comes to supporting our product.

    • Re:The forgot something... (Score:4, Insightful)

      by Anonymous Coward on Wednesday July 27, 2005 @01:53PM (#13177929)
      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.
    • Unfortunately for us all, this attitude is very common. My approach is quite the opposite: code to the standards so it works/looks correct in FF (or other mostly-standards-compliant browsers), give it basic functionality in IE and if an IE user complains about it not being perfect tell them to use a proper browser.

      Obviously, when doing work for the company I have to be careful and make things look at least reasonably proper in IE (for which the IE7 javascript library has been a lifesaver). However, for my

    • We simply tell our clients (who are all windows users anyway) to use IE.

      What do you do when IE is banned company-wide for security reasons (as it has been with several of our clients) or when the government agency you are trying to sell to says, "our security group is all on OS X, we need it to work in both Safari and Firefox?" What market are you selling to that you have not run into one of these two problems and what makes you think that market will stay so technologically backwards?

    • Re:The forgot something... (Score:4, Insightful)

      by Leebert ( 1694 ) on Wednesday July 27, 2005 @02:42PM (#13178475)
      We simply tell our clients (who are all windows users anyway) to use IE. Not giving further choice means less headache for us when it comes to supporting our product.

      That's a perfectly acceptable position to take. As long as your competitors take the same position, that is.
    • 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, the

  • Or you can use XUL (Score:4, Funny)

    by bahwi ( 43111 ) on Wednesday July 27, 2005 @01:52PM (#13177908)
    Or you can use XUL and make it Mozilla/FireFox only.

    Until XulRunner comes out that is, then you can almost detatch it from the web.
  • ...

    No matter how standards-noncompliant this snippet is, at the office we use this a lot. Any ideas?

  • And why would most use IE anyway? (Score:5, Interesting)

    by ShatteredDream ( 636520 ) on Wednesday July 27, 2005 @01:55PM (#13177952) Homepage
    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.

    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 .NET development when you have free access to Visual Studio.

    • What I have trouble understanding is building an app fully and solely for IE.

      I can understand if one actually needs IE-specific features, but then those should be built in modularly, so that when more browser support that kind of feature, it can be broadened.

      We're stuck with some Windows-only items, and it is extremely frustrating because we continue to need to buy Windows licenses to put IE on machine for people to use these apps, when the VAST majority of our users have NO NEED whatsoever to have Window

  • I'm shocked, shocked (Score:4, Funny)

    by Crispy Critters ( 226798 ) on Wednesday July 27, 2005 @02:00PM (#13178023)
    Notice that one of the figures has a browser with an address box shrunk down to reveal only part of the URL.

    The part that is visible is http://goat.

    • The part that is visible is "http://goat"

      I saw that too, in the section describing how IE behaves badly with overflowing <div>s. Thank goodness that's the *only* part that's visible. If there were one thing I'd have surgically removed from my memory...

  • Both browsers (Score:3, Funny)

    by HTH NE1 ( 675604 ) on Wednesday July 27, 2005 @02:01PM (#13178037)
    It covers basic cross-browser development techniques, and some developing strategies for overcoming the differences between both browsers.

    Country and western?
    • I think someone's been watching Blues Brothers once too often. :)
    • It covers basic cross-browser development techniques, and some developing strategies for overcoming the differences between both browsers.

      Country and western?

      A but oversensitive, are we?

      The article is about porting an IE-based web app to Mozilla-based browsers.

      Would you write an article comparing Mac OS X to Windows XP, then spend a paragraph talking about FreeBSD? If so, I hope you've got a good editor...
  • Lets talk seriously for a moment. Why are there IE only extensions on an open standard? Why are there Mozilla-only objects, ways of doing things, formatting problems, etc?

    It's because everyone is trying to stand their ground and provide something specific to their purpose.

    Get Mozilla/Netscape, Opera, Microsoft, etc all in one room and decide on a standard. Everyone has to give in, nobody is right or wrong... and make it stick. -OR- if you can't, include 100% compatibility for the other person's idea.

    Th

    • Already been done (Score:2, Insightful)

      by goldspider ( 445116 )
      "Get Mozilla/Netscape, Opera, Microsoft, etc all in one room and decide on a standard."

      It's called the W3C [w3c.org].

      Sadly, despite the W3C's efforts, it seems that the Browser Pissing Contest rages on.

  • One of the best moves I made (Score:3, Informative)

    by JPyObjC Dude ( 772176 ) on Wednesday July 27, 2005 @02:04PM (#13178060)
    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 ]
  • and get iNotes to work better in firefox

  • Mistakes (Score:5, Informative)

    by Linus Torvaalds ( 876626 ) on Wednesday July 27, 2005 @02:08PM (#13178110)

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

  • some of the code examples show how to make it browser-independent and specifically show cases and code for allowing Netscape, Firefox, and Opera all to work with previously IE-specific code.

    But, in general, it's a fairly good doc.

    I enjoy the part about not sniffing the useragent to make it version specific when that may make it so that you have to upgrade the code when a new version comes out, even though the behaviour hasn't changed - which means less revisions just for incrementalism, and more revisions f

  • Missing - DevEdge Sidebar (Score:5, Informative)

    by JPyObjC Dude ( 772176 ) on Wednesday July 27, 2005 @02:13PM (#13178165)
    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

  • Not priter friendly (Score:3, Interesting)

    by WMNelis ( 112548 ) <wmnelis@MONETyahoo.com minus painter> on Wednesday July 27, 2005 @02:15PM (#13178182) Homepage
    I find it interesting that an article about creating cross browser web pages does not print out properly from Firefox. The right side of some text gets cut off.

  • Material Possibly a little dated... (Score:3, Informative)

    by jsight ( 8987 ) on Wednesday July 27, 2005 @02:32PM (#13178362) Homepage
    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.

  • IE only is unprofessional (Score:4, Insightful)

    by hexed_2050 ( 841538 ) on Wednesday July 27, 2005 @02:42PM (#13178482)
    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.

  • Automigration (Score:3, Interesting)

    by Doc Ruby ( 173196 ) on Wednesday July 27, 2005 @02:45PM (#13178525) Homepage Journal
    I'd love to see IBM bundle their Eclipse IDE with tools that convert IE-only (or Netscape/Mozilla/Firefox-only, for that matter) code to truly cross-browser code. Automated conversion. They've got the manpower and other resources, including global human testers. And the more productive is this "migration" program, the more money IBM makes selling hardware and services to the defragmented market.

  • What I'd really like... (Score:3, Interesting)

    by dghcasp ( 459766 ) on Wednesday July 27, 2005 @03:36PM (#13179040)
    What I'd really like is a tool that I can point at a web page and have it TELL ME what problems I can expect.

    For example: You have used a div with stylesheet ID "X" having attribute 'clear: both', and then followed that with another div. This will probably display incorrectly on IE5.x on Macintosh, because it incorrectly uses lexical instead of block scoping for the clear attribute on boxes.

    I'd pay money for that. Anyone want a new project?

  • Stick to the standards (Score:3, Informative)

    by Anonymous Coward on Wednesday July 27, 2005 @04:17PM (#13179470)
    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.

  • DA DORON ROSENBERG (Score:3, Funny)

    by Anonymous Coward on Wednesday July 27, 2005 @04:33PM (#13179669)
    DA DORON ROSENBERG

    Migrate apps from IE to Mozilla
    Da doo ron ron ron, da Doron Rosenberg
    Someboy told me that the fight was uphill
    Da doo ron ron ron, da Doron Rosenberg

          Yes, the fight was uphill
          Yes, I'm in love with the 'Zill
          And when I write that code
          Da doo ron ron ron, da Doron Rosenberg

    ActiveX controls are the work of the beast
    Da doo ron ron ron, da Doron Rosenberg
    Migrate apps from IE to Mozilla
    Da doo ron ron ron, da Doron Rosenberg

          Yes, the fight was uphill
          Yes, I'm in love with the 'Zill
          And when I write that code
          Da doo ron ron ron, da Doron Rosenberg

    Well, I'm Internet Explorer-free and it feels so fine
    Da doo ron ron ron, da Doron Rosenberg
    BillG's pissed and that's just fine
    Da doo ron ron ron, da Doron Rosenberg

          Yes, it runs so fine
          Yes, I've made it mine
          And when I write that code
          Da doo ron ron ron, da Doron Rosenberg
          Yeah, yeah, yeah
          Da doo ron ron ron, da Doron Rosenberg
          (repeat & fade)

  • maybe we should fix it ourselves (Score:3, Interesting)

    by cahiha ( 873942 ) on Wednesday July 27, 2005 @04:51PM (#13179914)
    It's good when people fix problems in their web apps. But, realistically, a lot of companies aren't going to bother; touching large amounts of old code is a dangerous and costly proposition.

    I think the solution is a different one. Greasemonkey has already been used for the purpose of fixing IE-only problems, and it's relatively easy to write new scripts that patch up problems in IE-based web apps. I think that's the path towards helping making Firefox an even better replacement for IE.

    Of course, Greasemonkey itself isn't mature and has problems. The recently discovered security problems are serious but fixable.

    More important is that Greasemonkey scripts may be too much trouble to install right now for deployment. Greasemonkey would be greatly enhanced if it could be set up to access script repositories through http and/or WebDAV. That way, intranet administrators could point their users' Firefox browsers at a secure, internal Greasemonkey script repository and add fixes as they encounter them.

  • What webpage were they trying to view? (Score:3, Funny)

    by bugnuts ( 94678 ) on Wednesday July 27, 2005 @06:34PM (#13180879) Journal
    Look at the IE addressbar (which is truncated) in this picture. [ibm.com]

    Makes you say "Hmmmmm..."

Slashdot Top Deals

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Close