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."
If you want to hear about my own personal attempt to migrate the company webapp to firefox. Haha.
AC comments get piped to
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
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.
"Ask not what your country can do for you." --John F. Kennedy
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.
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.
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.
_Vishal www.squad9.com
True developers test for compatibility.
Not if the requirements document says build this app for IE only and don't worry about interoperability.
No, no matter how much I love RoR, this is just fanboyism. RoR is server-side, XHTML, css and cross-browser compatible javascript is the answer.
I agree, but a large reason that some developers didn't use server-side code was that it was claimed (rightly so or not) that it took longer to get a result. Now, on the other hand, we can use technologies that like AJAX to speed up the process of getting certain pieces of data back. Now, it's a matter of people putting it all together.
Perfecting Discordia
www.stevenvansickle.com
Having server processes deliver content does nothing to eliminate browser compatibility issues.
These issues lie with the developer at heart, and the QA engineers. One needs to ensure compatibility at the unit-testing stage, having followed standards (as in the IBM article) in the design and coding stages...
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.
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)
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.
.NET development when you have free access to Visual Studio.
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
Click here or a puppy gets stomped!
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.
It all depends on the target audience. If the company is making Windows only software, then they never had to test something on Safari or IE 5.2(mac). Some companies, also, don't see a point in catering to those that aren't in the majority. If the loss of one or two users that use non-IE browsers is negligible at the time, then why waste the money on cross-platform testing? Too many businesses run thier web sites like a democracy: 3 wolves and 1 sheep voting on what to have for lunch. Mob wins.
On the other hand, if IE starts falling out of power, then some companies may regret those poor choices, and some already are.
Perfecting Discordia
www.stevenvansickle.com
This should have worked a year ago, too. Maybe not 2 years ago.
The part that is visible is http://goat.
It covers basic cross-browser development techniques, and some developing strategies for overcoming the differences between both browsers.
Country and western?
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
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
Supplies!
... 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
It's called the W3C.
Sadly, despite the W3C's efforts, it seems that the Browser Pissing Contest rages on.
"Ask not what your country can do for you." --John F. Kennedy
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 for functional changes.
-- Tigger warning: This post may contain tiggers! --
Don't forget the cardinal rule of data validation: "Use javascript to make things work well for the user and server side validation to prevent hacks."
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
Stop spreading misinformation. ASP.Net runs within .Net on the server side and does not use .Net on the client side. It only uses javascript, etc... on the client side. I believe it does do some optimizations if it detects the client is IE.
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.
Sig free since 2/6/2002
Right! Web applications should be thought of as three tiered client server appications. As such, any processing you can do client side, should be done there. It makes no sense to wait until the data has been sent to the server to throw an error for a required field. The client knows whether the field is NULL or not. Why should I make the sever process this. Besides, passing processing off to the client makes the entire application more robust. There is only one server, but there is an unlimited amount of procsessing distributed among the clients.
Insert Generic Sig Here:
Agreed, but you can still do server-side processing via javascript (I think it's called AJAX) instead of forcing reloads on the page. For simple things like adding a total you'd probably just keep it javascript, but for more complicated things you can use basic javascript to go to the server for more complicated processing instead of worrying about browser compatabilities. Google does a lot of it, like with Google Suggest. Try it out, just start typing something in the search box, and the page will send what you're typing back to google's server via javascript and the server processes that information and returns suggestions which are then displayed on the page in real time again with javascript. This wouldn't be possible without the server doing the work, but the page never needs to reload.
I pity the pour souls who were forced to use your "huge and widely used" web app that was compatible only with IE. It's clear you didn't do your homework before starting the project. ASP.NET web apps do not require having the .NET runtime on the client any more than PHP web apps require installing PHP on the client. (read: they don't)
.NET equivalent of browscap.ini). The default values stored in the machine.config basically only recognize 5.x+ versions of IE as "uplevel" browsers.
All of the native framework web controls have two distinct rendering modes. One is for "uplevel" browsers which includes any javascript/DHTML/etc. goodness that the latest browsers support. The other is for "downlevel" browsers and basically renders everything in something like HTML 3.2 compatibility. The server runtime detects which mode to use based on a section of the machine.config called browserCaps (essentially the
Updated versions of the browserCaps info can be found here:
http://www.codeproject.com/aspnet/browsercaps.asp
It should be noted you can choose to either replace the data in your machine.config to make it a system-wide update, or just add the same data to your app's web.config file.
On a related note, you can find an updated version of the original browscap.ini here:
http://www.garykeith.com/browsers/downloads.asp
On it's way out? Do tell, where are you getting this from as in my experience .NET is one of the greatest things since sliced bread when it comes to coding windows or web based applications.
Help Brendan pay off his student loans
A good developer will recognise that the requirements doc is tremendously short-sighted, and code for compatability anyway. He'll save the customer a surprising amount of money when they inevitably decide to support Firefox after all, though no-one will realise this.
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!
A punch card web app? Why stop there?
I want a steam driven, coal powered web server which is programmed via punch cards and renders it's output via a ticker tape machine being driven by a hamster wheel.
This is my sig. There are many like it but this one is mine.
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
Why should I make the sever process this.
Javascript has plenty of uses, but relying only on client-side code to validate data is a recipe for disaster.
On the server side, it's usually an extremely simple action to check the validity of the data.
The server MUST have functions to check for data integrity.
You should also enforce the rules in the database.
If you rely on the client to do all this, you'll need to deal with buggy clients, or people who copy your page, create their own cracked version of the page, and use the cracked version to screw with your server.
There's plenty of use for client-side javascript, but you shouldn't use it as an excuse to exclude server-side security.
94% of Repubs and 21% of Dems voted to renew the Patriot Act
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.
Valkyrie is about to die! Wizard needs food -- badly!
Besides, passing processing off to the client makes the entire application more robust. There is only one server, but there is an unlimited amount of procsessing distributed among the clients.
And an unlimited amount of dodgyness. It doesn't make the application more robust at all but it might give a better user experience.
Any validation the client does MUST also be performed at the server end because
(1) How do you know the client DID validate it
(2) correctly
for some ill specified and overly cached version of "correctness"
Sam
blog.sam.liddicott.com
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.
--
make install -not war
Actually, his position is not unreasonable, although he did state it in an undiplomatic fashion. I, personally, do not and will not connect to the internet (or even the local net) with MSIE installed on my computer. I consider it excessively dangerous. So if I cannot test or use the proposed application, I would not be willing to do business with them. If I had to go to a special computer that was specifically isolated from the rest of our network for security reasons to use their applications... well, it had better be an important application that I won't need to use very often.
I have not yet been able to ensure that the others that I work with do not have MSIE installed, but that is one of my goals. In furtherance of this goal, I will not suggest any application vendor that I know provides MSIE only applications. And I will not recommend any MSIE application. And I will recommend against the purchase of or use of any such application. (This doesn't mean that I'll always come right out and say why I'm against the application. Those who know me well will know my attitude towards MSIE, and they will need little explanation. For others, I'll find some easier to understand reason that is also correct..or I'll be silent...but security issues are almost always present, if I can't find any other valid reasons. A better approach, when there is time, is to come up with a competing product that I find superior.)
I consider MSIE to be a security nightmare, and we will have as little to do with it as I can manage.
I think we've pushed this "anyone can grow up to be president" thing too far.
It's not hard to code cross platform. Developers are just lazy. If web developers stuck to W3C standards than this wouldn't even be an issue. If game developers used OpenGL instead of DirectX than it would trivial to port games between platforms. And so forth.
Use first-child selector from css2:
...
tr td:first-child
tr td:first-child + td + td
The problem arises when you depend on proprietary extensions.
Also, based on your argument, what do you consider an acceptable loss from potential sales revenue? Do you consider excluding 10% of the market to be acceptable? What if that 10% had a large chunk of disposable income and would be more likely to buy your product? Just because the "majority" uses IE doesn't mean it's right to exclude the minority who choose not to or cannot.
If anyone's being moronic, it's you.
OCO is Loco
lol, reminds me of a non-developer friend who on Tuesday was asked to learn asp.net and build the company's web site by Monday.
I got an email with the subject, "help!"
The global economy is a great thing until you feel it locally.
Javascript has plenty of uses, but relying only on client-side code to validate data is a recipe for disaster.
Yes and no. If that is your only method for validating data, yes it is a recipe for disaster. However it can be very handy to validate data before a form is posted to make it easier to alert the user. Of course the server side componants should also validate what they receive as you state. A good three tier design needs to check validity on all three tiers.
I use a lot of javascript to make the UI cleaner (usually simple scripts), to make small changes to objects without having to reload a large page, and to validate form data before it is submitted. Since this is a company internal site I have the advantage of a limited number of browsers, nearly 50/50 between IE and Mozilla. Under these circumstances I can make use of javascript to a much greater extent than if I were creating a public face.
Sig is on vacation
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.
There is only one server
...only one who can bend it to his will, and Bill Gates does not share power.
"All great things are simple & expressed in a single word: freedom, justice, honor, duty, mercy, hope." --Churchill
Not when we have $$$ to spend. I do, and if your site won't let my browser through, you lost a customer.
It's also a good harbinger of how good their customer support is in general, I've found.
I would also point out that the ones with the small "world view" are the ones supporting only one browser.
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
Listen to my latest album here
You guys actually get, like, a real.... document? Like with writing in it, describing in some detail what people actually want?
I thought they were myths.
Where I work, people's minds change, sometimes on a weekly or even daily basis. Sometimes it's a good idea to plan ahead to be able to keep up with those changes.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
This is a blantantly uninformted opinion. .NET is anything BUT going away. Heck, the new .Net framework 2.0 is out November 7th, VS.Net 2005 (and it's "express" counterparts), VWD 2005, SQL Server 2005 in the same time frame (some the same day).
This brings us ASP.Net 2.0, which is so much of an improvement over the old ASP.Net, it's just amazing. Honestly I didn't care much for ASP.Net until I tried v2.0. It amazed me FAR more than everything else I've seen (like RoR, Zope, Plone, etc). Its good enough that I don't even wanna use anything else anymore (asp/php/whatever? no thanks!)
It's anything but deprecated/on it's way out or being replaced by something better (much the inverse - other platforms are adopting it - ever heard of Mono? I guess not.). It's currently THE best platform to develop for (web wise) and that has the best tools (VS.Net 2005 rocks).
See for yourself!
Clearly, you have no idea at all about all this. No wonder you posted as AC.
///<sig
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?
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.
IE compared to Firefox plus some web development specific extensions (webdevelopper, html debugger, javascript debugger ) is like notepad vs Vim. And my experience is that web application developped with firefox generally works very well in IE, but not the contrary.
Don't rely on it, and don't dare trust it. Think of it as a service to your users. Oh, and add it on last, once the rest of the system works.
Client-side validation of a big long ugly form that the user has to submit along with, say, a few MBs of files - is a way of saying "We don't hate you, and don't want you to hate us".
Don't dare trust it though. Don't trust a damned thing - make no assumptions about the correctness of anything the client sends.
cyn, free software and *nix operating systems enthusiast.
I don't think M$ is dumb enough to break IE5/6
LOL!
OK, you owe me a new keyboard, as it's now covered with soda.
I'm remembering the problems I've had when I was working with IntraLearn, and the way it broke when going from IE 5.5 to IE 6.0, and how stock 6.0 worked but the latest Service Pack didn't. I ended up decrypting their damn Cold Fusion code and fixing it myself.
IE breaks a lot of things between versions. I've come to the conclusion that the IE developers at Microsoft just can't keep things working form one version to the next. Hell, I've even seen small security patches break sites.
Ever try to open up an HTML file generated by Powerpoint 95 in IE 6.0 SP2? In Windows 2000? It's a disaster, and half the links don't work, and that's using nothing but Microsoft products. Because it looked fine on IE 5.5, and the company owner was running IE 5.5, he concluded that it must be fine, and I was the one who was chewed out when it didn't work for the sales guy who did a demo on W2K running the latest IE.
"Live Free or Die." Don't like it? Then keep out of the USA
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.
Let's say you are implementing a feature and are faced with two approaches, the IE-only approach and the standards-compliant approach.
Even if you know your audience is IE users with no choice in browsers, it would still be unwise to choose the IE-only approach. You may be relying on some undocumented side-effect of IE that will get "fixed" in their next release/patch.
As an example, I had to support an app that provided a list of items as anchor tags. IE did not require the anchor tag to be closed since it would automatically close it on the next "</p>" tag. After upgrading to IE 5.5, this "feature" started causing stack overflow exceptions.
Most people, when they say "IE-specific" they actually mean "IE version x/windows verion y/service pack level z"-dependent.
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)
I saw an implementation of a website that ran against an application on an NT which connected to a mainframe which then ran batch COBOL to generate reports, ship them back to the NT server, formatted via PHP and into peoples browsers.
On the internet, no one knows you're a mainframe...
putting the 'B' in LGBTQ+
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.
I've spent the past few weeks porting code from Firefox to IE. It's been hell. I need to find the location of user-selected text in the document: Firefox supports (mostly) the W3C Range object, which provides a DOM node and offset, but IE's proprietary implementation provides only the pixel location (!). I tried using a trick with copy & paste to locate it, but when IE provides the content of the selection it tries to be clever: it adds tags. It also adds tags when you paste. So if you copy the selection and paste it right back where it came from, you'll get a broken document!
Both browsers also corrupt whitespace. The Firefox DOM collapses multiple spaces in a text node to a single space (sort-of - they're also still there, which is very puzzling). The IE implementation goes one step further and collapses spaces across element boundaries. So, for example, a leading space following a start or end tag may vanish (or not, depending on whether it preceded by whitespace). It also inserts newlines following tags for block elements. Oh yeah, and it capitalizes tag names and drops some close tags while it's at.
One more appalling bug: the DOM normalize function in IE crashes the browser. But only sometimes.
I've solved my problems, but it has taken longer than it did to get the whole system working in Firefox in the first place. (It's a web annotation system that allows for highlighting and margin comments for arbitrary HTML - I need to find the selection when the user creates a highlight.) The world would be a better place if IE crawled off and died.
Yeah- it's a very big 'can`t we all just get along' comment. I'll admit it.
I guess the comment is just trying to point out that there is no BENEFIT to not keeping to the standard and setting it. If they want to do something other than what W3c says, why not suggest it and let everyone adopt it or provide better solutions- as another pointed out, this is what w3c is for.
And you think people will listen? HA! Who cares? For the user, IE displays pages fine, so why would a user care about such technical detail of making it right? As long as 10-95% of people are using IE (yes- that means until eternity), people will make their pages compatible for it, so end users will never notice the difference, and never care what some hippie spouting open-source thinks. So no bank or major site is going to let their pages look horrible in IE due to some code changes, so they'll update it.
And M$ will say that IE is better for A B and C. And then you have a bit war. If there was a right answer, we wouldn't be having this discussion. If there was a superior OS in every way, we wouldn't need two... but each has it's advantages and market.
-M
when you see the word 'Linux', drink!
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
For those that don't know- you can develop web ASP.net applications that leverage 3 types of authentication- Forms, Windows and Passport. Forms and Passport will work for all browsers. Passport authentication costs a lotta $$$ so you only see it on MS sites and large commerce sites like Expedia. Forms is the simple authentication that every browser will render- it requires you to write custom code to handle authentication. This means your code needs to do work like checking a password file, looking into a database, etc. You'll also need to write code that meets your company's security policies. It adds a lot of time and expense to application development. Windows authentication uses your Active Directory session- none of the custom code in forms authentication is necessary. You just set the acls on the directory of the app, and as long as the user is logged into the domain and their group has access permissions, the domain handles authentication and authorization issues. No worrying about password complexity algorithms, password aging or user account management. You save cash and you ensure that security requirements are applied consistently.
Single sign-on (in this instance, windows authentication asp.net apps) solves a significant number of organizational security problems. Reducing inconsistency in password complexity, password aging, access management, etc, should be a primary goal in business web applications. This is an instance where IE only solutions are better than Netscape, Mozilla & Firefox apps. This article is missing the only reference that is really necessary- how can I offload my security concerns into a single clearinghouse with Firefox/Netscape/Mozilla. If someone does a samba like project to figure out how to kludge in Windows Authentication into the other browsers, then this article will be complete.
I'm sticking with I.E. only solutions for Intranet business applications because it contributes to centralized security.
Look at the IE addressbar (which is truncated) in this picture.
Makes you say "Hmmmmm..."