Finally! ComponentArt Editor for ASP.NET AJAX

This space is available to any ComponentArt employee to write about anything.

Finally! 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'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!

Posted by: Miljan
Posted: Thursday, September 13, 2007 1:48 PM

Comments

PAML IT said:

Excellent work. I'm excited to see the final product. Thanks for giving us this sneak peek at the editor.

# September 13, 2007 5:27 PM

RvP said:

The story of how the development investigation and the approach appeals to me and I am hoping that a beta version will be available soon. I'm hoping that the loading time of the real version will be better than the sneak preview. It took quit some time to load (or was that only my experience)

# September 13, 2007 11:35 PM

Miljan said:

Thank you very much for the praise PAML IT! RvP, loading times depend on the complexity of the skin being used. The Editor control itself is extremely lightweight. However, the "Black Ice" skin is image-heavy, which is why it takes a little while to load (especially if your Internet location requires a few hops to our server). We are currently working on new skinning techniques that will enable rich skins that load very quickly. Not sure if these techniques will be included in the 2007.2 release, but some news on this front should be available soon.

# September 14, 2007 11:42 AM

Wayne said:

Will the editor support uploading and placement of images?

# September 14, 2007 12:16 PM

Miljan said:

Uploading images to the server will not be supported in the first release. However, we will support embedding images into the document (if they are already on the server) through the "Insert Image" dialog, where you'll be able to specify image placement, among other things.

# September 14, 2007 1:17 PM

kavorka said:

Re: loading speed, it would really help to immediately show some kind of a frame and a "loading.." type message, since not having anything render for a bit is awkward, esp. for a first time visit on a slower connection. Other controls on the market have this drawback as well. Coalescing all css and js files into single files also helps a lot, if that is an option.

# September 15, 2007 10:34 PM

Miljan said:

Thank you for your suggestion Kavorka. Indeed, coalescing all CSS and JS files into single files does help, as it reduces the overall number of requests. However, vast majority of requests are tiny 1Kb image files (for toolbar buttons, etc.). We have just completed a demo that uses the new skinning technique I mentioned above. The main idea is to dramatically reduce the number of images as well as the overall download size by combining many images into a single file. At that point CSS techniques are used to clip the big image and only display the desired portion of it. You can see a reproduction of our Black Ice skin through this technique here:

- "Black Ice" Skin - New CSS Technique

In our tests, this demo loads dramatically faster than the "standard" Black Ice demo above. One of the main challenges we've had with this technique was a flicker in IE6 (which we considered a show-stopper), but we think we were able to eliminate it.

# September 26, 2007 1:50 PM

oVan said:

After playing around a bit with the fonts I noticed it doesn't always produce the desired layout. Checking the html-code reveals several ... constructs, which is probably not intended?

# October 2, 2007 12:22 PM

Miljan said:

Thanks for reporting this oVan. Yes, this sounds like a defect. Could you please send the exact steps for reproducing this problem to beta@componentart.com? Your help is much appreciated.

# October 3, 2007 6:57 AM

Jay said:

Looking good. I tested on a poor connection and the new skinning method was alot fasster will there be spell checking facilities available like netspell support or something?

# October 4, 2007 1:42 PM

Miljan said:

Great, thanks for confirming better loading time on a slow connection Jay. In answer to your question, yes - we will offer integrated spell checking in the first release of the product.

# October 4, 2007 2:01 PM

Lawrence Arnold said:

Having recently retired, I now have time to devote to my love or computers and web development. Having worked with HTML for several years, this product should speed things up as I get into web development and PHP programming. Hope the price isn't too high. Larry Arnold larystoy@yahoo.com websbylarry.com

# October 6, 2007 8:29 AM

Stephen said:

Does the editor have an upload functionality to upload images from HD to server?

# October 9, 2007 7:40 AM

Miljan said:

The first release will not support uploading images to the server, just embedding images that already exist on the server. We are considering the uploading feature for the next release. I would appreciate feedback from more users who need this feature. So far it looks like we have two people on this thread who need image uploading.

# October 9, 2007 8:17 AM

PAML IT said:

Uploading of images is a must. If you don't build it in, we'll have to build it in ourselves almost every time we use this control. Unless you want to build a complete Image Gallery control... :) That would REALLY be usefull.

