I thought I'd convey the remarks about Rich Text Editors (RTE) one implementor of Drupal sites posted to our internal development team's collaboration space. We use TinyMCE for our 90+ sites currently. But TinyMCE has a lot of drawbacks -- including that its code base is bigger than all of core Drupal. We are planning our migration to Drupal 6. We will re-evaluate which RTE to use as we do that. Here are the remarks: "a google of "jquery rte" yields this: http://batiste.dosimple.ch/blog/posts/2007-09-11-1/rich-text-editor-jquery.h... would seem to make sense to start with something like this as a base and add only what is needed, rather than strip out stuff from tinyMCE of FCK. sorry, this is one of my peeves. if drupal is using jquery as js library then it needs to be leveraged. austere or not, every bit counts in the field." To restate: If Drupal is using jQuery, then we ought to have a few RTEs to choose from based upon jQuery. That sounds like a golden opportunity to me.
You might also want to check out WYMeditor. (Almost) valid xhtml and jquery. http://wymeditor.org On Feb 4, 2008 10:16 AM, Chris Johnson <cxjohnson@gmail.com> wrote:
I thought I'd convey the remarks about Rich Text Editors (RTE) one implementor of Drupal sites posted to our internal development team's collaboration space. We use TinyMCE for our 90+ sites currently. But TinyMCE has a lot of drawbacks -- including that its code base is bigger than all of core Drupal.
We are planning our migration to Drupal 6. We will re-evaluate which RTE to use as we do that.
Here are the remarks:
"a google of "jquery rte" yields this:
http://batiste.dosimple.ch/blog/posts/2007-09-11-1/rich-text-editor-jquery.h...
would seem to make sense to start with something like this as a base and add only what is needed, rather than strip out stuff from tinyMCE of FCK.
sorry, this is one of my peeves. if drupal is using jquery as js library then it needs to be leveraged. austere or not, every bit counts in the field."
To restate: If Drupal is using jQuery, then we ought to have a few RTEs to choose from based upon jQuery. That sounds like a golden opportunity to me.
-- Regards, Johan Forngren :: http://johan.forngren.com/
On Feb 4, 2008 9:55 AM, Johan Forngren wrote:
You might also want to check out WYMeditor. (Almost) valid xhtml and jquery. http://wymeditor.org
I was looking around for jQuery editors the past couple of days and also came across jTagEditor [1]. This is just a tag inserter, and has some shortcomings even as that - but I like the way it supports pluggable markup alongside xhtml (the demo has bbcode, wiki syntax and textile implemented). Wysiwym along the lines of wymeditor (I don't think wyg in a textarea is ever going to be possible with 91 contrib filter modules - how do manage with view insert tags and the rest?) + pluggable input filters/buttons + live previews[2] seems like an ideal option either in core or contrib. 1. http://www.jaysalvat.com/jquery/jtageditor/ 2.http://drupal.org/project/live (and see it in action on http://groups.drupal.org)
Unfortunately, WYMEditor is not working with Safari (2 and 3) while most others do nowadays. That was the last time I checked (a couple of weeks ago). Also, the wymeditor website is currently down. Konstantin Käfer -- http://kkaefer.com/ ------------------------------------------------------ Don't miss DrupalCON Boston 2008 · March 3-6, 2008 Learn more at http://boston2008.drupalcon.org Affordable sponsorship packages available ------------------------------------------------------ On 04.02.2008, at 10:55, Johan Forngren wrote:
You might also want to check out WYMeditor. (Almost) valid xhtml and jquery. http://wymeditor.org
On Feb 4, 2008 10:16 AM, Chris Johnson <cxjohnson@gmail.com> wrote: I thought I'd convey the remarks about Rich Text Editors (RTE) one implementor of Drupal sites posted to our internal development team's collaboration space. We use TinyMCE for our 90+ sites currently. But TinyMCE has a lot of drawbacks -- including that its code base is bigger than all of core Drupal.
We are planning our migration to Drupal 6. We will re-evaluate which RTE to use as we do that.
Here are the remarks:
"a google of "jquery rte" yields this:
http://batiste.dosimple.ch/blog/posts/2007-09-11-1/rich-text-editor-jquery.h...
would seem to make sense to start with something like this as a base and add only what is needed, rather than strip out stuff from tinyMCE of FCK.
sorry, this is one of my peeves. if drupal is using jquery as js library then it needs to be leveraged. austere or not, every bit counts in the field."
To restate: If Drupal is using jQuery, then we ought to have a few RTEs to choose from based upon jQuery. That sounds like a golden opportunity to me.
-- Regards, Johan Forngren :: http://johan.forngren.com/
On Feb 4, 2008 7:16 AM, Chris Johnson <cxjohnson@gmail.com> wrote:
would seem to make sense to start with something like this as a base and add only what is needed, rather than strip out stuff from tinyMCE of FCK.
We've currently got a lot more options than just tinymce/fck: * http://drupal.org/project/bueditor * http://drupal.org/project/htmlarea * http://drupal.org/project/quicktags * http://drupal.org/project/whizzywig * http://drupal.org/project/widgeditor * http://drupal.org/project/wymeditor * http://drupal.org/project/wysiwyg (not really, but kinda) * http://drupal.org/project/xstandard * http://drupal.org/project/yui_editor I made that list when Doug announced nicEdit - http://www.civicactions.com/blog/nicedit_a_new_text_editor_for_drupal which is yet another RTE that has been integrated already (though not jquery...yet). I personally am mostly interested in the discussion in terms of "how can I the user or module developer be sure that the RTE isn't applied to certain textboxes" since these can be a bit of a pain on admin/settings/ pages. Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
On Feb 4, 2008 11:34 AM, Greg Knaddison wrote:
I personally am mostly interested in the discussion in terms of "how can I the user or module developer be sure that the RTE isn't applied to certain textboxes" since these can be a bit of a pain on admin/settings/ pages.
Regards, Greg
Did I see discussion somewhere about adding a fapi #editor property? Is there an issue for this somewhere or did it stay as discussion? The big thing for me is that although I really dislike wysiwyg, my users really need code insertion buttons (this is mainly in a forum, they're generally comfortable with bbcode, and would end up typing it directly into a wysiwyg for weeks if I switched) - so any editor in core that I wouldn't immediately switch off on every site would need to have a permanent 'code view' - not as a switch in the editor itself, but an admin setting which removes js representation in the text area itself, so it just deals with insertion of the actual tags. Something which does what both wymeditor (which looks like it's moving towards opera/safari support) and jTagEditor does really. This, again, would reduce the need for quite so many contribs, and make it very useful for install profiles (on for bloggers, off for forums - or a mixture of the two for a community site by node type).
Yes there were several discussions about this prior to code freeze for D6. Issues were filed which mainly got marked as postponed, for all the right reasons. I submitted one myself, but have since come to believe that Gabor has the closest take on this. I'd love to see the ability for RTE enable/ disable to be tied to the type of markup rather than wether we have a textarea field. Basically I think it boils down to giving the RTE maintainers some meta data beyond is it a text area. Currently it's difficult to tell the difference between a textarea filed that's designed for a "show this block on these pages" textarea and a "Here's the HTML markup for the view header" textarea. Ideally we need to know which input filters are selected and be able to say, "enable or disable RTE for these textareas.". There might be a way to do this by examining the forms array in a form alter hook. but if it is realy easy, I'd love to see at minimum helper functions to attempt this. There's a lot of room for improvement here without trying to solve all of the issues associated with RTE's. Dave On Feb 4, 2008, at 3:53 AM, catch wrote:
On Feb 4, 2008 11:34 AM, Greg Knaddison wrote:
I personally am mostly interested in the discussion in terms of "how can I the user or module developer be sure that the RTE isn't applied to certain textboxes" since these can be a bit of a pain on admin/settings/ pages.
Regards, Greg
Did I see discussion somewhere about adding a fapi #editor property? Is there an issue for this somewhere or did it stay as discussion?
The big thing for me is that although I really dislike wysiwyg, my users really need code insertion buttons (this is mainly in a forum, they're generally comfortable with bbcode, and would end up typing it directly into a wysiwyg for weeks if I switched) - so any editor in core that I wouldn't immediately switch off on every site would need to have a permanent 'code view' - not as a switch in the editor itself, but an admin setting which removes js representation in the text area itself, so it just deals with insertion of the actual tags. Something which does what both wymeditor (which looks like it's moving towards opera/safari support) and jTagEditor does really. This, again, would reduce the need for quite so many contribs, and make it very useful for install profiles (on for bloggers, off for forums - or a mixture of the two for a community site by node type).
I believe I said about N times that there should be one module which * keeps a tally of all textareas * provides some UI which lets you configure whether you want a real time editor with a certain textarea (checkbox, JS link) This is totally doable in contrib, I am touting such a module in contrib ever since fapi is, which approx two years and yet noone has written one. I guess its easier to whine at the core developers at every possible occassion. Thanks god we disabled comments on announcements -- less whine. I see the overwhelming pressure for an RTE in core. Here we have a problem: * there are many input formats * some freak out from a simple tag inserter because then the one bit users see HTML code and apparently this is just too much. The answer might be that "hey you need variety? great, there are many editors in contrib" but then, people really want an editor for core. Let's see * The thread starter http://batiste.dosimple.ch/blog/posts/2007-09-11-1/rich-text-editor-jquery.h... is the first editor that does not fill me with sheer unadulterated dread. We still need to check whether the HTML it produces is valid. But at least it uses jQuery and is *small*. Very, very small and thats how I like it. * If you want another editor than this little one, still, contrib modules are many. * We could put the RTE attribute registry into core provided some writes one. I am not holding my breath. Regards, NK
On Feb 4, 2008 2:39 PM, Karoly Negyesi <karoly@negyesi.net> wrote:
I believe I said about N times that there should be one module which
* keeps a tally of all textareas * provides some UI which lets you configure whether you want a real time editor with a certain textarea (checkbox, JS link)
This is totally doable in contrib, I am touting such a module in contrib ever since fapi is, which approx two years and yet noone has written one.
Well, it would not be admin/user friendly, so there is no point. RTEs are not tied to text areas, but the format they generate/support (bbcode, HTML, whatever), so it is not an RTEs to textareas but an RTEs to input fields with a certain format relation. Once we cleaned this up, there is much less input fields to do exceptions with (ie. a HTML RTE will not show up on fields with bbcode input or which is just check_plain()ed, because we know what happens with the input, so we can tell whether an RTE should be there (and with what config) or not).
* We could put the RTE attribute registry into core provided some writes one. I am not holding my breath.
I am not much excited about an RTE in core, it will take time to agree on one, but I am excited about doing RTE support right, so that whatever RTE you use, the admin experience is smooth as well. See also: http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drupal-b... Gabor
Gabor's blog post is useful, input formats are definitely the real issue with this. On that note - Corsix and cwgordon (both ex-GHOP students) developed the flexifilter module: http://drupal.org/project/flexifilter which may impact this discussion a little. I've not yet used it, and they can speak for themselves, but as far as I understand it allows for creating custom filters from scratch, but more importantly for this discussion, importing filters from other modules (which can then be customised via the ui as well). All this is maintained in the db. Having Drupal know exactly what's going to happen to which elements in different input formats could help a lot with tying them into an editor - and it'd also mean only loading one module for filters as opposed to the six, seven (think bbcode, smileys, youtube, wiki, textile, code filter etc.) or more that can easily build up on any remotely complex site. Could make all this a lot easier to tie together.
On Feb 4, 2008 9:12 AM, catch <catch56@googlemail.com> wrote:
Gabor's blog post is useful, input formats are definitely the real issue with this.
Input formats are important, but not really for the reasons that Gabor mentioned. Consider the comment field on groups.drupal.org. I recently added live preview to this textarea and am quite pleased with the results. For example, start typing into a comment into http://groups.drupal.org/node/8140. Note the Preview below. Users can author in Markdown (or HTML) and receive immediate feedback about their presentation. It is WYSIWYG, but he intelligence is on the server, not the client. I don't think a client will ever have have markdown.php nor will it understand all our filters for inserting images, inserting Views, etc. IMO, the best bet is a tag insertion/filter insertion module on the client and leave the WYSIYG to live.module.
On Feb 4, 2008 4:07 PM, Moshe Weitzman wrote:
Input formats are important, but not really for the reasons that Gabor mentioned. Consider the comment field on groups.drupal.org. I recently added live preview[..] It is WYSIWYG, but he intelligence is on the server, not the client. I don't think a client will ever have have markdown.php nor will it understand all our filters for inserting images, inserting Views, etc. IMO, the best bet is a tag insertion/filter insertion module on the client and leave the WYSIYG to live.module.
Well whatever happens for D7, this is what I'll be implementing on the sites I run in the near future (having seen it on g.d.o for the first time a week or two ago and going wow!). However, the main motivation for 'wysiwyg in core' seems to be to hide markup entirely from site visitors - which has to be impossible to do in a way which can take account of the actual information that can be put into a textarea. If I've misunderstood this demand, and simple tag insertion + live previews would satisfy the clamouring, then that'd be great, but I have a bad feeling it won't. At the moment there's two issues: * RTEs are *bad* (really bad) because they can never hide markup and do actual wysiwyg at the same time. This is partly why they've traditionally produced such shocking markup. * a tag inserter + live previews are probably not what's wanted by those who really, really want a wysiwyg editor, because they don't hide markup - although you do get real, genuine, wysiwyg this way, and bad markup isn't enforced. What both have in common is the tag insertion - which I think is something that could be separated from both and unified in terms of how core and contrib handles it. Then client side processing and/or live previews (or neither) handles that side of things independently of generating the markup, and potentially everyone's happy ;)
I agree that this is a great way of fixing this problem (and I'll most likely use it for DrupalMU). I agree with Boris that the live preview should be displayed above the submit button because we don't display the preview button anymore. Wim Moshe Weitzman wrote:
On Feb 4, 2008 9:12 AM, catch <catch56@googlemail.com> wrote:
Gabor's blog post is useful, input formats are definitely the real issue with this.
Input formats are important, but not really for the reasons that Gabor mentioned. Consider the comment field on groups.drupal.org. I recently added live preview to this textarea and am quite pleased with the results. For example, start typing into a comment into http://groups.drupal.org/node/8140. Note the Preview below. Users can author in Markdown (or HTML) and receive immediate feedback about their presentation. It is WYSIWYG, but he intelligence is on the server, not the client. I don't think a client will ever have have markdown.php nor will it understand all our filters for inserting images, inserting Views, etc. IMO, the best bet is a tag insertion/filter insertion module on the client and leave the WYSIYG to live.module.
The Wysiwyg [1] project along with a working group [2] was initiated to create a contrib module that shall act as a controller (and integration) for any RTE/Wysiwyg editor. Most of the current maintainers of editor integration modules in contrib have already expressed their interest. Furthermore, the goal for Wysiwyg is to have a central API for editor plugins that are provided by Drupal contrib modules (aka. external plugins), like Image Assist, Asset, aso. So, if a Wysiwyg editor is enabled for a textarea, a plugin button should be displayed in its toolbar, otherwise a plugin button should be displayed below a plain-text textarea. In addition, all of these inserted contents should be editable afterwards. However, this requires us to have a generic/default way of inserting contents generated by other Drupal modules into a textarea -- and this is, where Inline API [3] comes into the game. I'm working concurrently on these efforts. Unfortunately, building these APIs to support every textarea in Drupal, every editor, and every possible use-case is a quite complex task and requires studying a lot of modules in contrib. My personal goal is to have both projects at least in a beta state in 2008. Of course, any help is appreciated. [1] http://drupal.org/project/wysiwyg [2] http://groups.drupal.org/wysiwyg [3] http://drupal.org/node/80170 Daniel
On 04.Feb.2008, at 08:39, Karoly Negyesi wrote:
* there are many input formats
+ 1 kabillion.
* some freak out from a simple tag inserter because then the one bit users see HTML code and apparently this is just too much.
Couldn't it be possible to have BUEditor's preview mode as default? It's the only RTE that I have found to not eff up the HTML --and I have been able to expand it to include, ampersand punctuation. That, IMHO, makes it far superior than any other RTE. / liza
I don't understand the mindset of developers who object to rich text. Developers should be developing what the end users want. They overwhelming want to not learn html, but use something as simple to use as Word or OpenOffice. I would much rather have an RTE generating html than someone who doesn't know html. The RTE has a much greater probability of generating reasonable html than most users. Yes, I let lots of users who are not professional web developers enter information. If they do something really gross, I go in and fix it. I do not have the time to hold their hands or do what they can do because they know the content. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.19/1258 - Release Date: 2/4/2008 10:10 AM
I use WYSIWYG editors on my sites, but as a designer, I absolutely hate having to. The reason why is that one, they don;t work well, often producing crap code, and two, they allow the end user control over appearance in ways that I don't think them well enough trained to deserve. ;-) The first problem most often manifests itself when users past directly from Word into the editor rather than using the Paste From Word feature in TinyMCE or any similar feature in the others. Word produces crap code, but the users don't know that, and no matter how much we try to train them, they still don't use the correct paste function. CTRL+V in the editor window should be caught and automatically mapped to that Paste From Word function. Furthermore, the editor needs to do a better job of cleaning up code before sending it to the server regardless - it should simply not allow me to enter malformed code. The second is one of aesthetics. We've all seen idiots put bold underlined text in word docs that isn't linked or meant to be. Then there are all the people who insist on using at least three fonts in a page. Anyone using any of my sites will note I've disabled the underline and color buttons as well as all the font and size drop downs, allowing only the basic bold, left and right align, link, unlink, image and paste from word buttons, and the format select element (they can make something an H3 if they want to use my style for that, but they can't change the font manually unless they know HTML). Any solution in code would need to address both of those concerns for me. I'm very picky about producing standards compliant code and I don't want my editor making it easier for clients to screw that up than it needs to be. It's telling that when CNET.com did a standards compliance survey of 1000 US political sites two years ago, one of my sites was in the only 31 that passed, and it was the only one of my sites that the clients hadn't updated content on yet. :-/ Walt Daniels wrote:
I don't understand the mindset of developers who object to rich text. Developers should be developing what the end users want. They overwhelming want to not learn html, but use something as simple to use as Word or OpenOffice. I would much rather have an RTE generating html than someone who doesn't know html. The RTE has a much greater probability of generating reasonable html than most users. Yes, I let lots of users who are not professional web developers enter information. If they do something really gross, I go in and fix it. I do not have the time to hold their hands or do what they can do because they know the content.
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.19/1258 - Release Date: 2/4/2008 10:10 AM
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
The web is not about producing standards compliant web pages. It is about producing content for everyone to read quickly. If you really want to insist on standards compliance then force everyone who submits anything to be moderated by a compliance officer, but let them produce the content quickly and easily. Although I have some problems with bad style, I have more severe problems with overall writing style which was intended for newspaper publishing rather than web publishing. RTE or not does not help this problem at all. The bad style I can fix in a few minutes. The bad writing is much harder and in most cases I have to talk with them to find out what message they really want to deliver in the few seconds that it will be looked at. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Sean Robertson Sent: Monday, February 04, 2008 1:41 PM To: development@drupal.org Subject: Re: [development] rich text editor I use WYSIWYG editors on my sites, but as a designer, I absolutely hate having to. The reason why is that one, they don;t work well, often producing crap code, and two, they allow the end user control over appearance in ways that I don't think them well enough trained to deserve. ;-) The first problem most often manifests itself when users past directly from Word into the editor rather than using the Paste From Word feature in TinyMCE or any similar feature in the others. Word produces crap code, but the users don't know that, and no matter how much we try to train them, they still don't use the correct paste function. CTRL+V in the editor window should be caught and automatically mapped to that Paste From Word function. Furthermore, the editor needs to do a better job of cleaning up code before sending it to the server regardless - it should simply not allow me to enter malformed code. The second is one of aesthetics. We've all seen idiots put bold underlined text in word docs that isn't linked or meant to be. Then there are all the people who insist on using at least three fonts in a page. Anyone using any of my sites will note I've disabled the underline and color buttons as well as all the font and size drop downs, allowing only the basic bold, left and right align, link, unlink, image and paste from word buttons, and the format select element (they can make something an H3 if they want to use my style for that, but they can't change the font manually unless they know HTML). Any solution in code would need to address both of those concerns for me. I'm very picky about producing standards compliant code and I don't want my editor making it easier for clients to screw that up than it needs to be. It's telling that when CNET.com did a standards compliance survey of 1000 US political sites two years ago, one of my sites was in the only 31 that passed, and it was the only one of my sites that the clients hadn't updated content on yet. :-/ Walt Daniels wrote:
I don't understand the mindset of developers who object to rich text. Developers should be developing what the end users want. They overwhelming want to not learn html, but use something as simple to use as Word or OpenOffice. I would much rather have an RTE generating html than someone who doesn't know html. The RTE has a much greater probability of generating reasonable html than most users. Yes, I let lots of users who are not professional web developers enter information. If they do something really gross, I go in and fix it. I do not have the time to hold their hands or do what they can do because they know the content.
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.19/1258 - Release Date: 2/4/2008 10:10 AM
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.19/1258 - Release Date: 2/4/2008 10:10 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.19/1258 - Release Date: 2/4/2008 10:10 AM
Although I have some problems with bad style, I have more severe problems with overall writing style which was intended for newspaper publishing rather than web publishing. RTE or not does not help this problem at all. The bad style I can fix in a few minutes. The bad writing is much harder and in most cases I have to talk with them to find out what message they really want to deliver in the few seconds that it will be looked at.
Care to elaborate on that? I'd be interested in specific examples as well as general guidelines. As for standards compliance, the reason I care is because non-compliant code can really fuck up the display of a web site (I have to fix something on www.johnconyers.com nearly every time I visit it because of FUBARed comments, etc.). -- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
It sounds like the prime RTE offender is the ability to paste or more specifically the ability to paste anything other than plain or the tinyMCE paste word. All the controls I am aware of generate pretty reasonable code. Disallowing paste might actually help solve my other issue. If they can't paste from Word, then they can't paste some document prepared for some other media and have to think about typing something more in the web idiom. There are a number of good books/papers on writing for the web, e.g. Jakob Neilsen. My posters are mostly staff or volunteers, not the unwashed public who add comments. So far I haven't allowed these to use RTE. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Sean Robertson Sent: Monday, February 04, 2008 2:26 PM To: development@drupal.org Subject: Re: [development] rich text editor
Although I have some problems with bad style, I have more severe problems with overall writing style which was intended for newspaper publishing rather than web publishing. RTE or not does not help this problem at all. The bad style I can fix in a few minutes. The bad writing is much harder and in most cases I have to talk with them to find out what message they really want to deliver in the few seconds that it will be looked at.
Care to elaborate on that? I'd be interested in specific examples as well as general guidelines. As for standards compliance, the reason I care is because non-compliant code can really fuck up the display of a web site (I have to fix something on www.johnconyers.com nearly every time I visit it because of FUBARed comments, etc.). -- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.19/1258 - Release Date: 2/4/2008 10:10 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.19/1258 - Release Date: 2/4/2008 10:10 AM
Like Liza, I like BUEditor: http://ufku.com/drupal/bueditor/demo While I'd like it to use more jquery, and have live preview, it's light, and I can override each button's javascript in the admin. Gabor: Daniel's (sun) wysiwyg project seems in the spirit of your wysiwyg thread. http://drupal.org/project/wysiwyg What's your opinion on this? Simon
On Feb 5, 2008 4:00 AM, Simon Hobbs <emspace.com.au@gmail.com> wrote:
Gabor: Daniel's (sun) wysiwyg project seems in the spirit of your wysiwyg thread. http://drupal.org/project/wysiwyg What's your opinion on this?
I think there are good ideas, but most of the common code needs to be in core, or RTE module developers will not pay attention and the users will suffer in the end. Gabor
I think there are good ideas, but most of the common code needs to be in core, or RTE module developers will not pay attention and the users will suffer in the end.
Gabor
I second this. However, core should support every use-case. After studying RTE modules *and* RTE plugin modules, I see a great demand for an open and well thought-out API. As mentioned several times before by many core developers, a generic integration for Wysiwyg/RTE support is possible through a contributed module and does not have to be developed in core up front. Thus, my proposal is to let it evolve in contrib and move the stable parts step by step into core, just like we did and/or probably will do with CCK, Views, i18n, Token, aso. Many other modules in contrib support these, so I don't see a reason, why we should treat RTE/Wysiwyg support differently. Daniel
Disallowing paste might actually help solve my other issue. If they can't paste from Word, then they can't paste some document prepared for some other media and have to think about typing something more in the web idiom.
My clients would kill me if I did that. The problem is that in political campaigns, much of what's posted has to get vetted by several people, and these people are all older types who seem to have to see it in a word doc before it's real to them. -- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
I was pretty much in the same position as you with Firedoglake and Crooks & Liars, even though they use Wordpress (despite my efforts to get them to move to Drupal LOL), TinyMCE is still used for the post editor and they both have a lot of contributors that love to directly paste from Word into TinyMCE. What I ended up doing was using HTMLPurifier as an extra level of filtering on form submits. It has worked out great for filtering out all the extra crap Word puts in. The only problem people have had was using indent in Word as a blockquote and losing that (since it does an actual indent with paragraph styling). The best part has been that I haven't had a single problem with a tag left unclosed since using that. Before making this move, I was getting an email every day or so where someone pasted something in and it broke the layout. In 3 months of using this system, I haven't had any. The only few emails I got was from people pasting into the RTE (usually from Gmail) and losing the text, simply because it was included inside some javascript that GMail uses. That does force them to use the "paste as text" or "paste as word" button more. We don't use RTE for comment posting, but it is used for the comment moderators when editing comments. The comments are still ran through HTMLPurifier when submitted and has ran great. The only other problem I ran into was with embeds being pasted directly into the post. To fix that I ended up grepping out all embed code and replacing it with a token prior to running through purifier. Afterwards the tokens are replaced back with the actual embed code. This opened up another feature I introduced of creating whitelists/blacklists for the embeds. I can decide which domains to allow/disallow embedding from and check them before reinserting the embed code into the post. Jamie Holly http://www.intoxination.net http://www.hollyit.net Skype:intoxination Phone: 1-513-252-2919 Sean Robertson wrote:
Disallowing paste might actually help solve my other issue. If they can't paste from Word, then they can't paste some document prepared for some other media and have to think about typing something more in the web idiom.
My clients would kill me if I did that. The problem is that in political campaigns, much of what's posted has to get vetted by several people, and these people are all older types who seem to have to see it in a word doc before it's real to them.
On Tue, 05 Feb 2008 12:59:23 -0500 Jamie Holly <hovercrafter@earthlink.net> wrote:
I was pretty much in the same position as you with Firedoglake and Crooks & Liars, even though they use Wordpress (despite my efforts to get them to move to Drupal LOL), TinyMCE is still used for the post editor and they both have a lot of contributors that love to directly paste from Word into TinyMCE. What I ended up doing was using HTMLPurifier as an extra level of filtering on form submits.
How would you compare HTMLPurifier with tidy? -- Ivan Sergio Borgonovo http://www.webthatworks.it
I really don't have enough experience with Tidy to compare the two. From what I have read though, Tidy doesn't do that much actual filtering as it does markup correction. HTMLPurifier does have an option in it to have it run with Tidy to clean up the source code formatting though. Jamie Holly http://www.intoxination.net http://www.hollyit.net Skype:intoxination Phone: 1-513-252-2919 Ivan Sergio Borgonovo wrote:
On Tue, 05 Feb 2008 12:59:23 -0500 Jamie Holly <hovercrafter@earthlink.net> wrote:
I was pretty much in the same position as you with Firedoglake and Crooks & Liars, even though they use Wordpress (despite my efforts to get them to move to Drupal LOL), TinyMCE is still used for the post editor and they both have a lot of contributors that love to directly paste from Word into TinyMCE. What I ended up doing was using HTMLPurifier as an extra level of filtering on form submits.
How would you compare HTMLPurifier with tidy?
How would you compare HTMLPurifier with tidy?
The big difference between HTMLPurifier and Tidy is security and filtering. Tidy will let you clean your code style and make sure that tags are closed, etc. HTMLPurifier actually uses Tidy to perform those tasks. However, where HTMLPurifier shines and the reason that embed/object code is stripped is that it not only makes sure your code is correct it makes sure it is safe. It removes all script, object, etc that could cause a security attack. read more about HTMLPurifier: http://htmlpurifier.org/ I use HTMLPurifier where ever I can. However, HTMLPurifier, like Drupal, can be resource intensive. So it is best to apply it as a in-bound filter. -- Alan Doucette Koi Technology, LLC www.KoiTech.net
The hardest part for me is sorting out the relationships between the following three components: 1. The RTE 2. Input Filters 3. Input Formats Each of these components have their own, sometimes quite complex, settings. The success can depend on the precise selection of settings. And even then, the successful implementation can be broken by adding further functionality or changing seemingly unrelated settings. In the realm of RTE, Drupal's power and flexibility lead to nightmarish results. How about a dedicated input format, built into core, called DrupalRTE? The hard code would decide, which, if any, input filters would be supported in this input format. The Wysyiwyg interface would be totally tied to the selection of the DrupalRTE input format. Example: If I'm in node/add/story and I change the input format from DrupalRTE to Filtered HTML, the Wysiwyg will go away. I think by closely wrapping the RTE into an Input Format which does not allow the user to select which input filters its supports -- we'd be significantly lowering the number of variables that contribute to really fussy RTE implementations. Shai Gluskin content2zero <http://content2zero.com>
here are some of my thoughts, they may be dupliate of what has already been said, i just wanted to do a brain dump. Why is there a need for a special input format to be in CORE? why not have the RTE define it's own input filter which just happens tobe flexible enough for user to configure for "extra security". on top of that, if we use a 'predictable' filter, then we can pull it's settings, and at the same time we can examine which of the current TRE enabled features (TRE profiles) can work with current filter settings, and disable accordingly. all this is rather complex if we are depending on other filters, but is marginaly easier if we use our own filter. also a major issue to consider is the following: HTML code produced by the TRE. i can imagine two solutions, please add your own as you come up with them. 1) operate on raw HTML, which leads to very complex and ugly html code, which is often unoptimized (nested font tags anyone?). to avoid this we'll need a very very very complex regex to fix our markup. 2) operate on a DOM-LIKE data structure in real time, which gets saved to HTML on submit. this is much more complex in terms of initial design and coding, but in the end result we can guarantee to produce much beter HTML markup and overall result will be better because we are working with a data type which lives within predictable restrictions imposed by us. imagine FAPI data structure for this, each element has properties and all of them can be nested to define a larger entity. on save (or in case of fapi, on form display) it gets converted into HTML ! i am quite confident that no RTE will make it into core if it produces ugly HTML markup, but i am also confident that no TRE will get into the core if it allows the user to see the markup. (for the following, i use button and TRE feature interchangeably. in both cases i am referring to the button you see on the user end that performs some kind of function on/to the text in the TRE) going back to the input filter issue, i believe the RTE should not have to handle the filtering. i think we have much better chance of success if we think of the TRE itself as a 'plugin engine', or think of it in terms of drupal. i think we can design some TRE which is flexible enough to be extended /easily/, then we can turn our focus away from TRE and onto button features. each button feature will exist on the front end as some JQuery code operating on the live data, but also it's module will sit in the background defining it's own filter (filter per button or filter per feature relating to the RTE). that way we again avoid having to predict what filters the site has enabled, we just have one filter which is the TRE defined filter, and in the admin filter settings we attach filter engines or parsers which are defined by each TRE button. we may however define our own filter admin screen to avoid the end user having to run through many different admin screens connecting all those dots. which is rather trivial for us to do. summary of my thoughts, complexities: input formats/ filters : trivial admin screens for end user: trivial build in jquery + lightweight: trivial to medium expandable through plugins: trivial to medium produce clean HTML or design and build custom TRE data structure: very difficult this is all i have for now, i hope i was able to bring some fresh thought for discussion. ~LiTWoL On 2/5/08, Shai Gluskin <shai@content2zero.com> wrote:
The hardest part for me is sorting out the relationships between the following three components:
1. The RTE 2. Input Filters 3. Input Formats
Each of these components have their own, sometimes quite complex, settings. The success can depend on the precise selection of settings. And even then, the successful implementation can be broken by adding further functionality or changing seemingly unrelated settings.
In the realm of RTE, Drupal's power and flexibility lead to nightmarish results.
How about a dedicated input format, built into core, called DrupalRTE? The hard code would decide, which, if any, input filters would be supported in this input format. The Wysyiwyg interface would be totally tied to the selection of the DrupalRTE input format. Example: If I'm in node/add/story and I change the input format from DrupalRTE to Filtered HTML, the Wysiwyg will go away.
I think by closely wrapping the RTE into an Input Format which does not allow the user to select which input filters its supports -- we'd be significantly lowering the number of variables that contribute to really fussy RTE implementations.
Shai Gluskin content2zero <http://content2zero.com>
-- Oleg Terenchuk Web Manager / Developer Phone: 917 - 306 - 5653
On most of the sites I use, manage or built, the primary need is for a WYSIWYG or RTE editor that is simple, lightweight and provides just a small set of simple operations. The most commonly needed operations are: 1. Create a link / URL 2. Insert an image 3. Set something in boldface 4. Set something in italics 5. Create a bullet list 6. Create a numbered list That's it. On these sites, most content is typed in by users, or pasted as plain text. Some users don't know HTML and want some style. Others (like me) are HTML experts, but are not interested in tripling the effort and time to write a short comment by styling it completely with HTML. So I think there are a variety of "use case sets" ranging from the simple situation I just described for my sites, to those who need fancier formatting and the ability to interpret and clean up things like Word doc HTML.
I think Shai Gluskin makes some excellent points below. The problem is not just finding the write RTE for a site's users, but configuring it along with input filters and formats to make the whole thing work in an easy and expected way. To the extent that we can unify and clarify the variety of configuration settings to achieve better ease of use is perhaps where core can help. On Feb 5, 2008 7:37 PM, Shai Gluskin <shai@content2zero.com> wrote:
The hardest part for me is sorting out the relationships between the following three components:
The RTE Input Filters Input Formats
Each of these components have their own, sometimes quite complex, settings. The success can depend on the precise selection of settings. And even then, the successful implementation can be broken by adding further functionality or changing seemingly unrelated settings.
In the realm of RTE, Drupal's power and flexibility lead to nightmarish results.
How about a dedicated input format, built into core, called DrupalRTE? The hard code would decide, which, if any, input filters would be supported in this input format. The Wysyiwyg interface would be totally tied to the selection of the DrupalRTE input format. Example: If I'm in node/add/story and I change the input format from DrupalRTE to Filtered HTML, the Wysiwyg will go away.
I think by closely wrapping the RTE into an Input Format which does not allow the user to select which input filters its supports -- we'd be significantly lowering the number of variables that contribute to really fussy RTE implementations.
Shai Gluskin content2zero
+1 for RTE support in core. I think Gabor is absolutely right, none will make use of this if it's not in the core. I disagree with the fact that input elements are too complex in terms of settings. I also think it would do no harm declaring a jQuery settings object as opposed to writing special tags in input element HTML code. Few other concerns: RTEs need to be bidi aware (RTL and LTR). On Feb 7, 2008 2:28 PM, Chris Johnson <cxjohnson@gmail.com> wrote:
I think Shai Gluskin makes some excellent points below. The problem is not just finding the write RTE for a site's users, but configuring it along with input filters and formats to make the whole thing work in an easy and expected way. To the extent that we can unify and clarify the variety of configuration settings to achieve better ease of use is perhaps where core can help.
On Feb 5, 2008 7:37 PM, Shai Gluskin <shai@content2zero.com> wrote:
The hardest part for me is sorting out the relationships between the following three components:
The RTE Input Filters Input Formats
Each of these components have their own, sometimes quite complex, settings. The success can depend on the precise selection of settings. And even then, the successful implementation can be broken by adding further functionality or changing seemingly unrelated settings.
In the realm of RTE, Drupal's power and flexibility lead to nightmarish results.
How about a dedicated input format, built into core, called DrupalRTE? The hard code would decide, which, if any, input filters would be supported in this input format. The Wysyiwyg interface would be totally tied to the selection of the DrupalRTE input format. Example: If I'm in node/add/story and I change the input format from DrupalRTE to Filtered HTML, the Wysiwyg will go away.
I think by closely wrapping the RTE into an Input Format which does not allow the user to select which input filters its supports -- we'd be significantly lowering the number of variables that contribute to really fussy RTE implementations.
Shai Gluskin content2zero
We work with jQuery, so what is better than to cooperate with the guy who did this proof of concept with the use of jQuery? http://batiste.dosimple.ch/blog/posts/2007-09-11-1/rich-text-editor-jquery.h... Stefan Op 7 feb 2008, om 13:39 heeft Omar Abdel-Wahab het volgende geschreven:
+1 for RTE support in core. I think Gabor is absolutely right, none will make use of this if it's not in the core.
I disagree with the fact that input elements are too complex in terms of settings. I also think it would do no harm declaring a jQuery settings object as opposed to writing special tags in input element HTML code.
Few other concerns: RTEs need to be bidi aware (RTL and LTR).
On Feb 7, 2008 2:28 PM, Chris Johnson <cxjohnson@gmail.com> wrote:
I think Shai Gluskin makes some excellent points below. The problem is not just finding the write RTE for a site's users, but configuring it along with input filters and formats to make the whole thing work in an easy and expected way. To the extent that we can unify and clarify the variety of configuration settings to achieve better ease of use is perhaps where core can help.
On Feb 5, 2008 7:37 PM, Shai Gluskin <shai@content2zero.com> wrote:
The hardest part for me is sorting out the relationships between the following three components:
The RTE Input Filters Input Formats
Each of these components have their own, sometimes quite complex, settings. The success can depend on the precise selection of settings. And even then, the successful implementation can be broken by adding further functionality or changing seemingly unrelated settings.
In the realm of RTE, Drupal's power and flexibility lead to nightmarish results.
How about a dedicated input format, built into core, called DrupalRTE? The hard code would decide, which, if any, input filters would be supported in this input format. The Wysyiwyg interface would be totally tied to the selection of the DrupalRTE input format. Example: If I'm in node/ add/story and I change the input format from DrupalRTE to Filtered HTML, the Wysiwyg will go away.
I think by closely wrapping the RTE into an Input Format which does not allow the user to select which input filters its supports -- we'd be significantly lowering the number of variables that contribute to really fussy RTE implementations.
Shai Gluskin content2zero
Stefan Nagtegaal wrote:
We work with jQuery, so what is better than to cooperate with the guy who did this proof of concept with the use of jQuery? http://batiste.dosimple.ch/blog/posts/2007-09-11-1/rich-text-editor-jquery.h...
Also the main developer of JQuery UI (http://ui.jquery.com/) has been given a full-time job working on JQuery UI (http://ajaxian.com/archives/jquery-ui-lead-is-hired-by-liferay). They are working on a standard RTE for the UI project and, given that JQuery has been cooperative, they too may be interested in our community's needs. Mike
Anyone looking at kupu? http://codespeak.net/svn/kupu/trunk/kupu/doc/README.txt -Dave
David Durham, Jr. wrote:
Anyone looking at kupu?
http://codespeak.net/svn/kupu/trunk/kupu/doc/README.txt
-Dave
Hi, I've used Kupu elsewhere and been really happy with it * produces well formed html * javascript code that is clean and editable * 'drawers' functionality is easily extendible - e.g. provide AJAX integration with Drupal menu for adding links inline * has an inbuilt spellchecker * easily themeable - the downside is that it is used almost exclusively with Plone - documentation for other systems was sparse last time I looked (about a year ago) I've been thinking about writing a Drupal kupu module - but just at the moment I'm pretty busy. -- Sean
On Feb 4, 2008 12:34 PM, Greg Knaddison - GVS <Greg@growingventuresolutions.com> wrote:
I made that list when Doug announced nicEdit - http://www.civicactions.com/blog/nicedit_a_new_text_editor_for_drupal which is yet another RTE that has been integrated already (though not jquery...yet).
I personally am mostly interested in the discussion in terms of "how can I the user or module developer be sure that the RTE isn't applied to certain textboxes" since these can be a bit of a pain on admin/settings/ pages.
Look: http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drupal-b... Gabor
participants (25)
-
blogdiva＠culturekitchen.com -
catch -
Chris Johnson -
Daniel F. Kudwien -
David Durham, Jr. -
David Metzler -
DragonWize -
Greg Knaddison - GVS -
Gábor Hojtsy -
Ivan Sergio Borgonovo -
Jamie Holly -
Johan Forngren -
Karoly Negyesi -
Konstantin Käfer -
Mike Cantelon -
Moshe Weitzman -
Oleg Terenchuk -
Omar Abdel-Wahab -
Sean Burlington -
Sean Robertson -
Shai Gluskin -
Simon Hobbs -
Stefan Nagtegaal -
Walt Daniels -
Wim Mostrey