Pretty slick--have to say I enjoyed the big mouse cursor coming up and editing the top paragraph, that was rather clever.
In trying the demos, it behaved rather unobtrusively and flexibly, and despite looking a little like Word's contextual ribbon it didn't make me want to set anything on fire after a few minutes. That's a first for an in-browser rich text editor.
I think it's interesting that "old" rich text editors like TinyMCE/FCKEditor tried to copy Word 2003 right down to the massive toolbars, and then barely anybody needed all that crud so it fell out of fashion in newer, slim designs (e.g., StackOverflow, Quora). Nowadays, it appears that Word 2007/2010 has finally gotten enough mindshare for the ribbon/contextual palette model that it's finally being comfortably re-implemented as a web UI widget.
One thing I wonder, though, is why WYSIWYG editors still use explicit markup (bold, italic, font size) instead of allowing the definition of styles. This is a hassle if you want to write consistent documents.
Even Google Documents does this; it does not have custom named styles like Word. It only has named styles for header 1..6, but usually that's not enough.
This is great input, the named styles are my absolute favourite thing about Word. One of my other peeves with almost all WYSIWYG editors is that they default to line-by-line editing, and generally avoid exposing paragraphs as a first-class construct. In both Word and HTML, treating content as paragraphs makes things more predictable, stable (in terms of layout), and easier to understand IMO.
Aloha Editor uses paragraphs as first class construct. The https://github.com/alohaeditor/Aloha-Plugin-MetaView plugin gives you a nice outline view of the used dom elements to understand the semantics. Using tags for formattings like b and i seems a good choice to me as it is the suggested formatting tag for visual bold or italic presentation in HTML5. Other formattings like (indent, etc) could be implemented as css classes, but this could cause problems when copy/paste content from on site to another as the css classes may not expose the same way. This could lead to unwanted behavior because the normal users will understand the reason.
There's some problems with this editor still and there's very few updates or comments in the forums, to the point where it seems like a dead, inactive project.
".mahalo()" which is the destroy method is non-functional in the current release, even though it in the documentation. Artifacts from pasting and x-browser is a bitch too. It looks promising, but it ain't ready for primetime, and don't expect get much support either.
I am sorry if you feel that there is few reaction on the forum. We try to improve that. If you have a look at https://github.com/alohaeditor/Aloha-Editor/commits/dev/ you will notice that there is a lot of action going on and we are hard working on providing a better user experience with the beloved contenteditable. The probably most painful part of HTML5 spec and browser implementations.
The HTML5 spec unfortunately is very unclear in most cases ("the behavior is UA-dependent" - http://dev.w3.org/html5/spec/Overview.html#user-editing-acti...). Eg. "Break block" is defined with 2 sentences, where we have more than 80 test cases and are far from complete https://github.com/alohaeditor/Aloha-Editor/blob/dev/src/tes...
Though the next release (in a few weeks) should bring a better experience.
PS: mahalo() should work even with the very old stable version 0.9.3. Could you point me to a implementation where it doesn't work?
The onpaste event isn't supported across the board, and doesn't let you access the paste content in any way.
Just try copying a webpage and posting it into the Aloha Editor area- it will paste the entire dom. Blech. contentEditable should be a boon for web devs, but instead the idea of a writable web has stagnated on a buggy, inconsistent implementation of contentEditable.
I'm looking forward to the next iteration of editable html content!
This can be solved to an extent by the "invisible text area"[1] trick. Here, whatever text is inputted or pasted goes directly to an invisible text area. And from that it is appended to the CE div/iframe that's is shown to the user. I think Cloud9IDE[2] uses this technique.
That and the way every browser reacts to the enter key press. Firefox appends <BR>, Chrome appends <Div> and IE[3] appends <P>.
For Webpop (http://www.webpop.com) we ended up going with TinyMCE as our rich text editor after trying both CKEditor and WymEditor because Tiny was the only one that handled pasting into the edit area fairly well.
It's really tricky to handle right, and the Paste plugin for Tiny has to use a lot of tricks to do it properly. The onpaste event doesn't really work for this, because even in browsers that supports it, it just gives you plain text with no formatting. Same with a hidden textarea.
It's ok if you want to strip all styles, and then let your user go though and apply all the same styles from his Word document manually once again (frustrating!), but otherwise it wont cut it.
The paste plugin does a lot of browser specific stuff, but basically handles it by creating a contenteditable div and redirecting the paste event into that, then grabbing the horribly broken HTML browsers produce when pasting from anything and cleaning it off before moving it back to the place the user pasted too...
Agree contenteditable is not implemented consistently across the browsers and with Aloha Editor we try to reduce that pain... Did you test the most recent paste plugin? https://github.com/alohaeditor/Aloha-Plugin-Paste/tree/maste....
This plugin provides a methode to register paste handlers the clean the pasted content. Imho the MS word copy/paste should work quiet good in most cases. Unfortunately there are only few other handlers implemented yet, so coping HTML may remain unhandled...
I built an in page editor like this a few years ago. I took a completely different approach however. I used jQuery to parse the entire page as XML and the used some dom navigation to work out path locations to the node I was on. There are jQuery libraries which will select nodes via xpath queries.
Then with some string functions I managed to break each node down into text runs (just wrapping spans around text blocks) so that I could apply styles to certain segments. Preserved the whole document in valid XHTML.
Just food for thought if you feel like making the editing functions even more granular.
Agree. A lot of buss words... Does that make it untrustful to you?
Agree 2: It would have been possibile years ago, but would have been even more pain than it is now, where the browsers improved a lot because of the efforts Ian and his fellows at WHATWG did to write a spec (HTML5) the respects current browser implementations and tries to find a common ground for all major browsers. I think that this movement encouraged browser vendors to improve their implementations and make them more compatible.
Working out the licensing for this is quite the challenge.
It uses a duel licensing (AGPLv3 / Commercial) setup. How AGPLv3 applies to web applications is a significant grey area, and could imply an expectation that all javascript code of the application needs be AGPL also.
Answers in the forum are vague and no clear indication has been given to when a commercial license is is not required.
TL;DR: Want to use this in a web app? Pay for a commercial license or consult a lawyer
this seems interesting but I feel like it might not necessarily replace things like tinymce and ckeditor. this seems to blur the lines between the text you're editing and the page you're on, which can be nice for certain things, but for certain blogs and CMSs people might want a more traditional "here is the edit box: the text you type in here is what's going to appear on your blog/page/whatever" text editor.
With the new HTML5 file upload feature, there's the possibility that you don't see the upload process (although it may be not the best way to do it for bigger images).
Also, they're still working at the image plugin, so I think it will be improved.
As mentioned before we are working on the image plugin. We separated the functionality of uploading and image handling. You can find some information here http://aloha-editor.org/wiki/Drag%26DropFiles Bigger images can be resized on the client side and are then uploaded. (See the code sniplet at the bottom of that page)
After many years, the sad truth is that wysywig editors are only as useful as the output generated when users copy and paste from word documents, which is what I have found the vast majority of input from actual end users to be.
Not supporting wysywig is a tactical advantage in my book.
So not supporting pasting from Word at all, and then forcing Word users to learn something like markdown (no easy feat for the average computer user) is better than supporting pasting from Word in most cases, and letting them edit with a UI that they're familiar with?
I've gone the markdown route in the past, but recently also put a WYSIWYG editor in a project. The client was insanely happy that he and his employees didn't have to deal with teaching/learning markdown and converting Word documents to markdown anymore. Pasting just worked.
Probably the major difference is that Aloha Editor supports direct inline editing. You can edit dom elements directly without wraping the content in an iframe which leads to a different rendering (inline tags, css, etc). Further we did implement the HTML5 spec and a utility API (https://github.com/alohaeditor/Aloha-Editor/blob/dev/src/lib...) the helps implementers of plugins to write plugins that modify the dom in a HTML5 complaint way. There are some other new concepts available like "scopes" or "blocks". The floating for instance menu reacts on scopes like continoustext, link, image, table, tablerow, etc. You only the the interaction items that are availabe for that scope. That reduces the number of interaction item that are exposed to the user and still provide a huge amount of interaction items, where only the relevant ones are available at the right time. Block are non editable areas in editables which is a very common usecase for CMS systems. Blocks can be copy pasted, serialized and rendered async by AJAX calls from a backend.
@2 Actually right now this is the default behavior. Converting bolck elements (h1-h6, pre, p) always changes the whole block and does not split the selection. This could be changed in future.
I used the Try It page. It does support undo of markup when you do the markup with shortcuts (e.g. ctrl+b), but not when you do it with the menu. By the way, the menu often obscures the content, it is quite irritating at times. Have you considered changing the algorithm for moving it around?
Aloha Editor as well as Opera did improve since Aug 2010. At that time Aloha Editor v0.9.3 and Opera 10 did not work properly together. I did some debugging and improvements with Maike Tylor from Opera. The current dev version of Aloha Editor has the bad alert replaced with a console.log and Opera 11 offers better support for contentEditable. Due to the huge refactoring and at the same time major improvements and extensions the dev is not yet stable enough to be released. We expect a release within a month.
None of these WYSIWYG editors approach the ease, control, and flexibility one gets by just learning basic HTML and CSS. I get it that "users" won't do this, and that it's really not reasonable to expect them to. But as a developer, I abhor all of these.
In trying the demos, it behaved rather unobtrusively and flexibly, and despite looking a little like Word's contextual ribbon it didn't make me want to set anything on fire after a few minutes. That's a first for an in-browser rich text editor.
I think it's interesting that "old" rich text editors like TinyMCE/FCKEditor tried to copy Word 2003 right down to the massive toolbars, and then barely anybody needed all that crud so it fell out of fashion in newer, slim designs (e.g., StackOverflow, Quora). Nowadays, it appears that Word 2007/2010 has finally gotten enough mindshare for the ribbon/contextual palette model that it's finally being comfortably re-implemented as a web UI widget.