# October 9, 2007 7:33 PM

Niall said:

Yeah!! Brilliant! I'll buying these controls in the next few weeks. Great work!

# October 10, 2007 12:59 AM

nibbler said:

I think image uploading is needed by everyone who embedds images into the HTML. Something like a filemanager which can be opened directly from Image-Dialog would be great. (like: http://www.fckeditor.net/extras/ckfinder but in ComponentArt Quality :-)) Is there already a release date for the public beta and will the Editor be part of the WEB.UI?

# October 10, 2007 3:09 AM

Andy said:

Looks good so far Does your editor support integration with a spell checker? Will it suport protected areas of text which the user cannot update? Do you have a road map for feature development?

# October 10, 2007 4:55 AM

kavorka said:

the number of requests made has a huge bearing on the perceived performance of a page. esp. for css and js files (js files at the top of a page in particular) since until these are full loaded the browser will not display any content. To that end, the css files coming down if rolled into 1 will have a meaningful impact. And compression of course makes it that much better...but that would mean digressing from the topic here. Basically your library should facilitate sending css down as one file rather than separate files, and also in the case of the editor render out something very fast so that the perceived performance is swift. I can see in HTTP Professional that the css files take a bit of time, and then the browser blocks on the ajax axd files. I am not aware of how the ajax javascript files can be speeded up -- outside the scope of this topic -- but basically downloading all that stuff makes the editor load slower.

# October 10, 2007 12:51 PM

Kirk said:

WTG ComponentArt Team! This looks great thus far and I know it will continue to get better before and after the initial release. Can't wait to get my hands on the beta!

# October 10, 2007 5:47 PM

Designworks-Development said:

Very good work looking forward to using 2007.2 and helping beta test product, any Idea on a beta release date for WebUI Subscribers looking to intergrate new features of 2007.2 with MS Silverlight and 3D web based wpf developments.

# October 12, 2007 5:12 AM

Miljan said:

Thank you for all your feedback. Our feature set for the 2007.2 release is essentially frozen as we speak. We agree with you regarding the image uploading functionality. It would definitely be useful, and this will be one of the most important features to consider for the very next release. Andy, yes - the control will have an integrated spell checker. This functionality will be available in the upcoming beta release. On that note, we expect to ship the public beta release within 1-2 business days. Please stay tuned...

# October 12, 2007 9:45 AM

Design-2k said:

> On that note, we expect to ship the public beta release within 1-2 business days. Please stay tuned... When do you think it will be available to Customers? Haven't found it in the downloads Section even though i have enabled Beta Downloads in my Profile.

# October 15, 2007 3:40 AM

Andy said:

Thanks Miljan, What dictionaries will be supported ? Will you be supporting a medical dictionary?

# October 15, 2007 4:16 AM

Jay said:

For me the image uploading is a must since I currently use FCKeditor and we have that option turned on. The spell checker is the one I really need as well (mentioned above) but I am willing to test out the product may even just make something my self for the image uploading. Will you be notifying subscribers via email when the beta is out?

# October 15, 2007 6:47 AM

Brian said:

I would like to see more support for relative paths like "../" and "~/" that in .net means that you take the application path and then append the remaining path. If you try this in the demo it does not work as expected. E.g. If from the HTML editor you change href="http://www.componentart.com/publish/news.xml" to href="~/publish/news.xml" and then switch to design mode and back to HTML mode you will see the problem. This is required if you host the content editor under a certain URL and then publish the actual content to a different URL. If the paths need to be hardcoded then the above would not be possible.

# October 16, 2007 1:48 AM

Miljan said:

Design-2k, our goal is to make the beta release publicly available to all customers within the next 24 hours. You'll see an additional beta download button in the main website ribbon nav. I will also post an update to this blog as soon as the beta becomes available. Andy, we will ship three standard dictionaries with the 2007.2 release: US-English, UK-English, Canadian-English. Please note that our SpellCheck architecture allows you to easily embed custom dictionaries, so supporting a medical dictionary shouldn't be a problem. Jay, implementing your custom dialog that supports image uploading is a perfectly viable option. In fact, all of our own dialogs are implemented externally to the control by simply using the publicly available APIs. We will ship the full source code for those dialogs as examples - so you could use them as a starting point for further customization. Brian, your suggestion for supporting ASP.NET application paths is interesting and worth investigating. Would you expect the paths to be resolved when you switch back to design view? In other words, do you expect to still see the "~/" values when you switch back to the code view?

# October 16, 2007 8:51 AM

PAML IT said:

Could you give us an idea of how many "skins" or templates or looks you will be releasing with the Editor?

# October 16, 2007 12:22 PM

Miljan said:

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. PAML IT, this build ships with the following skins: BlackIce Ribbon, BlackIce 2-Level, BlackIce Compact, Arctic White Compact and Office 2003 Compact. We are planning to ship more skins in the final release.

# October 16, 2007 5:50 PM

Andre said:

I have been watching for the release of the editor for awhile, and it looks very impressive. I'm particularly intrigued by the depth to which the control manages the tags to maintain the XHTML compliance. My question to CA would be: do you think that this editor could be easily adapted to support XML as opposed to XHTML, possibly by round tripping the content through XHTML and back to XML? We've toyed with a few other editors and have not found a reliable method to acheive this. This capability, and the features that it would make possible, would be an amazing coup for CA! Any thoughts on how it might be possible?

# October 17, 2007 8:37 AM

Andy said:

I noticed there is a callback error when performing the spell check.

# October 18, 2007 7:59 AM

Aaron Lewis said:

Looks great. Did notice that no editing at all is possible in Safari on Mac OS X, however. Hopefully not overlooked? We have to support pretty much every config over here.

# October 18, 2007 12:15 PM

Miljan said:

Thanks for reporting the spell check error Andy. I was missing a web.config entry for the blog demos - it's fixed now. Aaron, support for Safari 3 is currently on our "nice-to-have" list for the full release. In other words, we do intend to support that browser, but we won't hold the release if Safari support is not fully implemented.

# October 18, 2007 1:03 PM

Limbo said:

"So far it looks like we have two people on this thread who need image uploading." - I would like to sign up for this too! It looks great, but lacks image facilities!

# October 19, 2007 2:32 AM

Scott said:

FileManager functionality is unfortunately a deal-breaker for me as well. It's the number one feature asked from my clients. They expect a WYSIWYG editor to allow them to upload images and files to the server, on the fly when creating links and images through the editor. Is the product going to be included in a suite bundle, or is it being sold stand-alone? Any hints on pricing??

# October 20, 2007 11:58 PM

Roger said:

Just wanted to throw another vote toward adding image upload functionality ASAP. The usefulness of this control is severely restricted without this feature. Otherwise, great work! - Roger

# October 21, 2007 8:17 PM

Steve said:

Hi guys, great work - neat looking control! Just wanted to chime in with another request for image uploading...

# October 22, 2007 4:59 PM

Rod said:

Great work. We'll be using it immediately after it has upload capabilities.

# October 22, 2007 6:40 PM

Øyvind said:

This sounds very promising. But without document/image/video/flash upload and simple file manager capabilities, we just can't use it. We'll be waiting for the release when these things are integrated, and evaluate it then.

# October 24, 2007 7:32 AM

Miljan said:

Our feature set for the 2007.2 release is essentially frozen as we speak. We recognize that the most requested Editor missing feature is image/media uploading. This will definitely play a major role in determining the feature set for the 2008.1 release.

# October 24, 2007 11:49 AM

Kevin said:

A couple of features I would be extremely pleased to see in this Editor are: 1. File Manager - for managing uploads of files, as previously mentioned. 2. Templating - For example, is it possible to lock certain areas of HTML with special tags so it is impossible for someone to change their content? This would extremely useful to only allow certain users control of certain page elements. 3. Is it possible to load a complete HTML page into the editor, i.e. from to tag?

# October 24, 2007 3:18 PM

SteveP said:

I noticed that when I use the table I can't use the tab to go from cell to cell. also the delete key doesn't work.

# October 24, 2007 7:51 PM

Jochen said:

I've already got another tool, it is a page in my solution doing some nice things with the uploaded images. Is it possible to embed this page as a custom image upload dialog into the editor?

# October 25, 2007 12:04 AM

Hilmar said:

I like the approach, but find the lack of table-editing (adding/removing rows or columns) a bit of a let-down.

# October 25, 2007 12:28 AM

Dave said:

I remember requesting this a couple years ago and being told it would make it out in time. It's great to see it's here!! Cheers, Dave

# October 29, 2007 9:09 PM

Wildrice said:

So glad to find out about this! Currently building an advanced CMS for a client which is making use of several of the CA components, and a 3rd-party .NET editor that's not great but works for now. As I get more of these in place, I hope to integrate the CA editor as well, once the image/file upload mgmt is in place. Curious to know: 1) do you plan to offer the capability for custom buttons (i.e., to popup iframe or window containing custom-developed pages)? 2) do you plan to offer the capability for custom drop-down lists (i.e., tie to XML or database for name/value lists ... like, say, a list of web pages to link to)? 3) to what degree will you offer table/tr/td editing (I know this one's a challenge, but has the potential to be so much better than what's currently available with what I've seen you folks do so far)? TIA, and nicely done so far!

