5 ms·
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
by grayrest 14y ago
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.
- deveshz 14y agoHey can you share the link of the RTE that you wrote. Interested to see that.
- grayrest 14y agohttp://squarespace.com http://squarespace.com I was messing with it last week and looks like I broke list handling.
- deveshz 14y agoAmazing site. All the best with the company!
- oceansize 14y agoyou own that company or work there? I need a job! I see you're hiring front-end developers... I think I'll apply tonight
- grayrest 14y agoI work there. It's a great place to work.
- oceansize 14y agoI 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.. What do you guys use on the backend?
- grayrest 14y agoSS6 is java (no framework), rabbitmq, mongo, memcached with node providing services like less compilation.
- esusatyo 14y agoThis is somewhat unrelated, but how did you change the scroll thumb colour in OS X ML in that site? All other pages have gray scroll thumb.
- sim0n 14y agoWhen the background-color of the <body> is dark Chrome/Safari use a lighter thumb colour (Squarespace has a background colour of #181818).
- deliminator 14y agoI'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.
- eob 14y agoHi 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!
- deliminator 14y agoThe 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.
- grayrest 14y agoPrimary reason was licensing. This was a year ago.
- deliminator 14y agoThe License was changed recently to GPLv2.
- grey-area 14y agoIsn't GPLv2 still problematic for websites, unless you want to use GPLv2 for the rest of the website as well?
- 14y ago
- KaoruAoiShiho 14y agoHow is this any better than WYSIHTML5?
- paltman 14y agoI 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-for-redactor/ 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.
- grayrest 14y agoDoesn'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.
- latchkey 14y agoI 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.
- VMG 14y ago> and keeps the markup clean via regexp cleanup wait what?
- andybak 14y agoWould you care to elaborate on your objections? I'm guessing it might be along these lines: http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 http://stackoverflow.com/questions/1732348/regex-match-open-... 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.
- VMG 14y agoI 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.
- grayrest 14y ago> 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). [1] http://www.w3.org/TR/DOM-Level-2-Traversal-Range/images/RangeExample.gif 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.
- andybak 14y agoWhat are the differences between designMode and contenteditable? I always assumed they were different names for essentially the same thing.