Live data from Hacker News

WYSIHTML5: A better approach to rich text editing

xing.github.com

1–10 of 82 posts

WYSIHTML5: A better approach to rich text editing

#1
Open source rich text editor based on HTML5 and the progressive-enhancement approach. Uses a sophisticated security concept and aims to generate fully valid HTML5 markup by preventing unmaintainable tag soups and inline styles.

Twitter Bootstrap Plugin: http://jhollingworth.github.com/bootstrap-wysihtml5/

WYSIHTML5: A better approach to rich text editing
xing.github.com

Re: WYSIHTML5: A better approach to rich text editing

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

Re: WYSIHTML5: A better approach to rich text editing

#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?

Re: WYSIHTML5: A better approach to rich text editing

#6
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?

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.

Re: WYSIHTML5: A better approach to rich text editing

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

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!

Re: WYSIHTML5: A better approach to rich text editing

#8
post #7
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.

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!

Pah! "Just paste the table in from Word".

...and let the hilarity commence.

Re: WYSIHTML5: A better approach to rich text editing

#10
On a side note, it's worth mentioning W3C has a working group to standardize in-browser HTML editing (http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html).

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.

Post reply on HN