Forum OpenACS Development: Rich text input

The default input format, I think, should be like what MovableType has, namely HTML input where the software can automatically insert <p>'s, <br>', and &nbsp;'s for you. it could also make links out of URLs and emails. So essentially, this is the current plaintext format, except we don't quote HTML tags for you.

It's really convenient to be able to use simple HTML formatting, but it's really annoying to have to insert your own paragraph and line breaks.

I still think that keeping the plaintext format is nice for posts like this, where you want to write HTML tags that should be shown literatly.

Also, preformatted text probably makes sense. And finally, a "raw HTML" format also makes sense, for when you're copy-pasting stuff from some other source.

Finally, I've added some simple [B], [I], [U], and [URL] buttons which will wrap your current selection in the relevant tags. This is ripped from MovableType (we might need to create our own version of this, though this code is floating around the net in several places).

This only works in IE, though, I haven't been able to figure out how to make it work in Mozilla or other browsers. If there are any Javascript gurus out there, any help would be much appreciated.

I also considered coming up with a Wiki-style 'structured' input language, but Carl convinced me that we'd never manage to teach people yet another rich text formatting language, that it's better to just stick with HTML and add a few buttons to make it easier to use.

Q: Do you people agree that this input format (HTML with <p>, <br>, &nbsp;, and email/URL->link translation) is the optimal format?

Q: How do we label these formats? We could keep HTML/Plaintext/Preformatted, and add two check boxes "Preserve line breaks" and "Make links out of emails and URLs", but that's really long and convoluted.

We could also call them HTML, Raw HTML, Text, and Preformatted. Is that better? Or "Rich HTML"/"Raw HTML"? How would we explain the difference to people?

Is there any need to be able to turn on/off line breaking and making links out of emails and URLs separately from each other?

If you want to play with this, try here:

http://oacs-pg.cph01.collaboraid.net/bug-tracker/bug?bug%5fnumber=12

Register to try.

/Lars

I'm actively hacking on this server, that's probably why. Try again.

Janine,

No, it's not an ActiveX, it's a plain old textara with a little javascript magic. The only thing the buttons get you is that it wraps your current selection in <b>...</b> tags. Writing the <b> tags by hand is as trivial as it always was. It's mainly a pedagogical tool that shows people how to write HTML tags for people who've never tried that before.

/Lars

Yes, we never alter the user's input before storing it in the DB, only on output.

Regarding a multitude of formats, sure, but we might as well try to come up with one that we think is probably the best, the one that we'd use on openacs.org, say.

Btw, right now I'm trying to figure out what to do with links. I added the turning URLs into links, but now it conflicts with your own manual links: If you write <a href="http://foo.bar">link</a>, it's translated into <a href="<a href="http://foo.bar">http://foo.bar</a>">link</a> ...

Anyway, will keep hacking on this a bit.

/Lars

http://cvs.openacs.org/cvs/openacs-4/packages/acs-templating/tcl/richtext-procs.tcl.diff?r1=1.5&r2=1.6&f=h

The <p> ... </p> around the contents is an attempt to make the  output proper HTML, but it does result in annoying whitespace.

Any better suggestion? Should we resort to open-ended <p>'s between paragraphs like we used to?

The code that does this is these two lines in util_convert_line_breaks_to_html in packages/acs-tcl/tcl/text-html-procs.tcl, in case you want to take it out on your own system:

    # Wrap P's around paragraphs
    set text "<p>$text</p>"
    regsub -all {([^\n\s])\n\n([^\n\s])} $text {\1</p><p>\2} text

/Lars

An orthoganal issue ... 'way back on my back burner has been the notion of writing a new datatype for the form builder that handles our existing HTML/plaintext textarea boxes cleanly and without the need for the programmer building a form-handling page to do the work explicitly.

Among other things this would lead to uniformity in how such textareas are presented to the user, and in how they're handled by the submit code.

Do you have any interest in combining your ideas into a new smart text input type in the form builder?  Or are you already way ahead of me and doing this :)

textarea(rich_text_widget)

