I expected your reply to be an RTFM, because I did and there's a content parameter to {text-data} that specifies what to do with the field content, and one of the options is wiki — meaning, I presume, that it will be rendered as wiki markup when in display mode. But I think I hear you saying that the similarity with ordinary document content does not extend into edit mode, which I can believe, considering that this comment field, while there's a nice little preview button to show how it will render, also does not offer rich-text editing.

In the immortal words of Scrooge McDuck:

DRAT!!!

We'll buy it. WYSIWYG / Rich Text editing is a must have feature. I'd argue that, at that point, Atlassian should consider bundling it.

Additional comment: One way to implement this would be to have a button for Rich Text in one of the scaffolds; when clicked, it would pop-up a window that would just edit that pane in WYSIWYG - there would still be a tab for Wiki Markup and TWO preview tabs - one to preview the scaffolded input, and another to preview the full page with the edits in the child window.

Done right this could be a hover-over div rather than a pop-up browser window.

Thoughts?

Nearly the first he asks if every text-field could have rich-text-editing, cause many future customers shouldn't (and aren't) be able to use wiki-markup (too much time might be spended by them).

So we're really looking forward to it.

For details of the User Macro see: http://confluence.atlassian.com/display/CONFEXT/Rich+Text+Editor+in+Scaffolding

I would really like to be able to specify which textareas to use it on, and as in the regular edit mode to be able to choose it. Given its ability to prevent the proper invocation of macros, it would not be acceptable to force the user to use it.

I really like the preview-in-place option provided by the JIRA comment textarea too...

I was wondering what the concrete implementation will look like. Is it planned to add the Confluence Richtexteditor with all the functionality (e.g. formatting, Image Linking, Linking) that is shipped with the Confluence RTE?

If yes, that would be great

I have spent some time digging through the customized TinyMCE javascript served from Confluence 2.10, and it seems to be relying on a single text area (called "wysiwyg") per page. There is plenty of Javascript code doing special things based on accessing information from the "wysiwyg" element on the page. Given that Atlassian use this for a single rich text editor contain the entire page, you can see where they are coming from.

I've worked around it using a separate version of TinyMCE that is bundled with a custom plugin I've written. Unfortunately, Atlassian have done quite a lot of work around this in order to integrate tightly with Confluence, which isn't be available if you go this route. For example, you can't insert images or links in the same way.

I've done a small amount of investigation on specifying which textareas to enable RTE for, and again this isn't straightforward. Once you fire up tinymce, it hits all textareas as far as I can tell. I've been playing around with a link that users click to switch between RTE/vanilla textarea, but the problem here is loss of accuracy of the existing data when switching - it never seems to quite convert correctly using the Confluence Javascript wysiwyg functions.