Live data from Hacker News

WYSIHTML5: A better approach to rich text editing

xing.github.com

51–60 of 82 posts

Re: WYSIHTML5: A better approach to rich text editing

#51
post #4

Wouldn't it be more desirable to have these WYSIWYG editors serialize to a non-HTML markup (like textile or markdown) to reduce the hassle of user-input sanitization on the back-end? (e.g. stripping script and iframe tags). What's best-practice these days for storing and displaying rich-edit user input?

If you are going to manipulate the document structure on the server, JSON might be an alternative. There is an interesting project on Github that does HTML -> JSON conversion: https://github.com/gregory80/fastFrag

Re: WYSIHTML5: A better approach to rich text editing

#52

Feature request - ability to add 'notes' to a document. I'd imagine these as toggleable divs that would be able to be inserted anywhere in the doc, then made visible or not by toggling a class. When 'on' the visible portion would just be a small box/space/marker that, when clicked, opened up a larger div with the full note. I'd tried to do this with the YUI and Dojo editors a couple years ago, but my JS-fu wasn't goo…

This seems like it would be beyond the scope of the project (to provide a simple rich text editor.) It should be very easy to add some sort of inline commenting/review system in your own application.

Re: WYSIHTML5: A better approach to rich text editing

#53
post #13
post #12

Earlier quoted context omitted.

Aloha handles Tables perfectly (including merge/split of rows & columns, plus pasting from Microsoft Word). Check the demo - http://aloha-editor.org/builds/development/latest/src/demo/b...

Looks nice, but the Aloha licensing basically requires you to buy a license if you're going to use it commercially, whereas this one uses the very simple and open MIT license.

Furthermore, I've been trying to get them to sell me a commercial license for months. Someone sometimes emails me back, but they have yet to give me a way to give them money.

Re: WYSIHTML5: A better approach to rich text editing

#54
wysihtml5 is a decent editor. It's fairly lightweight in comparison to the other editors. I feel that its approach to DOM changes makes it easier to create cross-browser consistency. However, I feel the event system could really use some work and I find myself working against the editor to add new features. I would prefer if the framework made it easier to add new features rather than having to change the core to get the desired result. (and maybe I just need to spend more time with it.)

Oh, and I should add that the built-in parser isn't very flexible and requires lengthy configuration.

Re: WYSIHTML5: A better approach to rich text editing

#57
post #54

wysihtml5 is a decent editor. It's fairly lightweight in comparison to the other editors. I feel that its approach to DOM changes makes it easier to create cross-browser consistency. However, I feel the event system could really use some work and I find myself working against the editor to add new features. I would prefer if the framework made it easier to add new features rather than having to change the core to get…

Could you go into a little bit more detail on how you think it compares to other editors?

And more specifically: what are your thoughts on the Aloha editor?

Re: WYSIHTML5: A better approach to rich text editing

#58

We really need to escape the tyranny of the browser "design mode," with all its quirks. These RTEs are really lipstick on a pig, sadly. Does anyone know of a JavaScript RTE that does all the text layout and formatting itself using pure JS?

The RTE for Google Docs is written in Javascript, bypassing design mode:

http://googledocs.blogspot.com/2010/05/whats-different-about...

The code isn't officially released anywhere, but someone grabbed the source, prettied it up, and put it up here: https://github.com/benjamn/kix-standalone Obviously you can't use it for anything without a proper license.

Re: WYSIHTML5: A better approach to rich text editing

#59
post #54

wysihtml5 is a decent editor. It's fairly lightweight in comparison to the other editors. I feel that its approach to DOM changes makes it easier to create cross-browser consistency. However, I feel the event system could really use some work and I find myself working against the editor to add new features. I would prefer if the framework made it easier to add new features rather than having to change the core to get…

Could you go into a little bit more detail on how you think it compares to other editors? And more specifically: what are your thoughts on the Aloha editor?

The problem I have with most editors is that they try to be like a piece of desktop software. "Install me and get all of these features including themes and plugins." That's not what I want. I want an API. I want a consistent cross-browser approach to wysiwyg html editing that doesn't weigh in at 200+k minified.

What does Aloha come in at? (Web Inspector is telling me 1.6MB!)

I haven't used Aloha but my impression is that it's trying to be like all the other editors like TinyMCE or CKEditor.

wysihtml5 is lightweight, which is nice. It provides a command API so that I can wire up commands to my own toolbar and provides state management. But I don't like that some built-in commands don't offer up enough externalization, like autolinking. Or that I can't cancel an event like beforecommand. beforecommand doesn't even tell me what command is being fired. (or if it does, I couldn't find out how.)

Re: WYSIHTML5: A better approach to rich text editing

#60
post #3

Whenever I see "new rich HTML editor", I notice that there is no table editing. What's the point of editor that is missing the most needed function? You could argue that it is not needed, however lack of this function leads to cases of copy-paste from word/excel with bad markup.

Copy and pasting tables from MS Office is the most needed feature? I don't know whether to raise my eyebrows or feel bad for you.
Post reply on HN