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)
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...
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?
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.
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?
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.
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.
