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's 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's 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's 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's with those Apple-style-span CSS classes? Let's 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't 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's 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's 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. Live Demos We are happy to provide a sneak preview of ComponentArt's Editor control in action: - "Black Ice" Skin - "Arctic White" Skin Please be advised that this is a pre-beta quality product, so it is still rough on the edges, and its functionality will not be entirely stable. I should also say that these demos don't show off all Editor features - they contain only minimal toolbars and no dialogs. Next Steps We are currently alpha testing the 2007.2 release with a small group of select customers. If you run into any bugs while using the demos above, please send the exact steps for reproducing each problem directly to beta@componentart.com . We are planning to ship a public beta release at the beginning of October, and the full 2007.2 release in mid November. As always, these dates are based on our best estimate and are subject to change. This release has been a long time coming, but we hope you'll find that it was worth the wait! Update : We have just shipped the public beta of Web.UI 2007.2, which can be accessed through our beta download page . You will need to be logged into your ComponentArt profile and signed up to the beta program to access the download package. Among other things this build includes two new skins: - "Office 2003" Skin - "Web Ribbon" Skin The last one is my personal favourite. I hope you'll like it too. Share this post: email it! | bookmark it! | digg it! | reddit!
