Some Notes on the YUI Rich Text Editor

Blog
About

Site Search:

August 13, 2007 at 12:07 pm by Dav Glass | In Development | 39 Comments

About a year ago I made a Rich Text Editor (RTE) prototype to show that it was possible to build one on top of YUI. Of all my YUI examples, it quickly became one of the most requested, and the project indirectly resulted in me joining the YUI team in a formal capacity.

Once I started on the YUI team, building a full-featured YUI Rich Text Editor became my top priority. Even though there are many DHTML-based RTEs available in the open-source world, including Moxiecode’s excellent TinyMCE, there were four key reasons I took on the challenge of building a new one for YUI.

A-Grade browser support – Most available RTEs fail to support the full spectrum of A-Grade web browsers. Most support IE and Firefox well, but few support Opera and I’m not aware of any that fully support Safari. For example, many existing RTEs don’t offer list editing in Safari. I thought we could do better. Because YUI is committed to A-Grade browser support (and because I’m a fanatic Mac user) fully supporting Safari was a top priority for me. Wrestling Safari into submission was no small task, and I’ll look at some of the specific challenges below.
Extensibility – I wanted to build an editor that would allow fellow developers to add their own unique functionality. The YUI Rich Text Editor’s Toolbar is designed from the ground up to be extensible; the Flickr example is meant to illustrate this, as is the example of the Calendar Control implementation.
Accessibility – What happens when users employing assistive technologies are presented with a rich-text-editing interface? What should happen? I spent time working with Yahoo! accessibility specialist Victor Tsaran to answer those questions. I believe that I have engineered some of the answers into the YUI Rich Text Editor. This is an area of ongoing development, and I’ll share more details as the RTE progresses out of Beta status.
Footprint and Performance – I wanted to build an RTE that was small and fast. It’s already lighter-weight than some, but let’s be clear: It is not there yet. You can count on the fact that I’ll be putting a lot of effort into shrinking its footprint and improving its performance, while maintaining (and improving) consistency across the A-Grade browsers.

Current and Future Status

Before I get into the fundamentals of the YUI RTE, let me give you an update on the state of the project. First, this editor is currently a Beta control, and as such there is still much work to be done. Second, it’s neither a site editor nor a development environment. It’s designed for simple things like web mail systems, blog posts and comments, online reviews, and so forth. However, I did try to expose as many hooks and events as possible so that others could build upon the basic A-grade browser foundation that the RTE provides.

The Development Path

My development approach was to bend Safari first. I built it to work in Safari 2 before retrofitting it back to Opera, then Firefox and lastly Internet Explorer. I figured that if I could make Safari do what I wanted, the other three would fall into place nicely. And they did. By choosing to make Safari work first I was able to make the others do things in a standard way as well. I hope that Safari will eventually catch up to its A-grade peers and add support for the things that I have “emulated”, so I took that into consideration too.

Hacking Around Safari

Safari 2 is a really good browser, but it was also the most challenging browser to support with the RTE project. It lacks some serious and critical features when it comes to editing HTML content from JavaScript. I will try to explain the main hurdles that Safari presents:

Iframe Focus – One of the biggest issues was actually quite simple to solve. Safari (and Internet Explorer) has an issue with selecting text inside of an embedded iframe. If you select text within the editor’s iframe then click/focus the parent document, the selection within the iframe is lost. Clearly, this makes it rather difficult for a button click to take action on the selection (because the selection is lost when you click the button!). It also makes it difficult to use, say, a YUI Menu Control for a drop down. As I investigated this problem, I determined that if you stop the mousedown event on the button/href the selection doesn’t get lost. However, if something else (say a href in a dropdown menu) gets focus, the selection will still get lost. This leads me to the next Safari trick.

Selection Object – The selection object in Safari is very limited (to say the least). To work around its limitations, the YUI RTE caches a copy of the current selection in the _getSelection method. Then, the next time _getSelection is called I check to see if a cache existed. If the cache is there, I “rebuild” the selection and destroy the cached copy. This little trick is what lets Safari use a YUI Overlay as a menu instead of the more classic approach of a select element. It’s roundabout, but it works.

execCommand limitations – This is the mother of all hacks for Safari (and the others). My biggest problem with the native execCommand method (in all browsers) is that the browser doesn’t tell you what it applied the command to. So there is no real way to get an element reference back after running a command on a selection. The world of JavaScript editors would be so much more civilized if this would happen (hint, hint, nudge, nudge). So what I had to do was implement this feature myself. My current approach may not be the best way to do it (I have some other ideas that I am working through), but it does the job for now. The method is named _createCurrentElement and basically it runs execCommand('fontname', false, 'yui-tmp'); on the given selection (since fontname is supported on all A-Grade browsers). It will then search the document for an element with the font-family/name set to yui-tmp and replace that with a span that has other information in it (attributes about the element that we wanted to create), then it will add the new span to the this.currentElement array, so we now have element references to the elements that were just modified. At this point we can use standard DOM manipulation to change them as we see fit. In short, I’m using the iframe’s DOM to store metadata during editing as a way to enrich the communication that’s possible between the editor and the iframe.

