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."
Don't anthropomorphize computers: they hate that.
Apps should be made via server side processes eliminating the end user's browser to be compatible.
I wouldn't call them developers if they develop a web app just for IE. True developers test for compatibility.
What does your Credit Report look like?
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.
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.
--- Grow a pair, liberals... stop letting the Republicans bully you!
Not too sure about this but.. .net framework on client-side also making it impossible to make the app compatible with Firefox unless you get rid of .NET
I had a huge and widely used webapp developed in ASP.NET and compatible only with IE. I guess ASP.net uses the
What does your Credit Report look like?
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
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.
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!
Get over yourself.
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?
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!
<colgroup>
<col style="padding-left:4em;font:bold 8px Arial,Sans-serif;background-color:#CCF"
<col
</colgroup>
</table>
So, how to implement this in mozilla?
To me, the main advantage of IE web apps is complex forms and form actions / processing that can be accomplished with ActiveX widgets combined with VB and VB Script. Widespread adoption of a standard and rich web forms technology would eliminate much of the need for IE dependent web app technologies.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Sorry, but I see that guy's name everytime there's a Mozilla mention. Oh, and congrats to the developers that are porting to Mozilla; it will be a great day when *any* web user can use all webapps. (personally I see a promising future in AJAX) http://www.adaptivepath.com/publications/essays/ar chives/000385.php
bad_outlook
--
Is this vague enough for you?
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?
for pointing this out. My huge defense contracting employer is so hopelessly in bed with Microsoft that I can only use I.E. Even to do such routine things as turn in my time sheets, ActiveX is required. the customers are smarter and don't run anything but Mozilla on their LAN. Make's my life a constant pain in the ass. I am forwarding TFA to our co.'s IT dept.
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.
The Internet community builds itself on respect and compromise- ensuring the most imformation and availability to the masses. Lets once and for all come up with a mediated standard and everyone agree that the Internet would be a better place if developers just had things work properly.
The browser is to be the INTERFACE to connecting to content, and hence should connect to all content and display it in the same way.
I guess I'm just tired of everyone doing their own thing.
BTW: This is different than Linux distros and other situations. I could say the same with the hundreds of Linux distributions, but each of those have different target markets. In contrast, the browser is intended for anyone, and the CONTENT is what has the target market.. The content should always display and work the same. Everyone give in a little.
-M
when you see the word 'Linux', drink!
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 ]
I'm sure, with your small World View and asinine opinion, you are not in any position to "do business" with them anyway. Generally, code monkeys like you are LOW on the totem poll.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
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".
For migrating to Opera, follow the standards.
;)
Then make some coffee
Nicolas Mendoza
Prepare for MSIE 7
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! --
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
IBM makes INotes which is the worst web app i know, sloooww slooow slooow and I can't get it to work in Firefox although may be some better implementation of iNotes does work on it.
Mac toys and accessories blog
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
What serious developer would still want to use .NET? The .NET framework is on the way out and has made space to more powerful, portable, and easy to develop for frameworks.
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
(1) Check your pages with a validator.
(2) Fix the things that the validator says are broken.
Voila, cross-browser app.
Aren't there -international, non-proprietary standards-?
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!
The web interface of Lotus Notes is IE-only. I found it hilarious that IBM is telling people how to migrate from IE-only to firefox when they haven't done it themselves.
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
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!
Or a more current version:
http://www.oreilly.com/catalog/jscript4/
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
Your comments are right on the money.
-kgj
-kgj
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.
var foo = (condition) ? conditionIsTrue : conditionIsFalse;
Since when should terse programming be advocated like this? Give me a break. I thought programmers were aware of the fact that terse statements only serve to complicate code readability and should not be used. There are acceptable uses of terse syntax (the ++ increment operator, for example), but the ternary operator has never been one of them.
For he today that sheds his blood with me shall be my brother.
There's no reason to use JavaScript other than taste. And it's poor taste that uses JavaScript for client-side validation or any other task that simply must be performed properly.
JavaScript weenies and HTML page designers are popping up here like mushrooms after a good rain. Luckily the sun will soon come out and kill them all.
Comment removed based on user account deletion
"you know what- this is stupid. Let's meet somewhere in the middle, both give in a bit, and come up with something that's better for the community as a whole".
Do really think Microsoft cares about "the community as a whole"? What planet have you been on for the last 15 years? MS uses every mechanism possible to grab the public by the balls and keep their $10 billion/month revenue stream flowing. IE-specific web apps are a great lock-in mechanism for them. MS will do absolutely everything to continue the mentality of "everyone uses IE and Windows, so just develop for that".
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.
I likes to make me users suffer. I set my pages to refersh 60 times/sec and when the call and complain I tells 'em to upgrade their computers. Bwah ha ha ha!
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Check again, IBM encouraged its users to switch to firefox two months ago. http://news.zdnet.co.uk/software/applications/0,39 020384,39198253,00.htm
It runs on more than IE does, but don't pretend its 100%. Mozilla is still horribly broken on non-i386 platforms, and isn't ported to several OSs.
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
In a lot of cases, I know exactly what it would take - support for XML data islands. I know, I know, the stock answer is that you should be doing that as an XML style sheet, so it's not a missing feature of Mozilla. The problem is when the app that requires data islands is owned by someone else who has not the time, the resources or the incentive to rewrite their app to do it "the right way" instead.
Besides, it seems to me that it should be possible to implement via a plugin, no? I mean, google for "mozilla xml data islands" and you'll find forum posts and articles going back to 2000 asking for this, so howscome nobody's tried to do it yet?
"Lawyers are for sucks."
- Doug McKenzie
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.
Wow a MSIE article that is not about a security holl
*Head explodes*
Even just a year ago, I'd totally agree with you... but the big shift that makes JavaScript valuable is the AJAX paradigm for web applications, which is esssentially the strategy of using XmlHttpRequest objects to send requests that allow you to update snippets of the resident document.
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.
Billie's wrath shall be terrible!
They are usually written by Frontpage trainned monkeys, which by itself almost garantees an IE-only result. They are then lightly edited for code/debug by people who have Microsoft as their sole "standards" provider, making it almost impossible to get any result other than an IE specific site.
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)
You should be able to implement data islands without touching the original code as a Greasemonkey script (even with the less powerful version in use right now).
Slightly off-topic, but certainly related... I'm surprised none of the comments I've read have mentioned the 'User Agent Switcher' plugin.
When I run into apps that tell me they require IE and refuse to work with anything else, I find that quite often it's not that they contain something specific that no other browser can support, but more likely that they've only ever been tested with IE and the site wont support you unless you run IE.
In Firefox, click "Tools" -> "Extensions", then click "Get More Extensions" and search for something called "User Agent Switcher".
It basically lies to the web app server and reports that you are running a different browser. Just pick a browser that the site supports and usually the site will just work.
A word of caution that obviously there are sites that do only work with specific browsers because of the way they were coded -- but often times the site is merely checking the User-Agent HTTP header string and simply refuses to let you proceed any further if the string doesn't match one of the sites supported browsers. The plugin does NOT change the capabilities of Firefox to emulate IE... the plugin lets your browser lie to the server so that you can get past the browser version check.
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 wish the article would cover Windows authentication issues (NTLM, Kerberos)... which is the real nail in the coffin for the Mozilla browsers when it comes to deploying them on a corporate network. Anything good to read out there?
there's no place like ~
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.
No, there isn't a difference.
Smart organizations - filled with people that actually understand the strengths of the internet - know this.
It's the CapsLock and the stray exclamation mark that do it.
"wouldn't call them developers if they develop a web app just for IE. True developers test for compatibility."
Gee you know how people's pets end up looking a lot like their owners? Well apparently slashdot posters end up thinking a lot like their computers. "On","off", yes, no, "true developer","fake developer"*, us, them. Seems there's more division in the "techno-elite" ranks than originally thought.
*Oh you're going to burn in nerd hell, if you don't get with the program.
Notes 5 version of iNotes is IE only, yes.
But Notes 5.5 (? not sure) and 6 support Mozilla browsers. IBM has done a lot of work together with the Mozilla guys to fix this.
What power has law where only money rules.
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..."
"Your point is especially wrong when it comes to event handling in IE versus Mozilla based (firefox). Firefox uses the w3c model of addEventListener(), IE uses attachEvent()."
I am not sure what you are trying to denote, but per your comment, you are noting things that you can code in Mozilla that will not work in IE. The purpose of the Slashdot post is to note that an IE only coded web site may not work in Mozilla. You are simply pointing out that the reverse is also true. AS many have stated in other comments, Conforming to the WC3 standards will most always result in web pages that work in both browsers. The IBM article goes well beyond either of these points though and notes that Third party coding languages, such as Javascript, from Sun Microsystems can also present substantial problems with compatability. If anything, I think the article is noting that there are multiple players in the web coding arena that are guilty of either allowing bad code to be rendered or not recognizing the WC3 standard as it was intended.
So tell me "idiot" you are trying to tell me my php app even running on linux cannot authenticate to AD?
..... ba ha ha ha hah ha
Sorry I tried not to use the word "idiot" but it is the only thing I could find that was fitting for the parent post.
I bet you use Front Page for all your development work also
Got Code?
If a client requested that no documentation or training and that the user interface be presented upside down, would you do that too?
There's a certain level of professionalism that comes will your reputation. Sometimes the job just isn't worth it.
Considering the client will still ridicule you for not having the foresight - even if you do - in the future, you should play your cards carefully. Money now might mean less money in the future.
Just food for thought.
Mod parent up for being in-your-face-you-fucking-AJAX-on-Ruby-Rails-REST-s emantically-correct-tableless-but-23-CSS-workaroun d-full bloggerwhores.
[quote]"Have you ever wondered what would it take to make your (unfortunately) IE-only web app to work on Firefox?.[/quote]
No. I'm not in the practice of producing non-portable code in the first place. The extra work of making something portable is still less work in the long run than producing multiple versions of said code.
Non sequitur: Your facts are uncoordinated.
Back in the days of ASP, PHP was a real contender. Today, ASP.NET makes PHP4/5 look like Mike Tyson after he got out of jail.
Caio Chassot has created a godsend of a Javascript library for abstracting event handling and all sorts of other goodness:
http://v2studio.com/k/code/lib/
Actually a java script widget set like qooxdoo combined with a ajax library like sajax punks asp.net to all hell and back.
Got Code?
If XHTML validity is your only argument you are going the wrong way.
I expect that XHTML will never become a real standard because it denies the fact that a webpage is a fusion of two trees (data and layout).
The W3C standard is designed by language purists. It doesn't take into account the most basic requirement: HTML is a language that should be usuable both for absolute beginners and for IT people.
People keep using tables, innerHTML and other "outdated" stuff because they are simple solid solutions to their problems. The "modern" alternatives are more complicated and less intuitive.
The W3C people might do better to provide real basic standardisation like making HTML, CSS and javascript use the same properties.
Ok, how?
You can hack out some php code to integrate Active Directory, but if the company has more than one custom application, you're wasting their money re-writing authentication & authorization code that also may be insecure. Oh, and by the way, this code-based AD integration is not what I am talking about in the parent post when I'm referencing windows authentication. What you're refering to falls under forms authentication.
Your world:
1) Write code that queries against Active Directory
2) Write cleaning code that looks at form fields for malicious input
3) Write AD Authorization handling code
4) Compile and Implement
5) User must type in a username and password in a form
6) Server deals with overhead for passing data back and forth against AD (note this is more expensive than my solution- you'll see why in a second)
My world:
1) Write web application that uses one line of code to reference Windows Authentication
2) Set acls on the web application directory giving users permissions to the app through the OS
3) Compile and Implement (note! No complicated code here for dealing with malicious data- no authorization code either!
4) User visits website and begins using it immediately. HE DOES NOT HAVE TO ENTER USERNAME OR PASSWORD (assuming they have perms to the directory). I.E. Internet Explorer Passes Active Directory Data from the O.S. to the server only for authentication (A Kerberos ticket! NO EXPENSIVE AD QUERYING!)
Does that help? Do you understand the distinction here?