As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I was talking with a colleague about a problem we were having and he suggested that one possible solution was to use an IFrame.
I haven't needed to use an IFrame for he last 5 years and I've done full time web application development, but it made me wonder if the concept of the IFrame and Framesets is something that is supported by browsers for backwards compatibility but really shouldn't be actively used in development any more?
it's one of the major application integration methods for facebook and myspace. and most wysiwyg html editors rely on iframe. thickbox uses iframe. drupal uses iframes. and on and on... so not sure if it's so very simple to just call iframe obsolete. i imagine it'll be actively used for a good long while still...
It's the fastest and easiest way to get any of a number of google services into a web page, where the fuller control of the API integration is not needed.
Like anything else, it is situational. It's far from dead, and there's no reason it should be dead. The web's moving to looser coupling, and IFrame is in line with that.
At best the IFrame isn't ideal for rendering local content, but, like others have said, it is the only way to get external web-content into an application without an API and for that reason it is very important to modern web-development.
No, it shouldn't.
It's a cheap standard way to integrate functionality in a single page. Also allows some useful techniques such as COMET
Not sure if it should be dead. For one of the application I worked on for the manufacturing industry, they wanted multiple tabs to be able to run multiple programs on the same page. Knowing using just regular divs using Ajax would just be a little too much for this intensive app, we used iframes. Of course, it doesn't look like iframes to the end user (using some creative Javascripting and CSS), it looks like just a regular tabbed program.
So, saying it's dead is probably a little too soon unless there are better alternatives.
It's extensively used in ad tracking and conversion tracking; it's one of the easiest ways to put a beacon into a site unobtrusively.
I think that iFrames are not dead yet, they can be used for a lot of things and though they slow the loading speed of a website (with a few miliseconds, depends on the content).
iFrames maybe, Framesets NO. this is what i think. some things can be done only with iframes believe me i searched for another solution for a long time but for eg. a jscript can be used 2 or more times with iframes but when used on a single page it may cause conflicts and sometimes only the first thing that was using the javascript is working.
so sometimes iFrames are the right way to do it, if you can`t do it any other way.
No, its commonly used in junction with AJAX.
For example, on a page where you have ongoing AJAX requests you can't disrupt the response by closing it etc. BUT, you may need to provide a file download on the same page which would normally disrupt the AJAX request. To avoid the conflict, you serve the file download through an IFrame so that the AJAX on the host page isn't disrupted.
That's at least one use case for it =)
Iframes are not dead. They are the only method of fighting several extremely annoying bugs in MSIE (such as div overlapping a <select>), and are widely used in banner exchange networks.
If you consider the fundamental building blocks of the web you will realise that the iframe should never be removed. I have the feeling that many web developers do not properly understand the concepts of data centric systems and prefer to work in a procedural, top-down, application centric manner. There are many things done with async HTTP requests and Javascript that should simply use an iframe.
There are two fundamental concepts when it comes to linking content in a data centric world like the web - cross referencing and embedding. Hyperlinks are used to cross reference data while iframes are used to embed data. URLs are used to reference data in both cases.
A simple example is linking to an image. Cross referencing an image would be done as follows:
Link to the image
While embedding an image would be achieved as follows:
<iframe src="someImageURL" />
Of course you could use the "img" element to embed an image instead, but that is specific to images... I vote that the "img" element be removed in favor of using the more generic and flexible iframe.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been reading a lot of stuff about HTML 5 recently. Something still looks very fuzzy to me and I hope somebody can help me understand it better.
Is HTML 5 for the "technology" to create the UI only? If I need to create an application to access bank accounts, how is it possible that HTML 5 will replace all other technologies? I mean there must be some kind of web service that the application has to use to access the data on the server and I can't see how that piece can be done with HTML 5.
As with any new technology there is always a lot of speculation from commentators who don't really understand it... It always made me chuckle when I heard people talking about sites being 'Web 2.0' or 'Ajaxy'
Put simply:
HTML5 is just the same old html which we've been using since the nineties but with some improvements from HTML4&XHTML1. There are a few new tags, some of which aren't even new they've just been standardised.
HTML5 provides native support for many features that used to be possible only with plugins or complex hacks (a native drawing API, native sockets, and so on). Plugins, of course, present problems:
Plugins cannot always be installed.
Plugins can be disabled or blocked (for example, the Apple iPad does not ship with a Flash plugin).
Plugins are a separate attack vector.
Plugins are difficult to integrate with the rest of an HTML document (because of plugin boundaries, clipping, and transparency issues).
Although some plugins have high install rates, they are often blocked in controlled corporate environments. In addition, some users choose to disable these plugins due to the unwelcome advertising displays that they empower. However, if users disable your plugin, they also disable the very program you’re relying on to display your content.
This is where HTML5 comes on the scene, smiles, and waves its magic wand of native functionality. You can style elements with CSS and script with JavaScript. In fact, this is where HTML5 flexes its biggest muscle, showing us a power that just didn’t exist in previous versions of HTML. It’s not just that the new elements provide new functionality. It’s also the added native interaction with scripting and styling that enables us to do much more than we could ever do before.
Take the new canvas element, for example. It enables us to do some pretty fundamental things that were not possible before (try drawing a diagonal line in a web page in HTML4). However, what’s most interesting is the power that we can unlock with the APIs and the styling we can apply with just a few lines of CSS code. Like well-behaved children, the HTML5 elements also play nicely together. For example, you can grab a frame from a video element and display it on a canvas, and the user can just click the canvas to play back the video from the frame you just grabbed. This is just one example of what a native code has to offer over a plugin. In fact, virtually everything becomes easier when you’re not working with a black box. What this all adds up to is a truly powerful new medium.
HTML 5 is indeed markup and JavaScript APIs for the browser. It isn't intended to access data on servers.
But it's rarely used on its own.
CSS adds style to content.
JavaScript makes client side code dynamic.
AJAX allows you to make asynchronous calls to services to get data, keeping your UI responsive.
Yes, you still need services.
HTML 5 replaces earlier versions of HTML, nothing more.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I haven't used frames since 1998. They seem like a bad idea and in all my development I've never had a situation where frames were the right solution, or even a decent solution.
However, I'm now working with an internal web application written by another group and the entire site is built in a - header, left side menu, right side content - frameset.
For one, when VPN'd to my network I constantly get a "website.com/frames.html" cannot be found." error message. This doesn't happen when I'm on the internal network.
Second, the app has a built in email/messaging system. The number of unread messages is shown in the left side menu frame as "Messages (3)" but the count doesn't update as I read the messages. The developer told me since it was in a frame I needed to right click on the menu and 'Refresh'. Seriously????
So, my programming related question is, what reasons do you have for not using frames in a website?
Although they solved a problem at the time they were created (updating part of a "page" while keeping in place a non-updating part), framesets were criticised in terms of usability pretty much from the start, as they break generic functions of the browser, such as:
bookmarking, and copy-and-pasting URLs to share
printing the page as displayed on the screen
reloading the page: since the URL has generally not changed, you will often be taken back to the site's homepage or default frameset; manually reloading some frames is possible, but not obvious to the user
back and forward buttons are ambiguous: undo/redo the last frame change, or take you to the last time the URL bar changed?
The heaviest burden of avoiding framesets - including the same content on every page - is trivial to solve if you are using any server-side language to generate your HTML, even if all it provides is a "server side include". Unlike framesets, a server-side include could occur anywhere on the page; building a site with a server-side scripting language or templating system has other obvious advantages too.
There is still an advantage to being able to update small areas of the page without reloading the entire content, which can be achieved via AJAX. This sometimes leads people to create interfaces with all the problems of framesets outlined above, but that is hardly an argument in favour of framesets. Again, a site built with well-designed AJAX functionality can achieve things which framesets don't even begin to address.
One good reason to avoid frames today is they have been deprecated in HTML 5: Chapter 11 Obsolete features
11.2 Non-conforming features
Elements in the following list are entirely obsolete, and must not be
used by authors:
[...]
frame
frameset
noframes
Either use iframe and CSS instead, or use server-side includes to
generate complete pages with the various invariant parts merged in.
The #1 reason? Users hate them.
Even if they offered advantages in other areas (separation of code, application design, speed etc) they are part of the user interface. If users don't approve, don't use them.
Frames were vaguely useful when you had a static web site, to avoid repeating navigation menu in all pages, for example. It also reduced the overall size of a page.
Both these arguments are obsolete now: sites don't hesitate to serve fat pages, and most of them are dynamically built so including such navigational parts (or status, etc.) has no problem.
The "why" part is well answered above, partly by your own question (you hit a limitation, although it can be overridden with a bit of JS).
My number 1 reason not to use frames is because they break the bookmark (aka favorite) feature of browsers.
With the technology that exists today, frames have become obsolete. But if your legacy project still uses them, you can make the messages update with some ajax.
Just because of the cell phone iPad craze doesn't mean that highly functional full featured sites are suddenly "obsolete", and those who decided to make framesets obsolete seem to be the same complainers who never figured out their full potential in the first place, or maybe they're the lobbyists of the mega-corporate cell-phone and tablet makers who couldn't be bothered to make a decent frames capable browser for their itty-bitty screens.
Admittedly, iFrames can handle simple jobs like scrolling and/or displaying independent segments within a single page pretty well, and I use them for that inside my own frames based website, but to get them to work as well as the foundation for a site itself is a nightmare. Trust me, I know because my website is one of the most sophisticated frameset based sites on the Internet and I've been looking at the pros and cons of transposing it all to iFrames. Nightmare is an understatement.
I can already hear the whiners saying, "Well why did you build it that way in the first place then?" ... and the answer is A: Because I'm not lazy. and B: Because a frames based site is the most functional, visually appealing, and user friendly format for an information based site with hundreds of pages of content that doesn't have to rely on a server. By that I mean all but the external advertising can be viewed straight off a flash drive. No MySQL or PHP needed.
Here's some of the issues I've encountered:
The objection to orphaned pages can be easily handled with JavaScript.
The objection regarding bookmarking is irrelevant unless you use no frames all.
Content specific bookmarking can be handled with an "Add Bookmark" JavaScript function
The objection regarding SEO is easily handled by an XML sitemap and JavaScript.
Laying out dynamically sized frames is far easier and more dependable with standard framesets.
Targeting and replacing nested framesets from an external frame is easier with standard framesets.
In-house scripts like JavaScript searches and non-server dependent shopping carts that are too complex for cookies don't seem possible with iFrames, or if they are, it's way more hassle to get them working than using standard frames.
All that being said, I like the single page appeal of iFrames, and when they can actually do all the same stuff for my site as easily as standard frames does now, then I'll migrate. In the meantime, this nonsense about them being "obsolete" is as irksome as the other so-called "upgrades" they've foisted on us over the years without thinking it all the way through.
So what does all this boil down to for the question of whether or not to use framesets? The answer is that it all depends on what you want your site to do and on what platform it will mostly be viewed on. At some point it becomes impractical to make a multi-page site work well without some frames or iFrame integration. However if you're just creating a basic profile page that displays well on a cell phone or tablet, don't bother with framesets.
They almost always make people angry. What more do you need?
Frames are really useful in some occasions. If you are creating a local webpage that serves only for reading, no interactivity involved and the website will not be public on the internet, all the reasons on not to use frames are removed. For example a user manual for an application that is developed solely in html, frames are really useful in keeping a table of contents on the left in a simple and easy to code way. Also if you have proper navigation within the website then the back button ambiguity is removed completely
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Getting contradictory messages about that, hope they're not.
I cannot imagine support for it would stop, since a gazillion sites use them.
Some additional questions about that:
Why should they phase out this tag?
Any alternative for it?
Support for <iframe> is still there in HTML 5, so I don't think this will change in the near future.
To answer your other questions:
<iframe>s (as frames in general) are most of the time not user-friendly:
They don't allow easy access of the content in the frame via an URL (without losing the content outside of the frame at least).
Most "technophobe" users are irritated by frames.
As far as I know they are slower to render for browsers
Alternatives include dynamic page generation (SSI, PHP, Rails and so on) and using JavaScript / AJAX to change contents of e.g. a <div>
To be clear: I'm talking about <iframe> as an interface element. Not a hidden element for loading other stuff like e.g. Google Mail does.
In my opinion the W3C jumped the gun in dumping iframes from the Strict HTML and XHTML doctypes. In theory you would use the <object> element to add foreign objects to your document, but browser differences and limitations have made this a nonstarter for many developers. With the much-more-pragmatic HTML 5 (which is still a draft), iframes are back and even have two new attributes: seamless, and the intriguing sandbox.
IFrames are not obsolete, but the reasons for using them are rare.
Using IFrames to serve your own content creates a "wall" around accessing the content in that area.
For crawlers like Google, It's not immediately clear that cotent in an iframe will be ranked as highly as if the content were simply part of the page. For many, this is reason enough not to use it.
It makes the DOM for the IFrame less accessible by tools like jQuery, prototype etc..
Reasons for using iframes:
It's great for walling off other people's stuff from other domains but it doesn't integrate smoothly. (stylesheets, javascript etc...)
Integrating multimedia can sometimes be done easier via an iframe as opposed to using the embed tag.
Really, really specialized cases like gmail's case where they are using it for sounds and history management.
I would also answer that there is no need for the removal of iframes, it's a needed tag and will be around for a while.
Iframes are obsolete for page layout. Never use them instead of good CSS layout, even table-based layout is better.
Good reasons for using iframes are:
ads: adwords for example uses this technique, it is good for encapsulating - ad css won't destroy your page.
hidden iframe: it can be used for hundreds usable things, like tracking, ajax-alternative, etc.
I've seen lots of forums that suggest the Object tag as a replacement for IFrame, which probably works in most cases.
For example, I had a PDF showing in an IFrame (because there were other things we need to show on the page besides only the PDF) and was able to get it to display fine using Object.
What was:
<iframe id="confirmed_pdf" class="current_pdf" src="/prescriptions/show_pdf?id=123" height="570" width="480"></iframe>
Became:
<object id="confirmed_pdf" class="current_pdf" data="/prescriptions/show_pdf?id=123" type="application/pdf" height="570" width="480">
<p>[Show this message if displaying the PDF did not work]</p>
</object>
But Object was not a suitable replacement to fill the requirement to be able to print ONLY the PDF portion of the page.
An IFrame is like its own window within the page (a window within a window, basically), and once you get the window object, you can call .print() on it, like:
jQuery("#confirmed_pdf").contentWindow.print();
IFrame has a contentWindow property, that's what makes printing only that part possible. Object does not have a contentWindow property, so there's no way to print only the section of the page.
So, it seems like if you're just using IFrame to display something, there's other tags like Object that can be used instead. But if you need to interact with the contents of the IFrame in certain ways, then IFrame may be necessary.
IFrames are used a lot with AJAX. GMail for example, uses nine hidden IFrames I believe.
IFrames are not dead, but Frameset/Frames are dying.
In the last 2 releases of IE (IE7/IE8) zooming in Frames (not IFrames) has created disastrous results.
By all means use IFrames, but IMHO stay clear of Framesets/Frames.
At my previous company, we provided a hosted application that customers would integrate into their own websites. At times, they would use an IFrame to do this, fitting our hosted page into their existing designs. Sometimes this was even done seamlessly (ie. the IFrame had no borders or scrollbars, it just looked like part of the page). I considered this to be a good use of the tag.
They can be extremely useful in some circumstances, but those are limited. In particular embedding common functionality across multiple sites.
For example I have a client who runs a number of Scottish goods e-commerce sites. As part of this we have developed a couple of simple applications to locate possible clan names from your surname or your choice of tartans (giggle if you wish but tartans are worth $700 million a year to our economy). The database behind this is surprisingly large (nearly ten thousand rows in the core names and tartans tables) and fairly regularly updated.
So we have the applications set up to run on one website and then embedded these into our other websites using an iframe, enabling simple javascript parameter passing so we can integrate the selection of a tartan or clan with functionality on the embedding site. The iframe is set as noborder so it appears completely seamless to the end user.
Of course there would be other ways of doing this, but the use of an iframe is simple and robust. And it's certainly not obsolete.
Horses for courses... <iframe>s are like anything else... for the right purpose they're the right tool; for the wrong purpose they're an ugly hack, or worse.
In Ajax, <div>s are often the more appropriate container. In some places the activity of passing-off external content as part of your own site, as supported by <iframe>s, is inappropriate.
My team used an <iframe> the other day as an ideal way to give users access to their HTML e-mail history - the e-mails were complete <html> pages which we wanted to insert easily into our web template. <iframe>s were absolutely perfect for presenting that data]'.
On the other hand, <iframe>s should almost always be removed or disabled in any user-submitted content which is output back onto the site, because in that context they are a major security issue.
The google gadget specification currently relies on iframes: http://code.google.com/apis/gadgets/docs/spec.html
Currently they are the only simple way to provide isolation for javascript apps that are pulled from multiple domains/providers.
Also many of the widgets that people embed on their websites from third-parties use iframes.
While they do have their drawbacks, iframes provide a pragmatic solution to common problems on the web. I'd have to guess that they will be around for some time to come.
Compliance and Security issues can also drive you to use Iframes; Shopping carts are popular IFrame-based implementations when you want to visually incorporate a shopping cart as part of some web pages without taking on full responsibility for the payment processing side of things.
We commonly deliver an Iframe to integrate our eCommerce stuff and clients like how turnkey it can be.
I work for a company that used frames for everything from pull down menus, lists, content blocks, etc just to cover the intricacies of .net web forms. The application is very slow and only runs on IE. Don't do this.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Somewhere along the line I picked up the notion that using iframes is 'bad practice'.
Is this true? What are the pros/cons of using them?
As with all technologies, it has its ups and downs. If you are using an iframe to get around a properly developed site, then of course it is bad practice. However sometimes an iframe is acceptable.
One of the main problems with an iframe has to do with bookmarks and navigation. If you are using it to simply embed a page inside your content, I think that is fine. That is what an iframe is for.
However I've seen iframes abused as well. It should never be used as an integral part of your site, but as a piece of content within a site.
Usually, if you can do it without an iframe, that is a better option. I'm sure others here may have more information or more specific examples, it all comes down to the problem you are trying to solve.
With that said, if you are limited to HTML and have no access to a backend like PHP or ASP.NET etc, sometimes an iframe is your only option.
They're not bad practice, they're just another tool and they add flexibility.
For use as a standard page element... they're good, because they're a simple and reliable way to separate content onto several pages. Especially for user-generated content, it may be useful to "sandbox" internal pages into an iframe so poor markup doesn't affect the main page. The downside is that if you introduce multiple layers of scrolling (one for the browser, one for the iframe) your users will get frustrated. Like adzm said, you don't want to use an iframe for primary navigation, but think about them as a text/markup equivalent to the way a video or another media file would be embedded.
For scripting background events, the choice is generally between a hidden iframe and XmlHttpRequest to load content for the current page. The difference there is that an iframe generates a page load, so you can move back and forward in browser cache with most browsers. Notice that Google, who uses XmlHttpRequest all over the place, also uses iframes in certain cases to allow a user to move back and forward in browser history.
It's 'bad practice' to use them without understanding their drawbacks. Adzm's post sums them up very well.
On the flipside, gmail makes heavy use of iFrames in the background for some of it's cooler features (like the automatic file upload). If you're aware of the limitations of iFrames I don't believe you should feel any compunction about using them.
Having worked with them in many circumstances, I've really come to think that iframe's are the web programming equivalent of the goto statement. That is, something to be generally avoided. Within a site they can be somewhat useful. However, cross-site, they are almost always a bad idea for anything but the simplest of content.
Consider the possibilities ... if used for parameterized content, they've created an interface. And in a professional site, that interface requires an SLA and version management - which are almost always ignored in rush to get online.
If used for active content - frames that host script - then there are the (different) cross domain script restrictions. Some can be hacked, but rarely consistently. And if your framed content has a need to be interactive, it will struggle to do so beyond the frame.
If used with licensed content, then the participating sites are burdened by the need to move entitlement information out of band between the hosts.
So, although, occaisionally useful within a site, they are rather unsuited to mashups. You're far better looking at real portals and portlets. Worse, they are a darling of every web amateur - many a tech manager has siezed on them as a solution to many problems. In fact, they create more.
Based on my experience a positive side for iframe are when calling third party codes, that may involve calling a javascript that calls a has a Document.write(); command. As you may know, these commands cannot be called asynchronously due to how it is parsed (DOM Parser etc). An example of this is http://sourceforge.net/projects/phpadsnew/ I've made use of iframes to help speed up our site as there were multiple calls to phpadsnews and the site was waiting for the response before proceeding to render different parts of the page. with an iframe I was able to allow the site to render other parts of the page and still call the Document.write() command of phpads asynchronously. Preventing and js locking.
There are definitely uses for iframes folks. How else would you put the weather networks widget on your page? The only other way is to grab their XML and parse it, but then of course you need conditions to throw up the pertenant weather graphics... not really worth it, but way cleaner if you have the time.
The original frameset model (Frameset and Frame-elements) were very bad from a usability standpoint. IFrame vas a later invention which didn't have as many problems as the original frameset model, but it does have its drawback.
If you allow the user to navigate inside the IFrame, then links and bookmarks will not work as expected (because you bookmark the URL of the outer page, but not the URL of the iframe).
It's worth noting that iframes will, regardless of the speed of your users' internet connection or the contents of the iframe, cause a small (0.3s or so) but noticeable slowdown in the speed your page downloads. This is not something you'll see when testing it locally. Actually, this is true for any element added to a page, but iframes seem to be worse.
When your main page loads in HTTP protocol and parts of your page need to work in HTTPS protocol, iFrame can beat jsonp hands down.
Especially, if your dataType is not natively json and needs to be translated on server into json and translated on client back into e.g. complex html.
So nope - iFrame is not evil.
They are not bad, but actually helpful. I had a huge problem some time ago where I had to embed my twitter feed and it just wouldn't let md do it on the same page, so I set it on a different page, and put it in as an iframe.
They are also good because all browsers (and phone browsers) support them. They can not be considered a bad practice, as long as you use them correctly.
I have seen IFRAMEs applied very successfully as an easy way to make dynamic context menus, but the target audience of that web-app was only Internet Explorer users.
I would say that it all depends on your requirements. If you wish to make sure your page works equally well on every browser, avoid IFRAMEs. If you are targeting a narrow and well-known audience (eg. on the local Intranet) and you see a benefit in using IFRAMEs then I would say it's OK to do so.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am looking for a text editor to be used in a web page. Where users can format the text and get a WYSIWYG experience. Doesn't need to be too fancy. But has to be easy to use and integrate into the page. Has to generate HTML as output. Support AJAX (one I checked works only with standard form submit) and has to be small in terms of download to the user's browser.
Well it depends what platform you are on if you are looking for server-side functionality as well, but the defacto badass WYSIWYg in my opinion is FCKeditor. I have worked with this personally in numerous environments (both professional and hobby level) and have always been impressed.
It's certainly worth a look. I believe it is employed by open source projects such as SubText as well. Perhaps, Jon Galloway can add to this if he reads this question. Or Phil if he is currently a user.
TinyMCE is the simplest I've found to use. I've never used it in an AJAX-enabled application, but there are instructions on how to do so on the project's wiki.
Try FCKeditor. It supports integration with most popular platforms, and it's fairly lightweight.
You might also want to look at YUI's Rich Text Editor.
If you're starting your site from scratch or haven't invested a lot of effort into another JavaScript platform, Yahoo User Interface (YUI) is a very complete JavaScript library that could help you add other AJAX elements beyond a text editor.
I just did a full day of evaluation of all the ones mentioned so far (and then some), and the one I liked the best is Obout Editor. I think it might be for ASP.NET only, so it might not work for you, but if you are using .NET, it's great. The HTML output is clean and nicely styled, and the rendered output looks the same in the editor as it does when you output it to the page (something I had trouble with when using the others due to doctype settings in the editor). It costs a few bucks, but it was worth it for us.
I found TinyMCE pretty easy to implement. And it's light on bandwidth usage too.
Using fck for some tine now, after "free text box", or something like that. Had problems only once, when I put fck inside asp.net ajax updatepanel, but found fix on forums. Problem was solved in next release.
I would like to see some nice photo browser in it, because fck comes only with simple browser that displays filename, no thumbs. The other one, that has thumbs costs bunch of money.
Didn't try it with asp.net mvc, don't know how will uploading work. It uses one ascx for wrapping js functionality.
i started out using free text box when i was doing a lot of asp.net programming, but now that most of what i do is php i've moved to the FCK editor.
while the change wasn't necessarily prompted by the language, i feel that the fck editor is a better choice because of it's versatility.
For something minimalist, take a look at Widg Editor, it's truly tiny and very simple. It's only haphazardly supported as a hobby project though.
I'm currently using the RTE component of DynarchLib, which is highly customisable - definitely does AJAX - but a bit complicated and not very pretty. It is actively supported, and you can get answers on their forum very quickly.
I previously tried Dojo's editor, and found it broken and badly undocumented. YMMV.
Edit: In response to other people's answers, I've now tried TinyMCE and found it to be excellent. More easily configurable and far fewer problems than anything else I've tried. Use TinyMCE!