Twitter Bootstrap Plugin: http://jhollingworth.github.com/bootstrap-wysihtml5/
WYSIHTML5: A better approach to rich text editing
xing.github.com
1–10 of 82 posts
Twitter Bootstrap Plugin: http://jhollingworth.github.com/bootstrap-wysihtml5/
WYSIHTML5: A better approach to rich text editing
xing.github.com
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?
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.
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.
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.
If I could +1 this a million times... that's the number one feedback I receive from CMS users in commercial environments. Please make it convenient for them to create tables!
...and let the hilarity commence.
The spec is still not settled, but safe to use as a guideline for an implementation. If libraries align their command API implementations with the specs, it would be easy for them to port to use native commands as the browser support gets strong.