added a comment - - edited
Thanks for your feedback. This is one of our most hotly requested features, and we're excited to get it done.
We have kept this on the backburner for three reasons: first, it is a big engineering task to do well. Second, there's been other things we were better placed to spend our time on/things which were in more demand and third, we need to think about displaying HTML just as much as sending HTML.
This is something we are going to implement and we are researching various methods.
Believe it or not, Kayako once had a rich text editor for ticket replies. However, we dropped it - the problem was that customers would make a mess (whether in the HTML reply, or how it was handled by email clients). We also struggled to engineer a reliable way of displaying richly formatted email in the helpdesk itself (what use is sending rich responses if you can't display them back).
Things have changed now; email clients are better and so are, in the large part, rich text editors.
We are doing the following, while on the 'backburner':
- Scoping the work (a lot would need to change; i.e. ticket macros, knowledgebase article drop-ins, quote ticket responses, a new ticket reply area).
- Scoping rich text editors (WYSIWYG (all of them), text-based mark down, etc).
- Researching HTMLPurifier - an engine which processes and cleans up HTML really well, to make sure that malicious code does not make it into the helpdesk and to make sure that the helpdesk layout is not broken by someone else's bad HTML in an email (i.e. a missing tag). Unfortunately HTMLPurifier has historically been hugely resource intensive and has not been an option for us, until lately.
You're certainly free to use the patches attached to this post, but obviously at your own risk. They're based on the same editor we use for the knowledgebase and news articles.
We'll keep you all up to date. This is not something that is going to come straight away, but we are working on it and I hope our explanation goes some way to explaining why this is not as quick as it seems (and why our out of the box implementation has to be more considered than, say, a third party's plugin implementation).