Very nice. We discussed a lot whether to use the same approach on text editing when working a project of ours called Quabel. In the end, we went even further with a pure DOM-based editor (via contenteditable) and no hidden . However, we encountered lots of cross-browser issues because of the differences in contenteditable behavior when using FF / Chrome / Opera and later dropped contenteditable alltogether. I chuckled when noticing the odd editor behavior when pressing backspace at the beginning of a list item because we had exactly the kind of oddities.
WYSIHTML5: A better approach to rich text editing
11–20 of 82 posts
Re: WYSIHTML5: A better approach to rich text editing
#12Whenever 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.
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...
Re: WYSIHTML5: A better approach to rich text editing
#13Whenever 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.
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.
Re: WYSIHTML5: A better approach to rich text editing
#14I desperately want this as a Wordpress plugin.
Re: WYSIHTML5: A better approach to rich text editing
#15“(…) It uses a sophisticated security concept (…)” —Does anybody know what does this mean? Does this concept have a name, a description or anything?
Re: WYSIHTML5: A better approach to rich text editing
#16Wouldn'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?
Depends on the use case. If you are using it in as a website authoring tool, it makes sense to store the rich-edit user input as HTML itself. However, in a scenario like commenting or composing a message (where only limited editing options are available), storing in a format such as Markdown make sense.
Are you aware of any such editor that does store the data in Markdown or something similar?
Re: WYSIHTML5: A better approach to rich text editing
#17Whenever 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.
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...
Aloha is more than a meg of JS as it stands and the documentation is pitiful.
Re: WYSIHTML5: A better approach to rich text editing
#18IE in browser support: IE8+
yay ;-)
Re: WYSIHTML5: A better approach to rich text editing
#19“(…) It uses a sophisticated security concept (…)” —Does anybody know what does this mean? Does this concept have a name, a description or anything?
As far as I can tell, it's referring to the sandboxed iframe.
Re: WYSIHTML5: A better approach to rich text editing
#20The only way to add an image is to enter a URL? An upload feature would be great, most of my sites / clients require it.