# October 31, 2007 4:00 PM

Andy said:

I'd like to second Kevin's request for templating. i.e. enabling the protection of certain areas of text from being updated by the user.

# November 1, 2007 3:27 AM

billfredtom said:

i have found that table editing is what baffles users most - it needs to be easy to use yet powerful.... after all, these editors are made so users don't have to know HTML. the best i've seen is at cutesoft.net, the concept of dashed lines for zero border tables so you can see where the cells are and context sensitive operations within the table to alter cell, row or table properties. would like to see something along these lines!

# November 4, 2007 5:23 PM

Miljan said:

SteveP, please try the Release Candidate build (released earlier today) and let me know if the table problems persist. Jochen, yes - you can absolutely use your existing solution to extend the image embedding capabilities of the Editor control. Please download the RC build and read the "Using the client-side API" tutorial. Hilmar, the table editing options you mention are included in the RC build. Wildrice: 1) we already support adding custom toolbar buttons and dialogs. In fact, all of the current buttons and dialogs are external - they rely on the API; 2) You should also be able to insert your own custom drop-down lists using the same approach 3) We currently support the basic table editing functionality (adding/removing rows/columns, merging cells, etc.). We are planning to expand on this in the next release. Andy and Kevin, this indeed sounds like an interesting feature. Is there an example you could point me to? I'd love to see it in action. Thanks for your suggestion billfredtom, as I have said, table editing features should be expanded in the next release. My apologies if I have missed somebody!

