Hacker News Reader

Comment by kiwidrew | Hacker News Reader

I found a more detailed look at Aloha on Slideshare: http://www.slideshare.net/draftkraft/aloha-editor-contentedi...

In particular, there are some screenshots which show table editing, insertion of images, and what appears to be navigation and forms as well. My favourite, though, is on page 37, where it looks like some user-defined paragraph classes ("info" and "alert") have been included in the formatting toolbar -- it looks _really_ slick!

There's at least one other project which is trying to make editing web content better: http://www.wymeditor.org/

I recall reading that, due to the way that WYMeditor makes the HTML structure explicity (while still keeping it relatively end-user-friendly), it tends to encourage users to produce "nice" HTML -- simply because poorly-structured HTML looks ugly in WYMeditor. :)

But wow, Aloha looks absolutely beautiful! The sooner FCKeditor and tinyMCE die, the better off we'll all be.

View on HN

CKEditor and TinyMCE have solved a very difficult problem in extremely elegant ways; their developers deserve more respect than wishing their projects death.

Both of those editors rely on the contentEditable support of the browser to power the actual editing, and browsers have traditionally done a very poor job at producing valid HTML. They make attempts at "post-validation" and "attribute scrubbing", but these are at best makeup on a gorilla. I certainly wouldn't call their solutions elegant.

Having worked on numerous content management systems in the past, one of our biggest issues was trying to "lock down" the WYSIWYG editor so as to minimize the chances that clients could inadvertently break the layout when editing. It was a huge pain point for us, and I lost count of the number of times I had to go in and fix broken pages.

I'm very glad to see that the state of the art in HTML editing is moving forward, and it's well past time for CKEditor and TinyMCE to be put to pasture, IMHO.

Same problem here: the one feature that all these editors lack is the ability to restrict what kind of formatting that the users can create.

In a system I've created for a client, some users are allowed to use e.g. bold and italic, but most users aren't (because they would go overboard and make every other word bold). Post-scrubbing the edited html often breaks the editing experience, and browsers have lot's of bugs in contenteditable.

Hi all, we try to address this issues (bugs of the browsers and functionally to restrict to defined formatting) with Aloha Editor. For ex. we have more than 80 unit tests for the ENTER button. One of those is hitting the ENTER in a H1 Tag. The current is a release in an early development state and we want to focus on reliability and basic functionality (be able to write without errors) in first step.

Reply on news.ycombinator.com