

Aloha Editor - HTML5 WYSIWYG Editor - mweibel
http://www.aloha-editor.org/

======
pak
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.

~~~
thousande
TinyMCE has a ribbon theme that seems to work with the latest TinyMCE version,

<http://tinymce.swis.nl/>

------
wladimir
Looks very promising.

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.

~~~
ZoFreX
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.

~~~
draftkraft
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.

------
abend
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.

~~~
draftkraft
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...](http://dev.w3.org/html5/spec/Overview.html#user-editing-actions)).
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...](https://github.com/alohaeditor/Aloha-
Editor/blob/dev/src/test/unit/editabletests.js) 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?

------
PeterMcCanney
I had some interesting problems with this in chrome. And by interesting I mean
it became functionally useless very quickly.

It is a great idea and I see where they're going but it ain't there yet.

------
BonoboBoner
Would love to add this to my app, maybe someday someone builds a clone under a
less restrictive license.

------
mixonic
Having written an editor on contentEditable before, I think the biggest
challenge is paste events.

[http://stackoverflow.com/questions/3553041/how-can-you-
catch...](http://stackoverflow.com/questions/3553041/how-can-you-catch-a-
contenteditable-paste-event)

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!

~~~
rkwz
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>.

[1] I don't know where I read about this. Sorry.

[2] <http://cloud9ide.com/>

[3] The IE behavior is similar to MS Word.

------
rjd
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.

------
tintin
The website is so full of hyped words I don't trust it. Advanced doesn't mean
better. And I think this could be done years ago without HTML5.

But it is looking nice! Inline editing is very useful!

~~~
draftkraft
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.

------
oreilly
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

------
alecbenzer
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.

------
foxylad
I can't work out how to insert images. And although it implies it works with
all browsers, it would be good to know which versions.

~~~
mweibel
Just drag'n'drop an image from your desktop into the page. At least it worked
for me ;)

~~~
rsoto
Well, yes, it works, but there isn't an upload process, so I thought the image
is linked to your local drive-- which is useless.

In closer inspection, the image gets transformed to a base64 encoding
(data:image/gif;base64,[...]) which is useless in this context.

~~~
mweibel
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.

~~~
draftkraft
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)

------
vertice
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.

~~~
jules
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.

------
AlexC04
That has really improved since the last time it was posted here. I'm blown
away by this full page editor option.

<http://www.aloha-editor.org/demos/3col/>

~~~
draftkraft
:) We did another sweet cube <http://www.aloha-editor.org/demos/cube/> (works
only in Chrome and Safari right now) Feel free to extend
<https://github.com/alohaeditor/The_Aloha_Cube> :)

------
jules
Excellent work! Small problems:

\- Undo doesn't work for style changes

\- Selecting text and changing to heading still changes the entire paragraph
to heading

~~~
draftkraft
@1 Did you use the <https://github.com/alohaeditor/Aloha-Plugin-Undo> to test
undo? If not you just test the default browser implementation which breaks
whenever an app modifies the content...

@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.

~~~
jules
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?

------
netghost
Can anyone compare this to the other existing wysiwyg editors? The only thing
I could identify as being unique is the floating toolbar.

~~~
draftkraft
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...](https://github.com/alohaeditor/Aloha-
Editor/blob/dev/src/lib/util/dom.js)) 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.

------
CoryMathews
"Sorry your browser is not supported at this time"

Really Opera, a modern html5 compatible browser "is not supported"?

~~~
draftkraft
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.

------
ams6110
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.