# November 5, 2007 1:58 PM

Richard Tappenden said:

Hi, will this have the facility to insert custom tags etc from a drop down list? It would be really handy...

# November 8, 2007 1:52 AM

Stephen said:

Image upload to the server is a major plus, as most CMS systems have WYSIWYG's that have this functionality, When you start dealing with end users, they mostly cannot handle ftp. Would be nice to have this in the next version.

# November 12, 2007 5:59 AM

Dipal Bhavsar said:

Does ComponentArt:Editor's spell check provide multi language support? Does it support for Swedish Language?

# September 9, 2008 12:04 AM

Finally! ComponentArt Editor for ASP.NET AJAX

Comment Notification

Comments

PAML IT said:

RvP said:

Miljan said:

Wayne said:

Miljan said:

kavorka said:

Miljan said:

oVan said:

Miljan said:

Jay said:

Miljan said:

Lawrence Arnold said:

Stephen said:

Miljan said:

PAML IT said:

Niall said:

nibbler said:

Andy said:

kavorka said:

Kirk said:

Designworks-Development said:

Miljan said:

Design-2k said:

Andy said:

Jay said:

Brian said:

Miljan said:

PAML IT said:

Miljan said:

Andre said:

Andy said:

Aaron Lewis said:

Miljan said:

Limbo said:

Scott said:

Roger said:

Steve said:

Rod said:

&#216;yvind said:

Miljan said:

Kevin said:

SteveP said:

Jochen said:

Hilmar said:

Dave said:

Wildrice said:

Andy said:

billfredtom said:

Miljan said:

Richard Tappenden said:

Stephen said:

Dipal Bhavsar said:

Øyvind said: