When you first visit the TinyMCE website and check out the examples, you see a very advanced editor, in terms of the share number of functions. But as with most software, the real power is what is behind that graphical interface, the structure and quality of the code, the way it can be configured.

If you are familiar with Javascript, and go through the documentation of TinyMCE you will quickly get a smile on your face, when you realize the power of it all, from the way you make plugins, to how the the GUI is rendered and how the window popups are managed. And it is always a rush as a developer to see when someone has made a really good implementation and configuration, when you can see that they have studied the API documentation in order to bend and twist TinyMCE to function the way they want. There is even some that have stripped away all the theme/gui stuff of TinyMCE and only use it as an engine for their CMS directly by using the API.

The challenge as a developer is not to build yourself into a corner, don’t follow a path that ultimately will lead you to producing bad or bloated code. On the last rewrite of TinyMCE a lot of thought was put into how to avoid problems like that, and I think we did an excellent job, the code base feels very solid.

One example of powerful configuration is the valid_elements and extended_valid_elements options in TinyMCE, where Spocke invented its own format that has now spread to other projects, read more about the format on the documentation page.

The same goes for our other products, MCImageManager and MCFileManager, there is so much stuff going on behind the scenes in these products its crazy, we even implemented a form of .htaccess type configuration override (but we call the files mc_access). Means that most of the options you can set in the config.php file, you can also put into mc_access files to control the configuration for different folders. For example, you could make it so that if you upload a file to a certain folder, it re-sizes those images to a fixed small size, but if you upload to a different folder, you get a big image. You can restrict access to even upload, or disable certain functions in certain folders, and much much more.

So, check the documentation, even if you are satisfied with how it works, perhaps you can find some hidden gems that are extra useful just for you.

I am guessing noone has avoided noticing the financial crisis in the news, going through the world like a wave through an arena crowd. Can’t really say we have noticed it on our end though, this month will be a record in visitors for the TinyMCE website, as well as a monster amount of bandwidth being pushed out since we moved examples from the Wiki website to the TinyMCE website.

We certainly do not feel like we will be affected much by the financial crisis, on the contrary, perhaps the IT budgets are more slimmed and that makes companies look for Open Source alternatives, and finding that some of these projects are more structured, more tested and more stable than their commercial or home made version.

Currently we are busy doing major work on the MCFileManager and MCImageManager, planing to release 3.1 final during next week, with major behind the scenes rework of the graphical user interface, as well a few new features. We are also working on a secret new Open Source project we just came up with (stay tuned for that).

We will see what the future holds.

There have been lots of fuzz and development of small rich text editors lately and I think it’s time to comment on the these. I will try to explain why size matters.

Some users argue that TinyMCE is bloated and that it can be written way smaller if we rewrite it using JQuery, Prototype or some other library out there. This is not the case, we have calculated that we would gain about 5% in size for the core API. In other words 5k but we would on the other hand loose the library independence so TinyMCE will not be ported to any of these libraries since there isn’t much to gain. Most of the logic in TinyMCE is not related to normal library things like CSS selection, event handling, dom manipulation these parts are pretty small in size the large chunks of code are related to HTML Serialization, URL handling, browser workarounds for editing and those can’t be found in any library out there.

Another common thing we see is “TinyMCE has to much features that’s why it’s bloated, this other mini editor is just 1000 lines of code”. I just have one thing to say about that, TinyMCE is extensible most of the features are placed in plugins so if you remove all those plugins there isn’t that much bloat anymore. The other thing is that most of the logic in TinyMCE is related to browser issues and quirks none of that can be covered with 1000 lines of code.

We are trying to make a stable editing solution crossbrowser that will work the same and this is a very tricky task and that task will require more than 1000 lines of code. Trust me on this we have developed rich text editors in JS for 7 years so we have came across hundreds of browser bugs over the years. So it’s not possible to make a stable editing solution small and still fix the bugs. Not until all the browsers starts to work the same way and there isn’t anything pointing to that in the near future since there is no good specification on how editing in the browser should work. The HTML5 specification doesn’t really cover this.

The size of TinyMCE can also be dramatically improved if you use the GZip compressor package we provide . It will reduce the size by 70% and reduce the number of requests with a equal amount. So if you think TinyMCE is to large use that component.

There are situations where small size matters more than the browser quirks and the output. And then TinyMCE might be overkill to use this can be comment systems on blogs, forums and other situations where valid output isn’t required since the server will process the content anyway. This is why we created PunyMCE, we call it the bastard brother of TinyMCE. It’s small, extensible but not that competent and it will never be since that’s not the goal of that project. It will not turn into another big editor, it’s focused on small size it’s only 9kb in size.

