WYSIHTML5: A better approach to rich text editing

[tiff]

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/

[junto]

I'm using the Twitter Bootstrap styled version of this in a current project. It looks stunning: http://jhollingworth.github.com/bootstrap-wysihtml5/

[sundeep_b]

Cool! That's the first thing that hit my mind - how would this look in bootstrap? Thanks for doing and sharing this!

[laktek]

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.

[lunaru]

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?

[emn13]

I doubt Markdown, BBCode or anything similar is a good idea here. That's just introducing extra complexity - and what for? The point of markdown is that its simple for humans to read and write directly, which isn't applicable here.

The downside to markdown should be obvious:

* more code, both server and client-side (to implement the to-and-from conversion)

* more bugs (due to more code and the complexity of escaping valid input that happens to be markup in one or the other)

* less features (if the editor supports some html that doesn't map 1-to-1 to markdown, you're in trouble)

* less future-proof/platform independent (html isn't going anywhere, but that markdown variant you're using with the custom extensions you needed might be subtly different in whatever language/platform/toolkit you'd prefer in 5 years).

Html is by far the better choice. If there's an improvement to be had here, it's in using the (compatible) XHTML5 serialization to ease parsing. And it's quite likely already using that, since that's what browsers' rich-text-editing generally produces.

[brlewis]

If you would be happy with markdown, you'll be happy with a whitelist-based HTML sanitizer. HTML santization is only a hassle if you take the blacklist approach in an attempt to allow lots more than what markdown can do.

I've used antisamy, but there are many others and I don't know which is best. But I would call the whitelist approach in general, best practice.

[laktek]

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.

[geon]

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

[zv]

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.

[ams6110]

I have never seen a rich editor that handles tables well. In fact I've never seen a rich editor that does much of anything well. I almost always have switch to HTML view to get anything done.

[bergie]

I've been thinking about this a lot with Hallo (http://hallojs.org/), and I'm starting to come to the conclusion that the traditional way of doing tables in WYSIWYG editors is simply wrong.

What is a table editor would essentially be a database query, with data coming from your CMS or some other system? Then instead of building a generic table by hand you could do things like Insert a table of attendees of this event, with columns displayName, company, and email.

I'll try to do some experiments with this in the summer.

[laktek]

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

[middus]

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!

[drivebyacct2]

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.

[slikts]

Looking at the examples, I don't understand how this is "a better approach" to editing, because the HTML it outputs does not follow best practices. The HTML it outputs should look like a competent human had authored it, but currently it uses line-break hacks for paragraphs instead of semantic paragraph elements (two <br> elements aren't really a paragraph, it just looks like it), adds underline elements with Ctrl+U (these should be reserved for links and defined in stylesheets anyway) etc.

[TazeTSchnitzel]

Valid HTML5 markup? It's certainly not semantic. <b> should be <strong>, <i> should be <em>

[decklin]

You might want to take a look at this:

http://www.whatwg.org/specs/web-apps/current-work/multipage/...

[batista]

Only I don't want my text to be "strong", I want it to be bold, and I don't want my italicized items to me "emphasized", I bloody want them in italics.

I don't consider my bolds and italics to be mere style and much less I consider them mere suggestions.

Bold and italic are typographic conventions of author _intent_ (that is: semantics) with centuries of use. I put them there in purpose, and I don't want them converted to anything else via styling. Sure, someone can style "b" as "purple text with a yellow dotted underline", but I might as well make my _actual_ intention clear.

Outside of its proper context, "semantic" is just a BS notion that got popular with designers and co because it sounds sophisticated, giving rise to inane arguments similar to how many angels fit in the head of a needle.

[SquareWheel]

I like it a lot. It's fast, not bloated, and has a decent feature set. I could see myself implementing this.

[bflesch]

Very nice. We discussed a lot whether to use the same <iframe> 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 <textarea>. 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.

[cmelbye]

This is a fantastic rich text editor, easily one of the best I've seen. If I remember correctly, 37signals uses it in the note writing feature of the new Basecamp.

[javan]

Correct.

[cickpass_broken]

A little related: If anyone is interested I've been working on a WYSI-Markdown editor. http://draftbin.com/c3993540679e0a1af4e5704a208b60ceb46d20dc...

Haven't gotten around to a github repo or fixing some pretty annoying bugs. But, there it is.

[mgkimsal]

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 good enough. I'm possibly better now, and maybe wil try my hand at adding that to this editor (which looks nice for a lot of applications) but someone else with better skills could probably lay the foundation for a 'notes' system much better than me :)

[simonz05]

> 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 think this suggestion fully qualifies as something they don't want to do, "[to create] unmaintainable tag soups and inline styles".

[cmelbye]

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.

[slikts]

Looking at the examples, I don't understand how this is "a better approach" to editing, because the HTML it outputs does not follow best practices. The HTML it outputs should look like a competent human had authored it, but currently it uses line-break hacks for paragraphs instead of semantic paragraph elements (two &lt;br> elements aren't really a paragraph, it just looks like it), adds underline elements with Ctrl+U (underlines should be reserved for links and defined in stylesheets anyway) etc.

[DeepDuh]

Want good WYSIWYG html? Try out Apple Pages, export to E-Pub, extract and look at the xhtml files. After pretty printing it's almost like human authored. It seems that we still need the Apples and Adobes of this world.

[_urga]

How is it doing the speech input for Chrome? Is this an offline API provided by Chrome or backed by a Google web api?

[Joeri]

http://slides.html5rocks.com/#speech-input

[Udo]

This is very nice! And it feels very light weight, too. I've been looking for a saner rich text editor for a while...

[dmbaggett]

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?

[evan_]

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.

[snookca]

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.

[WimLeers]

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?

[simonz05]

Creating a simple editor which works, seems to be quiet hard, judging based on all the horrible examples we have of existing ones. Hopefully, they'll keep it clean and don't add many new features.

[alisey]

It's hard, especially if you want to support IE8. You need a 100-line function simply to get cursor position in a cross-browser fashion.

[cristiantincu]

“(…) It uses a sophisticated security concept (…)” —Does anybody know what does this mean? Does this concept have a name, a description or anything?

[grimboy]

As far as I can tell, it's referring to the sandboxed iframe.

[stef25]

The only way to add an image is to enter a URL? An upload feature would be great, most of my sites / clients require it.