edit: updated to show button styling

For our use we're only interested in a very small subset of XHTML. We use a rich text editor to let clients edit the contents of their web sites, and we don't want any tags included that could disrupt the design of the page. So only the most basic markup is allowed.

Should be easy to extend the script to take into account more of the elements specified in the HTML 5 draft, if anybody wants a more permissive purification...

Best of all, we just open-sourced the script.

Grab it from Github: http://github.com/biilmann/javascript-xhtml-purifier

Original anouncement (in Spanish): http://domestika.org/foros/956-kode/hilos/73209-depuracion_d...

As soon as you enable designmode on a document, every paste coming from something like Word will be transformed into delicious tag soup for you to deal with. No way to just disable that 'feature'.

What you don't see is the horrible HTML generated behind the scenes cough Sharepoint WYSIWYG editor cough.

It would work on half the browsers and need a dirty hack for the rest.

What You See Is Half Assed Texteditor

Prototype, when zipped, is 22 k -- just checked on a server I'm running.

They're closer than you think :)

*edit - that's for version 1.51... 1.6 when minified and gzipped by web server is 23 kb. Not a huge difference, but you get the point.

Also, a WYM editor based on jQuery: http://www.wymeditor.org/

As @JoshPeek noted in the comments given the LOC is 1K making it easier to create a JQuery port.

At the time I wondered if they might be considering developing a wysiwyg editor that integrated with their products better than what is out there.

I found the thread this summer while I burnt a fair amount of time looking at various lightweight markup languages and all the wysiwyg editors. I eventually just decided to put it to one side for now and maybe just code a few simple formatting helpers myself. I am very interested in seeing where this goes!

Modern WYSIWYG editors use an IFRAME with the property designMode="On". The problem that the actual editor solves is manipulating that. So browsers do have native rich edit already, it just needs to be summoned.

> Then can we have a file upload control that can be styled and select multiple files?

Agreed. Trying to create a usable file uploading interface is annoying, but there are some hacks to add Drag and Drop support and things. (Safari [Mac] supports D&D, not sure though about other platforms/browsers.)

I'm sure there's a good example of TinyMCE finely-customized to fit an interface beautifuly and I'm sure someone here will produce said example, but most of the places where I see a WYSIWYG editor, it looks kind of out of place, this is very important to some designers (I think)

Most of us deploying WYSIWYG editors are doing so in applications designed for non-technical users, where text markup is required but no technical knowledge on the users' part can be assumed.

Up until this point we’ve been using either plain text, manual HTML, or Textile formatting. Depending on who you are it’s either fine or annoying.

Regardless of how awesome LaTeX may be, a tiny fraction of people even know what it is. You shouldn't have to learn LaTeX to use 37signal's products...