So my suggestion is to choose the right editor for the right task. If you need an editor for CMS systems or blogs TinyMCE is a good fit since it will try to produce valid XHTML/HTML output and has all the features you might need. If you need something for a comment system and doesn’t care about valid HTML and have a backend that will parse the editors output choose a smaller editor like PunyMCE.

So finally there is one thing I have left to say. Size matters but there are also more important issues to take into account when choosing an editor. Does it have a large userbase, is it extensible, does it have unit tests, good documentation and active community? If I where to choose something other than TinyMCE I would look at FCKEditor or YUI Editor. These other editors also have what you would need for serious production usage, the smaller ones don’t.

TinyMCE is not always the perfect match if you need something really small and simple. TinyMCE is designed to be a CMS editor and it has all the features that you might need for such a task.

Some times you want something really small and simple for example on a forum or comment system. This is where PunyMCE comes into the picture it’s designed to be small and simple but yet extensible. It comes with a number of plugins that extend the functionality of the editor.

The size of PunyMCE is “puny”, about 9kb gzipped or 16kb minified. It’s library independent so it can be used with common frameworks like jQuery, Prototype, YUI etc.

But it’s important to understand that PunyMCE is not designed to be an replacement for TinyMCE nor will it ever be. TinyMCE is focused on being a robust CMS editor that produces valid output and takes care of all browser quirks. PunyMCE is focused on being small and simple, it might still have lots of browser quirks and output issues some of these can be corrected by using serverside technology.

This project was a result of a partnership with Freewebs. Kickapps has also joined the project and will help out internationalization.

So check the PunyMCE project out at:

PunyMCE
Google project

I think I have found the answer, noone reads it anyway, if you look at the TinyMCE forum, 75%-90% of the questions have direct answers in the documentation (or even the FAQ), and the replies to it is simple “check the documentation” followed by a “brilliant, thanks!”.

In my opinion, TinyMCE is quite well documented, thanks to ppl helping out and keeping it up to date and free of typos. It has taken a lot of time to make this documentation good, and it feels kinda sad that ppl do not take the time to read it.

Everyone does not have the same way of thinking, but at least when it comes down to solving an issue with a 3rd party software, these are the simple steps I follow.

1. Check the documentation to the product, the readme, install.txt, wiki etc.
2. Try a few different Google querys to find out if someone else has had the same problem.
3. Search in forums/mailinglists etc for a solution.
4. Try to contact someone or post in public forum/mailinglist etc.

Seems like a lot of ppl just skip to step #4 right away.

Well I guess it is better to have than not to have in the end, hopefully some ppl developing more advanced integrations get a lot of help from the API documentation etc.

There is a lot of buzz going on now about the new Google Chrome browser, and a lot of different testing of its performance against other browsers.

We take performance very seriously, thousands of ppl use TinyMCE every day, it is important that it works smooth on the browsers, not just loading performance, but also the performance of all the stuff that’s going on under the hood when you work with the editor.

So, the tests we have seen online so far have been very wide spread, showing insane performance improvements, but what are they testing? Is there any real-world implications of these performance tests?

TinyMCE uses DOM operations a lot, we have our own test bed, and these are the tests we are running.

• Serializer - This tests the cleanup functionality, a lot of DOM operations.
• Style parser/serializer - Tests a lot of string and array handling.
• URI - Tests a lot of regexp performance, converting URLs back and forth.

And these are the results.

The performance is measured in milliseconds, lower is of course better.

Summary

We could not install MSIE 8 beta on the same machine as MSIE 7, so no tests for that right now. The testing machine is a Windows Vista 64-bit, 4GB ram, 2.66gz Dual Core. Tests where performed with nothing other than the testing browser running.

Safari comes out on top of performance, with Firefox close behind, however we did not see any improvements when enabling the new JIT compiler in Firefox 3.1 Nightly build.

Results vary a bit up and down, but you can perform these tests yourself at this location.

http://tinymce.moxiecode.com/js/tinymce/performance.html

These tests try a lot of different things at the same time, using the TinyMCE API, the performance improvements that the browser developers have been bragging about does not seem to be there, at least not in the areas interesting for most developers (DOM operations).

I recently read an interesting blog post at Ajaxian it described that Hedger Wang discovered that some Chinese fellow was able to fix the circular reference memory leak in IE using a finally statement. This got me very exited since it would remove the need to use the unload event to cleanup memory leaks. There are lots of issues using the unload event to cleanup memory leaks I blogged about one of them earlier and using an non unload approach would make things a lot easier and more efficient.

Here is the proof of concept class and you can see it in action at the example page.

