If you're looking for a Rich Text Editor, this is the only one I will recommend. I wrote a proprietary RTE last year and continue to maintain it because nothing available both worked and produced clean markup. Redactor came out this spring and is the only generally available RTE that does this. If you insist on OSS, WYSIHTML5 is the best available.
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.
I really like Redactor and am considering switching to it from wysihtml5, but the one thing that has been holding me back is the design of the modals for things like editing links. I really wish they were more easily customizable because they look nothing like the design of my site. For example, I put the cancel button on the left and the ok button on the right and I use bootstrap to style it all. Redactor uses a link for cancel and switches the button order. I know this is a small complaint, but keeping consistent design is good design.
I'm curious why you decided not to use Aloha Editor, since it is also able to produce clean markup. Disclosure: I'm one of the Aloha Editor developers.
Hi deliminator! The Aloha Editor is great. I was poking around in your source the other day and noticed that it doesn't seem like it's received much active development for the past few months. Is it at a stage where you expect future changes to just be bug fixes, or is there still active development planned?
Just curious. Thanks for providing a great tool to the community!
The latest big development was porting the UI from ExtJs to jQuery UI. This had some benefits concerning licensing and code size.
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.
Before the GPLv2 we had the AGPL, which made it explicit that you had to divulge any server side code.
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.
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.
I was indeed referring to the famously linked response, but also expressing my astonishment that such a thing is even necessary. Not familiar with that topic at all, so pardon my ignorance.
> astonishment that such a thing is even necessary
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).
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 live in southern california though... I wonder if they help out with relocation? I'll shoot my resume over.. I dig the site it looks fresh and a good service..
Doesn't normalize enter to BR and I haven't managed to break it. WYSIHTML5 works for normal use cases and produces nice markup but if you mess around with multiple overlapping inline elements or the two lists and indent/dedent enough you'll wind up with very bizarre markup.
I think one of the biggest things I see is the ability to handle uploads/handling of images inline of your content. You still have to provide the server side implementation (see http://paltman.com/2012/08/15/how-to-setup-upload-handler-fo...) but having the ability to browse previously uploaded photos, as well as upload new ones, and have them appear inline with your content with resize handles, is pretty nice.
I'm currently using both of these and they are both a bit of a mess. Don't waste your time with either of them unless you want to spend a ton of time fixing them or you just have really basic requirements.
wysihtml5 just doesn't work well, is missing a ton of features and the developer isn't really spending much time fixing issues with it. 71 open issues and 11 pull requests isn't a good sign imho.
For bootstrap-wysihtml5, I had to override quite a bit of the insert link functionality to get it to do some basic stuff with regards to handling the modal, focus and enabling/disabling buttons if things change. https://gist.github.com/3889641
Very cool. Also worth noting these guys have a CSS framework (who doesn't these days?) that looks similarly clean and elegant, though I didn't dig into it enough to make a truly informed call. But still, worth noting...
Meaning: Maybe we can have a rest from chasing after the 'technology of the week(tm)' and simply get things done without having to dig through yet another framework.
I notice that still a lot of editors use inline css for their image-styling (I assume, since the editor should correctly preview the way images are lined up). But this obviously creates problems when you decide to style such images a bit differently (adding some padding, whatever) without modifying tons of generated content. A centralized css declaration would make this much easier.
Wouldn't there be a possibility to put these styles in an external stylesheet? As the editor itself makes use of external css for it's own styling, adding a new stylesheet for the elements it creates would not be very difficult, right?
I'm sure this is conscious practice that is done with a purpose in mind. I'm only unaware of its explanation.
Also: I noticed that Redactor uses italic-tags (<i>) to style text as italic. Isn't this bad practice in terms of semantics?
Then there is also my Hallo Editor, which is open source and uses contentEditable http://hallojs.org/
If you're using Create.js for making your stuff editable, it has editor abstraction that can drive Aloha, Hallo, and Redactor based on your configuration
TinyMCE, CKEditor, CuteEditor, etc. There are over 60 public popular WYSIWYG web editors, about half of them are mature and free. Why would someone want to move to this, when it is fairly new and also not free?
We're a happy paying customer of Redactor. Can't tell you how much we love it. It's literary the PERFECT WYSIWYG editor. Highly recommend you try it if you're looking for a fast & beautiful editor.
I love Redactor. I use it for an internal project and its easily the best compared to TinyMCE and others. Its clean, produces clean markup (you don't get random empty HTML tags like <strong></strong>..text) with no inline-styles.
A few things I can't seem to see how to do (that I can do with TinyMCE):
1. Define some CSS classes that I want to be available to the user (I'd never give colour and font controls to my users unless I wanted my lovely site design to end up full of bright-pink 42pt comic-sans)
2. Supply a list of already-uploaded images
3. Supply a list of internal links to the 'add link' dialog
4. Resize handles for images (or even better - some preset sizes) - I process WIDTH and HEIGHT server side and replace the image with one resized on the server.
5. Allow a couple of CSS classes for images (although I had to hack MCE to allow this)
#2: Looks like the Insert Image dialog has a list of images that have already been uploaded.
#4: There are no handles, but in Chrome 22 on a Mac at least I can drag anywhere in the image to resize.
The CSS classes/styles are the reason I'll probably stick with CKEditor for now. As cumbersome as CKEditor is overall, I can't lose the ability to add styles that my non-technical clients can choose from when editing their websites.
I would probably move HTML button to the far right of the menu and maybe get rid of strikethrough. Also, the P, H1, etc dropdown menu icon didn't immediately make sense to me. But those are all minor gripes -- this is really, really nice work. Congrats.
The Amazon S3 support seems to suggest that the authors believe it is acceptable to store your AWS key ID and "secret" key in your client-side JavaScript code. Am I missing something here?
What you're missing is that the secret isn't present. What's there is a policy, which is a way to preauthorize file uploads to S3. The policy is signed with the secret key ahead of time. It looks to me like all the fields in that form are safe to be exposed publicly.
The first thing I tried to do (in current Firefox) failed: select text over two paragraphs, change text colour. The selection then changes. Not a great start.
That was my first thought as well. For better or worse, I love MooTools and vastly prefer it to jQuery. It's the occasional time like this whene I have admit there's a cost to picking & sticking with the way less popular framework.
MooEditable is pretty good, but I'd plunk down the cash to swap this one in in a heartbeat.
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.