Posted by mcurry on March 16, 2011 at 2:48pm
I notice that drupal.org and groups.drupal.org don't use a wysiwyg editor. Any insights as to why?
Why don't D.O. and G.D.O. use a wysiwyg editor?
Group organizers
Group categories
Wiki pages
- Background info (5)
- Documentation (1)
- Issue lists (3)
Comments
Which wysiwyg? Which editor?
I would guess a few reasons:
For power users, markup using Markdown, Wiki text, etc. is much faster than using an editor. Even writing straight HTML to add a link is much faster than inserting one by highlighting text, waiting for the popup window, pasting in the URL, and inserting it back into the text.
Ample markup help is provided.
Most importantly, there are probably dozens of editors and a few choices for frameworks, and each has its adherents and detractors. CKEditor or WYSIWYG API? TinyMCE or WYMeditor? Whatever gets used here is tantamount to an endorsement from the project, so who wants to get into that fight?
I suppose that makes sense
Good points. I forget that D.O. and G.D.O. are definitely for power users!
I agree that the choice of an editor would be problematic.
There is one reason why choosing and integrating one would be beneficial to the community: it would provide a working model of how it is to be done, and provide incentive to work out the integration problems.
The situation reminds me of the lack of image handling in Drupal core, which frustrated some Drupal web admins for years. Drupal core has recently absorbed (er... integrated) ImageCache, which is a Good Thing.
I assert that weak WYSIWYG support is a hindrance, though (as you pointed out) not for D.O. since the typical user is probably very comfortable slinging HTML or other markup.
Michael Curry
Drupal and Windows Tips
One big reason why it would be bad: pasting code
Ever tried pasting code snippets in a WYSIWYG editor? If there were no other reasons, this one alone would make WYSIWYG a non-starter on D.O and G.D.O.
I bristle (my fault, I'm sure, not yours -- I'm over-defensive!) at the expression "weak WYSIWYG support". Drupal has very strong and flexible WYSIWYG support. It's just that I've yet to find a WYSIWYG editor that is thoroughly fit for purpose.
I certainly agree with you in spirit, mcurry. One of the reasons I'm following this group is that I'd love to see WYSIWYG working "perfectly" in Drupal. It's just a complex objective, and not even a well-defined one. "WYSIWYG integration" means different things to different people. I'm sure we'll get there though :)
Core editor
That's exactly the reason why we've always supported the idea about having a core editor in Drupal.
While the WYSIWYG module has the noble promise of being neutral, it pushes Drupal to a solution that will never be perfect. The main reason for it is that the WYSIWYG module, ironically, doesn't have a WYSIWYG editor.
Only building an editor on its every single detail, following the Drupal community requirements, will bring the perfect solution for Drupal. Why not having it on core, making it possible for developers to replace it with anything else, if they really feel it necessary? I really don't see a good reason against it.
We've already showed our availability to cooperate with the Drupal community to develop that editor in the past. I renew this invitation. @Drupal, just drop us a message and we'll start working on it immediately.
re: "following the Drupal community requirements"
Is there a coherent set of requirements? It would be great to have a discussion that might lead to some kind of requirements analysis. Shall we start one?
Requirements
Yes, there are requirements. But most probably not the kind of requirements you're thinking of.
We've had a couple of discussions about this topic at DrupalCon Chicago. I'll have to follow up on these discussions with a lengthier post somewhere in the short term.
Daniel F. Kudwien
netzstrategen
It depends on Drupal core devs
One of the main issues I see here is that Drupal core developers never showed much love about having a WYSIWIG editor on core. I believe one of the first things we need here is theirs commitment in this sense. Following that, the specific requirements are still to be documented.
We're sure a cooperation between CKEditor and Drupal would be fruitful. There is a lot of work to be done here tough, so It's just a matter of having both sides committed to that for real.
There are more candidates
There are more candidates than CKEditor though. Since, in terms of user-related quality, there are a few editors that would be suitable and their content-editing quality does not differ that much, the decision will be based on other factors. Definitely not usage statistics. But it is very likely that non-user-facing but developer-oriented technical aspects will play a key role; such as quality and cleanliness of API documentation, easiness and result of filing issues upstream, accessibility, server-side impact on performance, plugin development, jQuery, localization within Drupal's JS and localization environment, eco-system, licensing, and other integration aspects. The full list of evaluation criteria including details is what I have to work on, so stay tuned. However, given already these first few hints, there are huge differences between the editor projects, and only the top-ranking editor can be considered for Drupal core.
Daniel F. Kudwien
netzstrategen
I'm not talking about other editors, but about CKEditor really
There will not be a ready to use editor for Drupal. In fact, you've listed several valid things that need to be taken in consideration.
Being us the developers of CKEditor and its Drupal module, we just want to make it clear that we're ready and committed to dedicate our resources to work on CKEditor to fit all Drupal needs. We've been proposing this for years and be sure that we're the editor vendor that best knows Drupal (the WYSIWYG part of it). I'm sure it's the most adopted editor in Drupal installations.
We're in fact starting the development of CKEditor 4. It's a good moment for talking about it.
I'd love to talk about requirements
I've been trying to adapt WYSIWYG editors to my legacy sites' needs, and have failed so far.
While my seemingly simple requirements may be achieved with current modules and editors via custom configurations, I've been unable to find out how to do that (yet).
Here are the my basic requirements. I'm unlikely to use WYSIWYG editors that fail the first two requirements.
Again, these may be relatively simple to do with some existing editors but a well-integrated editor should be able to do this out of the box without obscure tweaking of configuration files, reading docs, etc. The default configuration should support 'basic' (standard) Drupal input formats without much fuss.
Michael Curry
Drupal and Windows Tips
Hi sun, when do estimate we
Hi sun, when do estimate we will have a core WYSIWYG integration?
Jason Graham
http://www.PolishYourImage.com
...
@sun: The types of requirements I had in mind were the need to work with multiple input formats, field types, input filters (including custom filters). Also the ability to keep the editor open for other modules to hook into. These are things which only the WYSIWYG module/API seems to be addressing so far. And I've always avoided WYSIWYG because I can get much more user-friendly results with combos of BUEditor, Textile, image fields, inline, and stuff like that.
@FredCK: I really don't think this is a question of love or otherwise. I've not experienced Drupal devs as hard-core tech-heads who sneer at user-friendly things like WYSIWYG. Rather, Drupal is a phenomenally powerful framework, and the perfect WYSIWYG is going to have to be remarkably flexible, configurable and open. I'd hope that if a bunch of us could put together a good enough spec that addressed the needs of end-users and module developers alike, everybody would rally round (even if it took a long time to implement). Look what the D7UX movement achieved as an example.
Some simple goals for my sites
As a software engineer (well, maybe I'm just a conscientious software developer) I've been admonished on more than a few occasions to not let the perfect be the enemy of the good. So the search for a perfect solution may be an impediment to progress. I'm not sure what to do about that.
I'm really just trying to find WYSIWYG support that satisfies very simple requirements, and so far, I've been unable to do it.
1. Leave underlying node body HTML structure intact. No destruction of linefeeds, whitespace. Switching between WYSIWYG and original browser text field editing (the standard method) should not garble the underlying node body. If you have the line break converter enabled in an input format (as most installations do and most legacy node content does), WYSIWYG editors really have to deal with this. Otherwise, WYSIWYG editors used on legacy node content (or node content entered w/o WYSIWYG editor) will require laborious reformatting if used inadvertently.
2. Deal with the <!--break--> mechanism (or in D6 and up, the summary join/split button)
Still looking...
Michael Curry
Drupal and Windows Tips
This would certainly be beautiful
I agree that preserving white space would be great.
Furthermore, given that Drupal automatically converts line breaks, there's no need for the rich-text editor to add BR and P elements. Doing so actually hurts usability by making the code unnecessarily complex for people who don't use the RTE.
Environment limitations
Pushing the techie point of view into the requirements tends to make things really difficult. These should be the "nice to have" stuff, but not "strictly required".
Keeping the original HTML intact is extremely hard (virtually impossible) to have. Comparing web apps with desktop apps is not good argumentation as well. I'm sure that there are other things that are certainly much more important and critical to have here.
As for BR and P, you must decide what data format you want to handle. Must it be HTML or not. If not, it's better to define that Drupal handles it's own data format only, and make the editors outputting that data format, instead of HTML. This is less natural, in the web technology point of view (which translates on "less stable"), but certainly doable. Even outputting different data formats for different input formats is doable.
Note that the idea behind input formats is to better address a non-WYSIWYG editing environment. It is one of the complex parts of Drupal though. Such complexity would become senseless, in the end user point of view, as soon as a WYSIWYG editor is available.
The goal of a WYSIWYG editor into core is having users using it. If the requirements start with a list of things to have so users will not have to use it, then it looks like this is going to the wrong path, again.
re: Environment limitations
I'm not sure how I'm pushing the techie point of view?
Fair enough. I respect your experience on this. However, Wordpress's (TinyMCE?) editor manages part of this. It doesn't apply P or BR tags, using double or single line spaces instead. I've just checked it, and it does reformat the text - if I put in 4 line consecutive line breaks, the WYSIWYG reduces these to 2 line breaks (i.e. a normal paragraph).
This is close enough, making the HTML view much easier to read and work with. So, how doable is this in CK? Or is it something the WYSIWYG module could/should do?
This is only half of the story, Fred. There is the principle of progressive enhancement, and Drupal has always built UIs based on this principle.
If you have no Javascript available, you should have the easiest possible basic method of formatting text. Textile would be my choice here. If JS is available, a WYSIWYG editor can enhance that basic experience. As we get more and more people engaging with our websites through a mobile device, this approach is going to become much more mainstream. Trying to use CKEditor on an Android phone with a tiny screen would be horrible. So would hand-writing/editing full HTML from a phone. Gracefully degrading to a plain text area and Textile is the obvious thing to do.
I'm not sure how I'm pushing
Sorry, I was replying to you and Michael Curry at the same time. A bit confusing, I agree.
Not having P or BR is not a big issue with CKEditor as well. Note that editors don't do that by default, but, with CKEditor at least, it's possible to input and output any kind of data format through what we call "Data Processor". Basic information about it can be found here:
http://docs.cksource.com/CKEditor_3.x/Developers_Guide/Data_Processor
With Data Processors, it's possible to output BBCode, Wiki markup or even Textile. Of course, this is not an easy thing to code, but it's certainly doable. We're working to do that right now with the phpBB team. We have also started prototypes for Wikipedia and Trac wiki markup formats.
So, for Drupal, it would be a matter of deciding which format to follow and then write the proper Data Processor for it. We can also have more than one Data Processor, each for a different Input Format.
It looks like a good way to go.
The WYSIWYG module could do that. It would be hard work though, developing an HTML parser that transforms HTML to other formats. Additionally, there could be small differences in the HTML produced by different editors, which could lead the parser to fail at its job.
Having a core editor means that we know exactly what comes out of it, so the output will be much more under control. It will also perform better, because it would use features already present in the editor.
Another requirement, I think...
I suggest that no WYSIWYG editor - especially not one designed for Drupal - should ever paste style attributes into the text area. The default paste button (and Ctrl/Cmmd+V) should strip any style attributes from the markup.
Is there a way to implement this already with CKEditor config options?
Yes, the forcePasteAsPlainText setting
http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.config.html#.forc...
That strips everything, not just style attributes
It doesn't look to me like you can strip just the style attributes while allowing HTML through.
Custom solution
Ok, I got the idea now. It's possible to instead have a custom cleanup procedure taking place on paste (In the API point of view, the "paste" event). In this way we can have results that fit the Drupal requirements precisely.
"weak" intended to signify lack of support in core
I meant no offense. I was trying to describe what I perceive as weak/nonexistent core integration.
There are several fine modules available, but I felt that the lack of core integration leads to confusion (on my part!) as to which system to use, and how to configure them for use with other Drupal features. That's not anyone's fault, but lack of standards does hurt a bit, IMO.
Michael Curry
Drupal and Windows Tips
Re: Why don't D.O. and G.D.O. use a wysiwyg editor?
This is a a slightly mischievous observation, but the CKEditor forums don't use a WYSIWYG either.