http://cdn.aloha-editor.org/latest/lib/aloha.js 1.1MB!
http://imperavi.com/js/redactor/redactor.js 168KB (odd, it is an encrypted version)
The actual minified 8.1.0 version that you get after giving them a fake email address is 41KB.
I expect the size would be around 300KB if only the basic plugins are included.
Still, it's a lot bigger than redactor - point taken.
Just curious. Thanks for providing a great tool to the community!
Drupal is interested in integrating Aloha, and we are currently discussing several improvements that would be necessary for them. Have a look at the issue tracker. I think the UI À la carte and accessibility will be the next big user-visible developments.
Now, with the GPLv2, it is possible to use Aloha freely in most websites/webapps. You don't distribute your website/webapp and therefore are not bound by the GPLv2 to divulge your website's source code.
The GPLv2 _would_ take effect if you distribute your website in the traditional sense - a package that someone can run himself.
(IANAL and can't speak for Gentics etc.)
wait what?
Is so - remember we aren't necessarily trying to parse HTML. You could probably fix most of the things that are likely to get screwed up by various browser quirks in ContentEditable.
It's necessary because there's a impedance mismatch between editing rich text and generating markup. Text editing works on text ranges while DOM manipulation works on trees. There's also behavior that you expect in an editor that isn't the default in markup like leaving empty paragraphs when you hit enter. Then there's the app-specific logic like what parts of pasted text you want to keep and what to pitch and what you want the markup to look like. Browsers also tend to toss in random <br> tags and style attributes. So that's why you want to start messing with the browser provided behavior.
If you don't go with simple markup and regexps for the fixup or you want to provide capabilities beyond what's available in the execCommand then you need to deal with the Range API.
Rant time!
The DOM 2 Range API which is far and away the worst API I've ever used in my life. You only want so many things from a Range api: the ability to select text, the ability to determine what's selected, and the ability to manipulate the selection.
For the first, you can do it but the offsets are dependent on node and offset which can be a text or child node offset and you must check the node type to distinguish between the two. This representation, naturally, does not persist when you're doing DOM manipulation. This is the best part of the API.
For the second. You can't actually get the selected DOM nodes. You can get the text using .toString(), you can extract or clone the nodes so you can mess with them in a doc fragment but you can't get at the live nodes in the DOM.
Next, determining equality of ranges–which is useful for figuring out when one range is in another so you can, say, invert the range–is tricky. See the illustration [1] in the spec. Ranges 2-4 in the illustration are, in terms of both visual appearance and text selected, equal but they do not compare as equal. It's actually possible for any permutation of the start and end points in the illustration to be what your users would consider an identical range. This illustration is simplified. In the real world, whitespace nodes in the DOM create an additional 4+ equivalent points that are identical. This isn't academic. They all happen in different permutations in different browsers depending on how the user selects text (start to end, end to start, double click, triple click, etc).
[1] http://www.w3.org/TR/DOM-Level-2-Traversal-Range/images/Rang...
The third part, manipulation, works mainly by inserting a DOM node in front of the startContainer, extracting the selection, and then sticking it in the DOM node. Requires special handling for selections crossing block nodes due to HTML containment rules. Generates wonderful stacks of empty nodes depending on where the range is when you slice. Breaks the browser's native history stack.
So that's why writing a quality RTE in the browser is harder than you might think. There are other issues like cross-browser normalization, bugs like webkit not displaying the cursor when the cursor is in an empty element but the Range API is the big one.
I wonder if all of this will one day be replaced with a canvas-based RTE.
I was messing with it last week and looks like I broke list handling.
What do you guys use on the backend?
For those that care, Redactor uses the designMode technique, leans on the browser for most operations and keeps the markup clean via regexp cleanup. This is the cleanest solution for the most common use case of html email/html item entry. The other two techniques are full emulation and contenteditable.
Google uses full emulation in their products. You type into a hidden text field and the display/selection/cursor is entirely script rendered. This is especially good for things like docs where they need to emulate word's behavior. Downside is that doing it is a lot of code and it's easy to miss OS specific keybinds (e.g. CMD+left/right in OS X don't work in gmail).
Using contenteditable would be the preferred technique but it's buggy as hell. Of the editors I know about only Aloha and my editor take this approach. The amount of code is relatively small (mine is around 2k sloc) but it's all really ugly code that reminds me of the bad old days in 2002-2004 when I had my own DOM abstraction lib.