(function() {
	window.EventUtils = {
		eventFuncs : [],

		addEvent : function(o, n, f) {
			var el, id;

			// Resolve element by id if needed
			o = typeof(o) == 'string' ? document.getElementById(o) : o;

			if (o.attachEvent) {
				// Since we can't use attachEvent we need to generate an unique id for the object
				// and place functions in an array one for each object
				el = EventUtils.eventFuncs;
				id = o._evtID;

				if (!el[id]) {
					// Generate new unique id
					id = o._evtID = el.length;

					// Add event listener old fashion way instead of attachEvent
					o['on' + n] = function() {
						var i, l, e = window.event, li;

						e.target = e.srcElement; // Force W3C style

						// Execute each event listener in order
						for (i = 0, li = el[e.target._evtID], l = li.length; i < l; i++)
							li[i](e);
					};

					// Create array with first function
					el[id] = [f];
				} else
					el[id].push(f); // Push in more functions

				// Fix the IE leak
				o = null;
			} else if (o.addEventListener)
				o.addEventListener(n, f, false);
			else
				o['on' + n] = f;

			return f;
		},

		removeEvent : function(o, n, f) {
			var i, li;

			// Resolve element by id if needed
			o = typeof(o) == 'string' ? document.getElementById(o) : o;

			if (o.detachEvent) {
				li = EventUtils.eventFuncs[o._evtID];

				if (li) {
					// Detach event listener by looking for it and remove it from the array
					for (i = 0; i < li.length; i++) {
						if (li[i] === f)
							li.splice(i, 1);
					}
				}
			} else if (o.removeEventListener)
				o.removeEventListener(n, f, false);
			else
				o['on' + n] = null;
		}
	};
})();

Here is a simple example on how to use the class it adds two events and removes one of them this sample code can be seen live running the example page:

var f;

EventUtils.addEvent('elm', 'click', function(e) {
	alert('Listener 1: ' + e.target.id);
});

f = EventUtils.addEvent('elm', 'click', function(e) {
	alert('Listener 2: ' + e.target.id);
});

EventUtils.addEvent('elm', 'click', function(e) {
	alert('Listener 3: ' + e.target.id);
});

EventUtils.removeEvent('elm', 'click', f);

We focus a lot on the size and performance of TinyMCE, each feature, optimization and fix adds more KB to the source, we always weigh fixes and feature against the increase in size of the package. If you use TinyMCE without compression, the Javascript, with all plugins and all features, is around 150kb, if you use the GZIP feature, you get it down to 75kb.

Is this big? Lets take a few examples, if you surf on a newspaper website, something most of us visit every day, you load far more than TinyMCE.

Here are some examples of some of the most visited websites in Sweden.

www.aftonbladet.se
CSS: 252kb
HTML: 244kb
JS: 252kb

www.dn.se
CSS: 325kb
HTML: 231kb
JS: 187kb

www.idg.se
CSS: 126kb
HTML: 140kb
JS: 175kb

This is without images or flash. Am I the only one to find this completely insane? Doing this test made my browser crash just surfing between these websites.

Perhaps TinyMCE is Tiny after all.

We have been users of the Sourceforge system for a long time now, and personally I think that is has been going downhill for quite some time, more ads, more downtime, site is slugish and at the same time, nice alternatives have been poping up. For example, Google Code and if your brave, the Trac system that you can run on your own servers, been keeping an eye on that for some time and it seems very nice really. Only problem is that its made in Python, not to fond of that.

Spocke planned to make a release of TinyMCE today, but Sourceforge has been down almost all day and now the site is up, but the SVN isn’t, so we will see.

I thought I might report a bit on the status of the browsers regarding WYSIWYG support and ContentEditable, watching the bugs we have reported, there have been quite a lot of fixing going on the last few days, both on Safari and Firefox.

Firefox
The features that they have implemented is quirky, but on the upside, they are further along than most other browsers in terms of functionality, if only the things they had worked properly, it would be great. One major problem with Firefox, that goes through many of their features, is the cursor handling, it jumps around and does not perform as expected.

Safari
On the complete opposite of Firefox, the things in Safari that they have implemented works very well, but the browser lacks certain important features. Overall, its looking very good, but its slow progress.

Opera
These guys are very fast as fixing bugs, there are some minor known issues with the back button at the moment, but other than that it’s very nice. We enjoy working closely with the Opera team.

Internet Explorer
We do not have as much overview of the current status of MSIE 8 development as we would like (if anyone at MS reads this, get in touch). Most of the stuff seems broken now in the latest 8 version, so we are basically waiting for the next Beta before we start to look into it more. But on the positive side, in MSIE 7, the things that work works flawlessly, there are a very low number of quirks compared to other browsers. It’s tough to report bugs and get them noticed however, so for any problems that does exist there isn’t much hope in getting them fixed.

So there you have it, our status report on current development in the WYSIWYG area of browsers.