Making it Your Way

Over the past few years I’ve implemented many of the available RTEs. Because of this I brought a “taste of your own medicine” mentality to the table. I wanted to build an editor that was easy to extend and change. The YUI RTE has Custom Events for everything that I could think of! I made all of the event handlers standalone functions that can be overloaded on the instance or on the prototype. I also tried to make as many things configurable as possible.

Just to give you an idea, let me show you a quick way to change one of the editor’s default behaviors.

Editing links in the YUI RTE.

The Create Link Dialog – Say you want to use a different input utility for link creation (a pre-defined links list maybe?) instead of the default link editor. Well, here’s some sample code to turn it into a JavaScript prompt:

var oEditor = new YAHOO.widget.Editor('demo');
oEditor._handleCreateLinkClick = function() {
    oEditor.on('afterExecCommand', function() {
        var str = prompt('URL: ', 'link');
        var el = this.currentElement[0].setAttribute('href', str);
    }, oEditor, this);
};

Using this technique, you could easily write your own property editor. By the way, the “insert image” dialog can be overridden in exactly the same way (for example to make it a photo picker), just override the _handleInsertImageClick method. You could either override it as above, or you could override all editor instances (so every editor on the page would behave the same) like this:

YAHOO.widget.Editor.prototype._handleCreateLinkClick = function() {
};

The Look and Feel

If you don’t like the visual design of the RTE, simply change the CSS. As with YUI’s entire family of controls, the visual presentation of the control is written in CSS and can be reskinned to suit your implementation. See the RTE’s skinning example for more information on how CSS controls the presentation of the RTE specifically. We’ve even provided the Photoshop source file for the icons to make it easier for you to create a design that’s customized for your site. Maybe you like the colors, but you don’t want to see the labels above the “groups”? Well, add these few lines of CSS:

.yui-skin-sam .yui-toolbar-container .yui-toolbar-group h3 {
	display: none;
}
.yui-skin-sam .yui-toolbar-container .yui-toolbar-group {
	margin-top: .75em;
}

Once you dig in, I think you will find that the YUI RTE is pretty flexible and easy to extend.

In the End

Safari was tough, but I’m stubborn. When Safari properly supports execCommand, things will be even better. YUI’s RTE is exceptionally extensible and customizable; from very low-level functionality all the way up through the visual layer. It’s also semi-lightweight, and will be even lighter before I’m done with it.

I hope you enjoy my first YUI control. Please keep the feedback coming.

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

39 Comments »

RSS feed for comments on this post. TrackBack URI

Any plans for implimenting tables?

Comment by Brian — August 13, 2007 #
@Brian – Since we are striving for full A-Grade support, adding a table editor will be very tricky; table editing is not supported very well in Opera and not at all in Safari. So yes, it is on my list of additions; but I can’t be sure when it will make it in.

Comment by Dav Glass — August 13, 2007 #
Really good RTE. The plugins are easy to implement. Great job! Waiting for the future release.

Comment by Antoine — August 13, 2007 #
Really glad to read about someone putting effort into supporting Safari, not a lot of people do. I also use Safari as my primary browser (why would I buy a Mac to use Firefox??) and do find myself getting annoyed when I come across a site that just doesn’t work when I know 90% of the time there’s no good reason for it.

Comment by John McKerrell — August 13, 2007 #
@Antoine — Thanks :)

Comment by Dav Glass — August 13, 2007 #
Any thoughts on providing a button to show the raw HTML ??

John Forsythe (www.jforsythe.com) is integrating it into dasBlog and that seems to be the one thing missing currently ??

.. KenH

Comment by Ken Hughes — August 13, 2007 #
You rock Dav! Having myself worked on a (much simpler) DHTML rich text editor in the past, I know what it takes to get the cross-browser support done. Kudos to you and the team. Can’t wait to get my hands on the future release!

Comment by Julien Lecomte — August 13, 2007 #
[...] I got to post my very first blog article over on the YUI Blog. Swing on over and take a peek.. Add to: document.write(”Del.icio.us”) | Digg it | Slashdot | [...]

Pingback by Davs Rants and Random Thoughts » First YUI Blog Post — August 13, 2007 #
@KenH — We left that out of the first version, because when we do it we want to do it right :) But there are a couple of options, the Plain Text Switcher example gets you started and my WordPress plugin uses that technique but doesn’t strip the HTML. So download it and take a peek at the source.

