AJAX and IE7? 72
Moochfish asks: "Recently, my company took a brief look at AJAX to see if it was worth implementing on a few of our administrative pages to speed up certain tasks. I had created a demo that made an interesting use of live edit fields that showed some promise. However, after a little debate on the issue, we ultimately decided to skip AJAX implementations anywhere in our codebase due to concerns about things breaking when IE7 comes out. I haven't personally tried IE7, but I completely understand and mirror the concern. For you testers of IE7, does it successfully render current, non-ASP AJAX enabled sites without errors? And finally, does IE7 introduce any new functionality that may enhance the current capabilities of AJAX?"
"Many of the AJAX libraries out there have tons of duplicate functionality to handle cross-browser support. Recalling Microsoft's history of IE quirks, it seems likely that the new IE7 will have its own set of problems with regards to JS implementation. With the AJAX craze only growing, how are other developers and IT departments addressing this problem? Is this even a valid concern? While this is probably not an issue with ASP developers - especially with the release of Atlas - is this an issue for sites that use non-MS technologies?"
I don't get the question, I think (Score:5, Insightful)
Seems your question might be more about DOM manipulation, but I have the same advice: install the beta.
non-ASP ? (Score:3, Insightful)
What the heck does the tech creating the html/javascript have to do with the browser's usage of the generated code?
If you specifically mean ATLAS, they you should specify it in that question.
Administrative pages (Score:3, Insightful)
IE7 Browser Usage and Design Decisions (Score:5, Insightful)
It's a non-issue (Score:5, Insightful)
AJAX is a presentation philosophy (AKA: a client-side issue). It runs independent of the server technology used. On various projects, I have implemented AJAX on servers running PHP, ColdFusion, and static HTML. AJAX is server platform independent.
As for the particulars of IE7, I can say that using script.aculo.us [aculo.us] and Prototype [conio.net] libraries run the same if not improved on IE7 in comparison to IE6. The fact that the libraries themselves are actively being tested for IE7 as new beta comes out means that I don't have to do anything extra for the changes; It just works.
I understand the initial concern for IE7/IE6 compatibility, but sticking with a popular library solve this problem and make the concern a non-issue.
As for the server-side of AJAX, what you'll be coding are pages that output either HTML, XML, or JSON. Any server platform can create this kind of output, so questions of server compatibility are moot.
But my word of cation is this: Know why you are changing a component to an AJAX philosophy and how best to implement it. There are good reasons to use AJAX as there are bad ones. Please proceed with cation and purpose.
Shannanigans (Score:5, Insightful)
How hard is it to download the IE7 beta? The app is in-house so if it breaks tell IE7 users to fuck off until support is added for it. Is moochfish totally inept or just trying to fan the 'IE7 is the suck' flames? My guess is the latter.
Re:Firefox (Score:3, Insightful)
Where's the problem telling users to employ Firefox? Hell, most companies oblige you to use Microsoft Word to write your documents and Outlook to manage your e-mail. What's the difference when telling people "you must start Firefox when using the accounting application"?
Re:I don't get the question, I think (Score:2, Insightful)