Aloha Editor - HTML5 WYSIWYG Editor • Hacker News Board

Re: Aloha Editor - HTML5 WYSIWYG Editor

#31

Post by draftkraft » Tue, Aug 02, 2011, 10:48 PM UTC

jules wrote: post #24

Excellent work! Small problems: - Undo doesn't work for style changes - Selecting text and changing to heading still changes the entire paragraph to heading

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

Re: Aloha Editor - HTML5 WYSIWYG Editor

#32

Post by draftkraft » Tue, Aug 02, 2011, 10:51 PM UTC

AlexC04 wrote: post #18

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/

:) 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 :)

Re: Aloha Editor - HTML5 WYSIWYG Editor

#33

Post by draftkraft » Tue, Aug 02, 2011, 11:02 PM UTC

netghost wrote: post #22

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

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.

Re: Aloha Editor - HTML5 WYSIWYG Editor

#34

Post by draftkraft » Tue, Aug 02, 2011, 11:09 PM UTC

mixonic wrote: post #4

Having written an editor on contentEditable before, I think the biggest challenge is paste events. http://stackoverflow.com/questions/3553041/how-can-you-catch... 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…

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

Re: Aloha Editor - HTML5 WYSIWYG Editor

#35

Post by ams6110 » Tue, Aug 02, 2011, 11:31 PM UTC

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.

Re: Aloha Editor - HTML5 WYSIWYG Editor

#36

Post by jules » Tue, Aug 02, 2011, 11:47 PM UTC

vertice wrote: post #26

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.

Re: Aloha Editor - HTML5 WYSIWYG Editor

#37

Post by jules » Tue, Aug 02, 2011, 11:58 PM UTC

draftkraft wrote: post #31

jules wrote: post #24

Excellent work! Small problems: - Undo doesn't work for style changes - Selecting text and changing to heading still changes the entire paragraph to heading

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

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?

Re: Aloha Editor - HTML5 WYSIWYG Editor

#38

Post by oreilly » Wed, Aug 03, 2011, 4:14 AM UTC

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

Re: Aloha Editor - HTML5 WYSIWYG Editor

#39

Post by draftkraft » Wed, Aug 03, 2011, 6:23 AM UTC

foxylad wrote: post #3

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.

Maybe we did not link the information properly. You can find the supported versions here:

http://aloha-editor.org/wiki http://aloha-editor.org/wiki/Browser_Support

Re: Aloha Editor - HTML5 WYSIWYG Editor

#40

Post by draftkraft » Wed, Aug 03, 2011, 6:25 AM UTC

mweibel wrote: post #21

rsoto wrote: post #16

Earlier quoted context omitted.

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.

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)