@Julien — Thanks..

@John — I do all my dev work in Firefox (because of Firebug), but I do all of my surfing with Safari. I too, really hate being blocked by a site not supporting Safari. So I thought I would try to spread the word that Safari is a capable browser and should be treated that way..

Comment by Dav Glass — August 13, 2007 #
Dude… you pretty much rule for making and releasing this! Thanks… I love seeing where you folks are going with the whole YUI project, and I totally appreciate your efforts.

Comment by Jon Roig — August 13, 2007 #
[...] doch nur ein Link auf einen – zugegebenermaßen – sehr interessanten Artikel im YUI-Blog: Some Notes on the YUI Rich Text Editor. Zusammengefasst: ich hätte keinen Bock, so ein Ding zu bauen, aber das machen ja zum [...]

Pingback by Neues vom YUI Rich Text Editor » Code Candies — August 13, 2007 #
[...] Some Notes on the YUI Rich Text Editor. [...]

Pingback by Morning Brew #61 — August 14, 2007 #
[...] RTF Editor von Yahoo by Wolfgang Schmidetzki Tuesday, August 14, 2007 10:11 PM Im Yahoo User Interface Blog berichtet Dav Glass über seinen neuen RTF-Editor (offizieller Status: Beta).Unter Anderm sagt er: [...]

Pingback by Schmidetzki.Net — August 14, 2007 #
I had some pretty significant style collision issues working it into our existing web app, but the configuration wasn’t any more difficult to integrate than the other rich-text editors out there.

I duplicated the example flickr plugin and got our own flickr REST proxy running too.

here is an early demo:
http://www.jforsythe.com/jforsytheblog/2007/08/15/YUIEditorInTheHouse.aspx

good stuff Dav.

Comment by John Forsythe — August 15, 2007 #
@John — Thanks, awesome too see that it was that easy to implement. Would you mind dropping me a note about the style collisions?

Comment by Dav Glass — August 15, 2007 #
[...] of the YUI team was in charge of building the new Rich Text Editor that was just released, and has documented part of the journey which includes how he managed to get this puppy working on Safari 2: My development approach was [...]

Pingback by Ajaxian » Tales of the Rich Text Editor and Safari Support — August 16, 2007 #
Wow! Anyone make a File Manager for it yet, like FCK’s?

Comment by ellisgl — August 16, 2007 #
The rich text editor support in Safari is quite limited and has many errors, which need to be worked around for more than very basic rich text editing and formatting.

We have actually fully supported Safari in our Asbru Web Content Editor (editor.abrusoft.com) since September 2005! It has been and still is a lot of hard work and many other developers have given up – but it is doable.

Comment by Soren Vejrum — August 16, 2007 #
[...] I read that the Yahoo UI team has finally bent Safari to its will to support WYSIWYG editing. We’ve come a long ways since I was hanging out on the Mozilla developer lists and asking [...]

Pingback by User First Web » WYSIWYG Editor for Safari — August 17, 2007 #
[...] 17th, 2007 in Links A slick rich editor component based on the YUI Javascript [...]

Pingback by warpedvisions.org » Blog Archive » Another solid rich web edit componet — August 17, 2007 #
[...] Some Notes on the YUI Rich Text Editor » Yahoo! User Interface Blog Rich text editor that works in Safari (tags: safari wysiwyg editor yahoo) [...]

Pingback by User First Web » links for 2007-08-19 — August 18, 2007 #
[...] Some Notes on the YUI Rich Text Editor » Yahoo! User Interface Blog —Interesting bit on how the new YUI RTE was implemented and works in all A-grade browsers (including Safari!) [...]

Pingback by Links for 8/19/07 [my NetNewsWire tabs] — August 19, 2007 #
What version of FF do you develop on? I have v2.0.0.6 on the mac, and after testing YUI RTE on Safari, FF and IE 6(win), FF was the most unusable with the insert position being lost each time the tool bar is clicked. This was from the YUI examples site, I have yet to install it locally, but is this known or am I the one goofed up?

Comment by Troy — August 20, 2007 #
@Troy –

The RTE was primarily developed on the latest FF release as well as the latest Safari. I an unable to replicate any of the issues you point out.

If you would, please file a bug here, make sure and give the Browser/OS and Machine version you experienced the problems with..

Thanks
Dav

Comment by Dav Glass — August 21, 2007 #
I wish the footprint were smaller (check the comments from yui-ext they your’s is 90k and thier is 20k are some thing).Also the editor is so bloated that it takes longer to respond to event and finally doesn’t respond.looking for cleaner and simpler editor widget just like YUI widget….
THnks

Comment by blue — August 23, 2007 #
@blue — Other “simple” editors are smaller because they only have a very limited set of features compared to this editor. Besides the YUI Editor is only 22k when it is minimized and gzipped. What browser and os are you using that is not responding? Please file a bug here so I can look into it..

