From a pure feature point of view, this release might not be very impressive, but if you are interested in JavaScript and do a lot of custom development, this is the release you have been waiting for. One of the main focuses for the new 3.x branch is to produce a more powerful API and also make it output valid XHTML code by default.

Some of the more notable changes are:

Rewrote the core and most of the plugins and themes from scratch.

Reduced the over all script size by 33% and the number of files/requests by 75% so it loads a lot faster.

Added new and improved serialization engine, faster and more powerful.

Added new inlinepopups plugin, the dialogs are now skinnable and uses clearlooks2 as default.

Added new contextmenu plugin, context menus can now have submenus and plugins can add items on the fly.

Added new skin support for the simple and advanced themes you can alter the whole UI using CSS.

Added new o2k7 skin for the simple and advanced themes.

Added new JSON parser/serializer and JSON-RPC class to the core API.

Added new cookie utility class to the core API.

Added new Unit testing class to the core API only available in dev mode.

Filesize is still huge. Looking through the source I see that tinymce is mimicking what most javascript frameworks allready have. A logical next step would be supporting one or more of these libraries. Framework users will then no longer have to look for editors that support their framework because they don’t want to drop in this much extra code. It will also reduce filesize by another 70%.

Comment by Nick — November 2, 2007

We have thought about writing some bridge to other libraries like jQuery and YUI like how Ext does it. But I don’t think that we would reduce the size that much since most of the logic in TinyMCE is based out DOM serialization and that is not the main focus of for example jQuery and it has lots of code for CSS selection of elements and that makes little sense in a editor environment so the overall file size would then be larger. But still it would be nice to be able to use features from other libraries. :)

@Spocke: I see what you mean. Adding such a bridge to TinyMCE will increase it’s filesize. It will on the other hand help to optimize code in a lot of places, since you will be able to use the library features yourself. From a framework user point of view it doesn’t make much sense to use a framework plus a library as big as TinyMCE when I could use a framework with a small richtext editor based on it, YUI with their richtext editor for example.

For non-framework users this might not work out that great. TinyMCE would have to provide something within the bridge to fall back on, increasing filesize. That could be solved offering non-framework users the smallest compressed framework within TinyMCE, maybe even stripped down. I’m sure it will help to make TinyMCE smaller and a lot more attractive for everyone.

Comment by Nick — November 2, 2007

Spocke, I’ve been using TinyMCE for quite a long time now, rewritten many of the plugins and added my own, out of my own experience, I would definitely recommend using Prototype as a core library and rebuilding Tiny around it. That’s what I basically did with all the plugings I’ve rewritten. In many cases I’ve reduced size by 60% and bridged different Browser issues TinyMce doesn’t address. I agree with Nick, that taking this route is the next logical step.
jQuery might not be the right choice for this type of project, but Prototype definitely is.
Ran

Comment by Ran Baron — November 2, 2007

So cool. We’ve already upgraded the editor for our open story community on http://www.writeopenstory.com using new version of Tiny MCE. In the past, we used Tiny MCE version 2.1.2 and it takes time in Javascript loading at the first time. Now the performance is improved more, faster.
Thanks Tiny MCE team.

@Nick and Ran: Yes, we will need to provide a base API within TinyMCE like we currently do for non framework users. But when TinyMCE gets used with a library the portions of the API could be bridged so then we might reduce the script by removing the base API functions that got bridged this would result in a smaller script size. We will look in to this idea for some future version possible 3.1, but we first need to get the base API stable before adding new stuff in. :)

Looking at the TinyMCE source for the first time, jQuery would cover these functions for you:
init() browserchecks, each(), map(), filter(), indexOf(), extend(), trim(), addUnload(), removeUnload(), JSON, cookies, AJAX, getRoot, select, add, create, createHTML, remove, find, set- + getStyle, set- + getAttrib, parseStyle…ok all the DOMUtils, the DOMEvents, scriptloader, UI control, show, hide, getClasses… I would say about a third of the code.Now, if TinyMCE is 125K minified, 1/3 of 125K = 41K, or about the same size as all of jQuery minified. The TinyMCE serialization code looks to be a small part of the script, the UI is by far the largest.
I think jQuery’s filesize would be a big advantage.
From Googling, it’s clear many developers are using jQuery + TinyMCE together already, why not combine them? I may take this on as a project depending on the direction my new client is headed. jQuery would definitely be a good fit.

