ComponentArt Editor for ASP.NET AJAX ...

Without any doubt, the upcoming Editor control is the most anticipated product ever developed by ComponentArt. Our customers have been telling us for years that they are unhappy with existing solutions on the market, and that we should make a ComponentArt-quality browser-based WYSIWYG editor. We set out to do that about a year ago, and I am happy to announce that we are approaching the first public beta release.

Building a solid browser-based text editor is hard. Our research has uncovered fundamental problems with various ASP.NET editing controls as well as major online document editing services like Google Docs. I will talk about our unique approach to the problem as well as share some interesting things we learnt along the way.

How Browser-based Editing Works

Modern browsers have built-in rich text editing features. Developers can take advantage of those features by simply adding an IFrame to a page and setting its document.designMode property to "on". This enables editing of the IFrame is content and provides many basic editing features "for free". However, there are vast inconsistencies among the browsers in the way that editing is handled. Consider the following minimal fragment of text:
First some bold text, then some italic text, then a change of color.
Finally, a new paragraph!

Let is review the markup generated by various browsers when this piece of rich text is entered.
Internet Explorer 6-7:
<P>First some <STRONG>bold text</STRONG>, then some <EM>italic text</EM>, then a change of <FONT COLOR="#ff0000">color</FONT>.</P>
<P> Finally, a new paragraph! </P>

Firefox 1-2:
First some <span style=font-weight: bold;>bold text</span>, then some <span style=font-style: italic;>italic text,</span> then a change of <span style=color: rgb(255, 0, 0);>color</span>.
<br>Finally a new paragraph!<br>

Ouch! Not only is the output from IE and Firefox entirely different, but neither is XHTML-compliant. Let is try the other two leading browsers...
Safari 3 (beta):
First some <span class="Apple-style-span" style=font-weight: bold;>bold text</span>, then some <span class=Apple-style-span style=font-style: italic;>italic text</span>, then a change of <span class=Apple-style-span style=color: red;>color</span>.
<div>Finally a new paragraph!</div>

Safari seems to do the best job so far - the generated markup is XHTML-compliant. However, why is the second paragraph contained in a DIV, but not the first? Also, what is with those Apple-style-span CSS classes? Let is look at Opera...
Opera 9:
First some <strong>bold text</strong>, then some <em>italic text</em>, then a change of <font color="red">color</font>.
<br>Finally, a new paragraph!<br>

We have found that the currently available web editors (including ASP.NET controls as well as online document editing services) deal with these inconsistencies with varying degrees of success. However, we haven found a product that always natively produces cross-browser-consistent, XHTML-compliant markup - without the need to run additional clean-up and conversion utilities.

Our Approach

Let is repeat this mantra one more time: "Create an editor control that natively produces cross-browser-consistent, XHTML-compliant markup - without the need to run additional clean-up and conversion utilities."

In order to accomplish that, we had to take over the control from the browser and write a custom XHTML serializer whose responsibility is to generate the document in response to user commands. That task is not trivial. It essentially amounts to writing a text editor in JavaScript from scratch, since we are no longer getting freebies from the browser. It was a lot of work, but we think it was worth it, as it brings additional important advantages beyond the purity of the generated content:

1. Completeness and power of the client-side API. Having full control over not only the markup, but the code that generates that markup allows us to expose a pretty powerful API to the developer. This API includes the same methods (for things like applying styles, getting/setting selections, controlling the structure of the document, etc.) as those used internally by the Editor control itself. In line with the rest of the Web.UI suite, Editor is API is based on the client-side component model introduced by ASP.NET AJAX. More info on the API will be coming soon from members of the Web.UI development team.

2. Ease of extensibility. Our solution consists of a lightweight, standalone Editor box (which can be used without any decoration) and the UI (toolbars, menus, tabs, dialogs, etc.), built entirely through our native Web.UI controls. The Editor box and the UI controls are "tied" together through their public APIs. This means that developers can create custom UIs to drive the Editor control using exactly the same techniques we did. Custom UIs are not only possible; they will be treated as "first class citizens" by our Editor control.

3. Customizable document styles. This is one of my favourites. Separated from Editor UI skinning, developers are also able to customize the styles that will be used for the document content. This includes things like paragraph and heading styles, bullet and number list styles, custom CSS classes and style strings that will be available in the style dropdown, as well as the collection of custom colours that will be added to the colour picker. In a nutshell, this feature enables developers to provide their end-users with a convenient collection of style elements that will fit into the target theme. A Glimpse of this feature can already be seen in the two demos below.

4. Ability to control all aspects of the document. For example, we can allow customizing the line breaking style: developers should be able to specify whether they prefer <p></p>, <div></div> or <br/> elements for breaking.

Finally, adding other new features is fairly easy, now that we have a solid core engine in place and full control of the document as well as the serialization logic. For example, Word paste clean-up can now be easily done, as stripping unwanted tags is simply an option in our serializer.

 Original Source:
http://www.componentart.com/community/blogs/miljan/archive/2007/09/13/finally-componentart-editor-for-asp-net-ajax.aspx