WYSIHTML5: A better approach to rich text editing

http://xing.github.com/wysihtml5/

by tiff • 14 years ago

312 78 14 years ago

xing.github.com

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/

Udo• 14 years ago

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

zv• 14 years ago

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.

middus• 14 years ago

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!

Angostura• 14 years ago

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

...and let the hilarity commence.

laktek4• 14 years ago

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

davidw• 14 years ago

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.

robin_reala2• 14 years ago

Aloha is more than a meg of JS as it stands and the documentation is pitiful.

ams6110• 14 years ago

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.

drivebyacct24• 14 years ago

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.

batista4• 14 years ago

How about neither, and just try to comprehend that tables are a common use case that if we haven't perfected yet in HTML editors it's web programmers/standards' fault and not Word's?

bergie• 14 years ago

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.

BHSPitMonkey• 14 years ago

If you've used Drupal, what you're describing is simply the correct usage of one of its most powerful pieces: Views. However, even with its somewhat decent "query" editing interface, it's still a complex task that requires some critical data-oriented thinking skills. It's important, I think, for people to be able to format an electronic table about as easily as they can do it with a pen and paper. It's a fundamental formatting operation, IMO, and there should always be a fast/intuitive way of making them.

lunaru• 14 years ago

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?

laktek4• 14 years ago

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.

legutierr• 14 years ago

Are you aware of any such editor that does store the data in Markdown or something similar?

Akram• 14 years ago

even in comments a whitlist of markup would save a lot of code on both the ends.

emn13• 14 years ago

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.

drivebyacct24• 14 years ago

I suppose it's strange to say this on HN where the markup is, well, atrocious, but after using Markdown for ages in varieties of places, it's simply more pleasant to use for the "advanced" user who doesn't want to memorize hotkeys or highlight and press buttons to give their text some basic simple formatting.

It's a hit on reddit, GitHub and more for a good reason. They could have whitelisted things as well, but they chose not to.

brlewis• 14 years ago

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.

geon• 14 years ago

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

SquareWheel• 14 years ago

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

laktek4• 14 years ago

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.

bflesch• 14 years ago

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.

fredley• 14 years ago

I desperately want this as a Wordpress plugin.

cristiantincu• 14 years ago

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

grimboy• 14 years ago

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

eliben• 14 years ago

IE in browser support: IE8+

yay ;-)

lunarscape• 14 years ago

Out of curiosity is it working in IE8 for you? Doesn't appear to fully work for me using IE8 on XP. The editor buttons and most of the page don't appear.

emp_• 14 years ago

The editing does work for me, no buttons show but I am not sure if the demo is tailored to show that off.

On IE7 nothing really happens.

nosierbatiste2• 14 years ago

We officially support IE7 and IE8 in Aloha. I say officially, because, although it does seem to work, it doesn't work very well (at all). IE does some weird stuff with the DOM, especially inside a contenteditable (certain combinations of DOM elements completely mess up the structure if it's inside a contenteditable, but not if it's outside).

stef25• 14 years ago

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.

junto3• 14 years ago

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• 14 years ago

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

junto3• 14 years ago

Just to be clear. I didn't write this! I just used it.

The credit for writing this goes to James Hollingworth: https://github.com/jhollingworth

cmelbye2• 14 years ago

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• 14 years ago

Correct.

mgkimsal2• 14 years ago

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 :)

simonz052• 14 years ago

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

mgkimsal2• 14 years ago

Who said inline styles? A class and an ID on a span tag inside a larger block would be all that's required. The clicking stuff would be applied outside of the document editing area.

This is the sort of reaction that makes me hesitant to even attempt to fork/patch it, because if this sort of thing wouldn't be accepted back in to the main trunk, I'm stuck maintaining a separate branch.

cmelbye2• 14 years ago

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.

simonz052• 14 years ago

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• 14 years ago

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.

slikts2• 14 years ago

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 (underlines should be reserved for links and defined in stylesheets anyway) etc.

DeepDuh• 14 years ago

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.

slikts2• 14 years ago

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.

_urga• 14 years ago

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• 14 years ago

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

TazeTSchnitzel2• 14 years ago

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

decklin• 14 years ago

You might want to take a look at this:

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

sandfox• 14 years ago

You might want to read this bit from that section: "The b element should be used as a last resort when no other element is more appropriate. In particular, headings should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element."

From the looks of it - while just about legal, it's the worst option going. <em> etc are far more preferable and 'right'

batista4• 14 years ago

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.

TazeTSchnitzel2• 14 years ago

I understand that, but when I open your page in lynx I don't want to read text without any formatting because there are no direct equivalents to "bold" or "italics".

snookca2• 14 years ago

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• 14 years ago

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?

snookca2• 14 years ago

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

dmbaggett• 14 years ago

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_• 14 years ago

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.

cickpass_broken• 14 years ago

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.

joelrunyon• 14 years ago

Any idea if/how this integrates w/ Vanilla Forums?

AlexFromBelgium• 14 years ago

Now make a WYSILatex editor in html5 :)

WYSIHTML5: A better approach to rich text editing

Related Stories