@Charles: The same could be said for Prototype, YUI, Mootools or any of the mayor frameworks. They all have the functions you mention, but with different names. Idealy you’d support all the mayor libraries instead of just one.
A smart bridge like Spocke mentioned feels like the best solution, it’ll get rid of unused garbage you would get by just putting this under Extjs, jQuery, Prototype or whatever. I’m looking forward to seeing how this will develop in future versions.

Comment by Nick — November 2, 2007

The difference between refactoring this RTE with Prototype and jQuery is that the filesize would be less than what it is now combined with jQ. When people user Prototype, they generally also throw in a lot of Scriptaculous resulting in a file size that’s 200kb+. jQuery is 20kb compressed/gzipped and I’m betting would reduce Tiny’s filesize by atleast half. Even if you’re a Prototype user, jQuery plays nice with other frameworks and the end result is still a smaller filesize for you, regardless.

This may also be something I may look into if the Charles doesn’t do it.

Comment by Mauvis — November 2, 2007

@Mauvis: You don’t need effects for refactoring. Besides that, throwing in the entire Scriptaculous library instead of just the effects part of it is like throwing jQuery UI in besides jQuery, except you get a lot more effects. When you compare filesize vs. functionality both frameworks have about the same amount of functionality, just different syntax.

Comment by Nick — November 3, 2007

@Spocke,

I am glad you don’t rely on a third party library, and I hope you keep it that way. I don’t use jQuery, and I don’t want to. The fact that you keep TinyMCE self-contained is a big plus for me, and load time for 41K is no big deal because there is such a thing as client cache.

I hope you resist the call from this group or that group to use _X_ library, because it’s the *best* library ever. The fact that I can drop TinyMCE into a site without any changes or external dependencies is perfect.

TinyMCE will continue to be framework independent. But the file size might be reduced for those who use these kinds frameworks. Anyway, I just added some proof of concept adapter logic for jQuery and Prototype and it seems to work just fine. Not that much gain yet about 1k for jQuery but it shows that it can be done so if someone feel up to the task of helping out with these adapters send me a mail so we can discuss it.

It’s quite a lot of work writing a syntax highlighting source view and most of those I’ve seen else were has major issues like incorrect syntax when users paste code since it doesn’t know that it needs to reflow the code etc.

But it should be fairly easy for you to plug one of those external code editors in to the source view. The source view page is one of the most simple dialogs in TinyMCE.

@ajaxus, I have implemented this new version and with the help of the packer it is “only” a 82kb gzip load with every single bundled feature, so I’m sure this could be cut down.

But this post could not of came at a better time, as I was going crazy with the old wysiwyg editor that we were using, and tinymce3 just works… I love it… – This is from a developers point of view, I couldn’t care less about using it for content.

Hi, After using new beta version of TinyMCE. I found a bug.
When I open the HTML view and paste embed code (to embed multimedia) from youtube or from other sites, click update, it always shows the empty screen.
Please help me to fix that, or I have to wait until it release the official version ?

@Speednet I second that, please don’t bundle TinyMCE with another toolkit. My app is written in Dojo since I need a lot of custom widgets. I don’t think Dojo is for every project though, and am not recommending TinyMCE uses Dojo. But, if TinyMCE starts using Prototype or Scriptaculous by default, then I would be forced to stay with the TinyMCE 2.x line.

@Spocke Your idea of adapters seems like the way to go, each toolkit has its use in different places and meets different needs. TinyMCE is used accross hundreds of systems, so choosing one toolkit would be impossible. Your doing an amazing job with something quite difficult. Looking forward to the 3.0 line. Keep it up!

Comment by tomgruner — January 6, 2008

i apply TinyMCE for most of my text editor – but when moving to SilverStrip CMS – it seems to limit some functions such as text colour, css style and so on…