Comment by Dav Glass — August 23, 2007 #
Dav, first of all. Great Job!

I started adding support for Safari 2 to the WYMeditor old demo, and I know how painful it is.

I managed to fix Iframe Focus, Selection Object and added a work around execCommand limitations, pretty much the same as you did. But it still far from A-Grade. Is there a public development repository for the source code? I would like to follow this editor development. I tried source forge, but no luck.

Did you code a selection API for this editor?

You might want to have a look at WYMeditor, specially the XHTML parser in the trunk, which plays beautifully when pasting from MS Word and for cleaning up design mode garbage.

Comment by Bermi — August 24, 2007 #
An eg of integrating flash videos would be nice.
Specially flash video from youtube or some other service :)

Thanks Dav

Comment by MySchizoBuddy — September 20, 2007 #
TinyMCE will not allow users to edit anything within contenteditable=”false” container element. If YUI RTE could support this feature, it would have everything I am currently using from TinyMCE. I started looking at editor-beta-debug.js and honestly I’m not sure where to start changing code to support this.

What are your thoughts on this? Is this a simple, medium, or hard thing to code? Any plans for support of this on your end?

Thanks for a great RTE!

Comment by JazzyJrFl — October 4, 2007 #
How do I extend it to support the insertion of flash?

Comment by Howard — October 12, 2007 #
I have been running into a lot of problems writing an rte starting with [not Safari] and then getting Safari to work… I love my mac, so I don’t want to leave it behind!

You mentioned creating a cache of the selection and then after focus is lost, “recreating” the selection… Do you mind sharing how you actually acquire the selection, and reselect it?

Mostly I need help finding the current selection to cache, after that I should be able to call selectNode() or selectNodeContents() or some method like that…

Comment by Alex — January 22, 2008 #
” The Create Link Dialog – Say you want to use a different input utility for link creation (a pre-defined links list maybe?) “

This is just I want ! Anyone can give me a example of a complex overrided “createlink” popup ?

Comment by loloajax — February 1, 2008 #
Im making a big website in .net and I have triede tinyMCE and FCKEditor. This one match what my customer needs… just perfect

Comment by Niels Henriksen — August 1, 2008 #
Hi, I like the way YUI text editor look and work, that’s the reason why I decided put it in some of my web projects; but when I try to validate the content of my message I can’t trap it. I’m a PHP-Ajax developer, so since two years ago I don’t use anymore the simple but not ajaxian way to submit a message using simple POST/GET and let to PHP validate the content, I let this work to JavaScript, but sadly I’m looking for some documentation about this without success. So I guess some words about the way how YUI’s rich text editor do it will be fine. Maybe I need look at the YUI’s rich text editor more than 6 minutes?

Thank you!

Comment by Oscar — August 16, 2008 #
I have tried TinyMCE and FCKEditor in the past and the YUI RTE suits my needs much better. Thank you for your work on this.

One question though. It seems to have an inbuilt spellchecker in Firefox but not in IE. Any plans to get this working for that pesky browser?

Thanks again.

Comment by Mark D — September 23, 2008 #
Hi Dev,

Any idea when and if you are going to handle stripping embedded MS Word styles in text.

almost everyone copy/paste text from word and i like to control my own style sheets.

I just love your editor, but this is a real urgent necessity for me. And i think a lot of people.

at least as long as MS Office still rules the market. which i hope is not too long :-)

thanks in advance.

Regards and keep up the good work.

Nikaj

Comment by Nikaj Wiggers — October 2, 2008 #
I’ve been using YUI’s RTE for a few months now. I have it implemented on two client’s website and just noticed something.

Whenever I load information into it, anything after a < will not show.

For example, if i load the following text into RTE:
<testing

it will show up as blank. However, when i view the page source, i see <testing

It’s strange =( I’ve been in the freenode’s YUI channel and no one knows.

Also, a ‘view html source’ button would be very handy, as sometimes when i delete text, the RTE doesn’t delete all of it, (it leaves some junks, for example, empty tags such as )

I really enjoy this editor though. Just need a way to figure out a way to get this fixed.

thanks for the hard work!

Comment by bruce — November 21, 2008 #
Any updates about the filtering of MS WORD embedded styles in text?

I am having the same problem and I cant find any solutions to this problem.

Clients are copying and pasting text they type in Word 2007 and after submitting reviewing the inputted text contains all sorts of weird characters.

A solution would be much appreciated!

Thanks

Comment by Kevin — December 15, 2008 #
@Kevin –

This list message should help:
http://tech.groups.yahoo.com/group/ydn-javascript/message/41845

Comment by Dav Glass — December 16, 2008 #

Yahoo! User Interface Blog