Let's see ... a widget implies something like (using ad_form notation)
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 ...
