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