[development] Why Drupal 5.x must have built-in WYSIWYG Editor?

[Gildas Cotomale]

On 2006.10.06, Robrecht Jacques wrote:
> Just to step in. I'm not sure we need a #wysiwyg property. I think we
> need a #html property. This would say: it makes sense to put HTML
> codes inside this textarea. If not set, one would be "required" to
> input plain text. This makes the property *semantically* correct and
> could even be used inside core.

You are all right :)
A kind of #wysiwyg property (combined with an hook_form_alter) will do
the trick.
And most of us agree to call it #html instead, in order to be more semantic.
But i think #wysiwyg is very semantic too if the purpose is to
indicate that a RTE must be used because the content may some BBcode
(and not HTML) for example. :/
Well, why do not simply say the kind of content expected here simply
like a text-based MIME type (and the RTE is invoked then only if can
manipulate/generate that MIME type, and Drupal stay that powerfull
format independant...) If you agree, what name should have that
property in such a case ? Why not something like #mime-type (or simply
#mime) or #content-type or better #accept-content  (or simply #accept
like at <http://www.whatwg.org/specs/web-forms/current-work/#accept>
=> <http://www.whatwg.org/specs/web-forms/current-work/#extensions1>
;) This approch also suits with Robrecht's explanations below

> Is the log message even suppose to be HTML or not? Is the description
> of a taxonomy term plain text or not? If you have a textarea where you
> input the paths blocks appear on #html would 0.
>
> But thinking of wysiwyg (or quicktags or img_assist etc), I always
> wondered if instead of adding a property to a form element (or rather
> like Bèr said, try to detect by element-id and/or path), it is not
> better to "connect" (eg in hook_form_alter()) wysiwyg behaviour to
> input formats (eg check if there is an input format form beneath it).
> I know tinymce has profiles, but these are for users/roles. The README
> of tinymce even suggests you make a "rich-text editing" input format
> that allows all html tag to use for tinymce enabled textareas.
> Now, would it not make more sense to attach those profiles to the
> input format instead? I would expect that if my input format was set
> to "filtered html", the things wysiwyg shows is more limited then when
> I select "full html". I don't care what role is editing the node, I
> just care about what input format the user is *currently* using (and
> because the formats a user can use depends on the role he has, it
> indirectly maps to users/roles too).
>
> As tinymce (or any other quasi-wysiwyg solution) needs javascript
> anyway, it should be "easy" to change the profile of tinymce *when the
> user changes the input format*. As the default input format is
> "filtered html" users are puzzled that the node they are previewing
> doesn't look like the one they were editing "wysiwyg" until they
> realize the input format is not set to "full html" (or "rich-text
> editing").
>
> I was thinking of developing exactly such a (contrib) module.
>
> Think of the way the gmail mail-editor works (there is a "Rich
> formatting >>" button above the textarea, and until you click it, you
> are editing in plain text). In some way drupal has the same (filtered
> html/full html), but the wysiwyg modules don't seem to use it.
>
> Together with something like rememberfilter, it would make the
> behaviour of wysiwyg editing in drupal much clearer/cleaner.
>
> It would be nice to see the wysiwyg modules authors come together
> *first* and develop a clean, common way of doing this before someone
> utters a word about it again on drupal-devel ;-)
>
> Robrecht
>
>
>
> On 10/6/06, adrian rossouw wrote:
> >
> > On 06 Oct 2006, at 3:05 PM, Michelle Cox wrote:
> >>
> >> While I don't agree that Drupal needs a WYSIWYG built in, I do like this
> >> idea. If I'm understanding right, it's basically a hook to call whatever
> >> editor the user has installed or a plain text area if none. From my non-dev
> >> perspective, that sounds like a useful thing. Would be especially nice if
> >> there was a way to make it so that, for example, my users get BBCode and I
> >> get QuickTags. And that they only show up when editing the main text of a
> >> node. for the longest time i've advocated that the tinymce module etc just
> >> extend the form
> >> and add a '#wysiwyg' => true property, to whatever field they want.
> >>
> >> this means anyone else can also go and add that property to any form they
> >> feel like.
> >>
> >> if the element is set , and the module is not available, it is just ignored.
> >>
> > for the longest time i've advocated that the tinymce module etc just extend the form
> > and add a '#wysiwyg' => true property, to whatever field they want.
> >
> > this means anyone else can also go and add that property to any form they feel like.
> >
> > if the element is set , and the module is not available, it is just ignored.

-- 
little thoughts