How do you communicate the "HTML/plaintext/etc" values to the code that handles the form?  If you're using the widget with the textarea datatype you should really only be returning the text itself, not any additional hidden stuff with a magic name, or a list, etc.  At submit time, a form should be able to handle any element of type textarea without any knowledge of the widget you've associated it.

On the other hand, a rich_text datatype (which would of course work with a rich_text widget) could be defined to return the list { text_area_data format }.  The widget would create the textarea block and the associated format dropdown (which I assume your existing widget is already doing), then at validation time (I think, I'd have to look to be sure since I haven't written a new datatype since GP/June) a list would be returned.  You'd want to create property procs to get the textarea and format values back, and an acquire proc to build one from passed-in data (useful for edit forms).

Probably the easiest example to look at is the currency datatype and its associated widget.  It's not well-documented but it is much more straightforward that the equally poorly documented date datatype and widget.

Anyway ... building both a datatype and widget allows you to  fully hide implementation details (i.e. the fact that textarea and  format are a list, or the order in which the two elements are stored in the list).

I was also thinking that Ola's spellcheck stuff could be implemented by creating spellchecked datatypes leading to a cleaner implementation (one which ad_form could mostly be ignorant of) but haven't had time to investigate ...

I haven't done that before, but it does sound like the right way to implement this. Will do that tomorrow.

The proposed standard data types are:

- Rich HTML (links, paragraphs, etc.)
- Raw HTML (no processing, only security checks)
- Text (links, paragraphs, quoting)
- Fixed-width text (links, paragraphs, quoting, wrap in PRE)

We should probably have some kind of help page explaining what they are. Who's building the context-sensitive help system? :)

/Lars

For security reasons we only accept the submission of HTML containing the following tags:
B I P A LI OL UL EM BR TT STRONG BLOCKQUOTE CODE PRE FIRST_NAMES LAST_NAME EMAIL GROUP_NAME
You have a <form> tag in there.

text
text with autolinks
HTML

Note that you can't unambiguously detect URLs, because they may contain spaces (thanks to MS) if not for a bunch of other reasons.

To me, a mix of user-entered HTML and post-processing always screws something up, except in the simplest cases. I had to swear a lot at various forums that do that. It's better to leave HTML option intact, i.e. no post-processing on user input. If it's HTML, it's HTML, no strings attached (well, that seems to be already lost :).

We're going to leave a raw HTML input option around, the question is just what to label it. I'm thinking "Raw HTML".

Then there's the question of whether to try and detect links. I think it's reasonable enough to try and detect them. If you wrap a URL in a link yourself, we'll leave it untouched.

What should the default option be named? "Simple HTML"? "Rich Text"? I'm actually thinking that "Simple HTML" might be the best way to go.

Comments?

/Lars

* some item
* another item
* last one

• some item
• another item
• last one

Regarding the form builder integration: that's great. I hope this will result in an acs-subsite (kernel?) parameter where the admin can define the default widgets that are available plus the ability for the programmer to override it in particular cases with options passed to the widget. (Just bluntly requesting features here ...)

There's a new datatype 'richtext', and a new widget 'richtext', which provides four formats, namely:

text/enhanced
text/plain
text/fixed-width
text/html

These are currently hard-coded in both acs-tcl/tcl/text-html-procs.tcl and acs-templates/tcl/richtext-procs.tcl. It would be relatively easy to make a service contract or some other form of API for adding new methods, but I didn't do it, because I'm more concerned about raising usability for users today than adding fancy options for admins :) Other people are more than welcome to add this, of course.

Also, I've added corresponding mime types to the content repository create scripts, so we can get packages that store data in the CR using this as well.

Available tasks for anyone who feels up to the job: Fix forums, general-comments, wimpy, faq, and whatever other applications we have to use form builder and the richtext widget/datatype.

/Lars

I'd also forgotten to add the gifs used for the buttons. They're in acs-subsite/www/shared.

Perhaps they should be somewhere else?

/Lars

"
<formtemplate>

Hello, I am <formwidget id="">. My favorite link is <formwidget id="">....etcetera.

<if $admin_p><input type="submit" name="formbutton:c_1" value="change"></if>

</formtemplate>
"