Re: [development] Why Drupal 5.x must have built-in WYSIWYG Editor?
On 10/6/2006 3:44:01 AM, Drupal Indonesia (support@drupal-id.com) wrote:
2. A best solution, IMHO, is provide a function in Drupal to call the Editor. This Editor() function simply call the ediitor if available, but if no editor installed then Editor() uses <textarea>.
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. Michelle
On Friday 06 October 2006 08:05, 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.
Michelle
There was a thread in the issue queue recently about adding a flag to textareas that the module author could apply or not, which RTEs (TinyMCE, FCKeditor, etc.) could then hook onto to decide where they should or should not be used. I agree that's a better solution than bundling an RTE in core, but I think even that much was told "get out of core and be a contrib module". That I disagree with, as it's a marker that really needs to be standaridzed to work properly, and core should acknowledge that need. I don't know why there was such resistance to it. The current code freeze, though, means that it can't go into core at this point anyway. :-( (OTOH, I'd consider the expandy-textarea thingie to be something that should be an RTE module, even if it is in core and on by default, esp. since it's exclusive with other RTEs. <g>) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
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.
Hi, 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. 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 <adrian@bryght.com> 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.
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
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.
Then, i suggested :
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>
The #accept attribute is a proposal to extend #type="textarea" in WobForms2, and it already exists for #type="file" in HTML4... But thinking about it later, it came to me that we are looking for something that must indicate the IME (Input Method Editor) and not the Content-Type accepted (thus, they are related here). And guess what? Xforms specifications suggest #inputmethod for that... <http://xformsinstitute.com/essentials/browse/book.php#ch06-14-fm2xml> <http://www.w3.org/TR/xforms/sliceE.html> :/
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
participants (5)
-
adrian rossouw -
Gildas Cotomale -
Larry Garfield -
Michelle Cox -
Robrecht Jacques