Rails, Textile, and javascript WYSIWYG roundup | Hacker News Reader

Rails, Textile, and javascript WYSIWYG roundup

blog.aisleten.com

Why would anyone make Joe Average use Textile anyway when there are plenty of rich text editors available? Many (most?) have button bars Joe would be familiar with if he's ever used MS Word (which most Joes have). And again, many are cheap, free, and/or Open Source.

A properly configured app that filters user input doesn't need to require users to know any markup languages at all. So why?

Stop thinking like geeks and think like users.

I've found that many power users prefer the precise control that Textile (or bare HTML/CSS) provide. They really take advantage of the ability to specify floats, margins, and the like.

I've tried supporting both Textile and 3rd party wysiwyg, but it just gets to be a hassle when multiple users try to edit the same thing. They wysiwyg outputs some pretty gross HTML, which the Textile users then have to deal with.

Still, if all you offer is very basic formatting, then a wysiwyg rich text editor is an excellent choice.

Anyone else find that users out-and-out HATE Textile? My users complain about it constantly. Does anyone get the same reaction with other markup languages? I want to make sure that it's across the board discontent, and not that there's anything particularly wrong with Textile.

I definitely second that, and the source of the problem is the same as that with WYSIWYG editors: tables.

I've solved the problem by making things like tables editable in another content management module and including it in the WYSIWYG editor as %%%DATA_TABLE1%%%.

WYSIWYG seems to only work for me when I only allow the client to choose h1,h2,h3,etc.. and bold and italic. If you're just doing that, the WYSIWYG editor is fine and there's no need to try to teach your clients Textile.

Of course, this all depends on who your client is...

Reply on news.ycombinator.com