The lack of WYSIWYG has been a fairly common complaint for some time now. If you hang out in the #drupal-support IRC channel for a few minutes, you’ll see that in many cases, it’s a dealbreaker for Drupal. Mark and Leisa in their usability plans for Drupal 7 are attempting to put an end to this once and for all by giving Drupal a standardized WYSIWYG system. But it’s pretty much a common agreement that WYSIWYG won’t be making its way into Drupal core anytime soon. Why? A couple reasons.
Flexibility
One of Drupal’s claims to fame is the incredible flexibility involved in the robust input filtering system. Anything from [b]BBCode[/b] to WikiWords to *Markdown* to Twitter style @usernames to syntax highlighting can come from Drupal’s input filtering, and to do pretty much any of that you need absolute control over the code without having to worry about your RTE (Rich Text Editor) adding or removing things to try and standardize it.
Lack Of Work
This is sort of a cop-out answer, but one chief reason why WYSIWYG isn’t going to make it into core anytime soon is that there’s nobody working on it at the Drupal issue queue. Code freeze for Drupal 7 is supposedly in just a few months and there’s no chance that a feature as major and revolutionary for core is going to make it in there by then even if the issue is posted in the queue tomorrow.
Contrib vs. Core
A big bikeshed (i.e., something that is argued and obsessed about continuously without ever reaching a conclusion one way or the other) in Drupal is the idea of what belongs in core vs. what would be better off as a module. In general, it’s sort of an unofficial goal of Drupal to not put anything big into core unless there’s an overwhelming movement for it (as is the case with putting parts of CCK and Views in D7). WYSIWYG isn’t getting this kind of support because it just seems to make more sense to leave something this problematic and complicated out.
Lack Of Collaboration
As we all know, there are dozens of WYSIWYG options out there, and there are more decent ones for Drupal than I could count on both hands. Even if we did decide to integrate an editor into core, we’d then be faced with the decision of which editor to use (which goes nowhere because each editor has its own set of problems and its own unique feature set) or alternatively building an editor from scratch to fit the typical needs of Drupal site builders (which also goes nowhere because this is such a huge task).
If there was one master WYSIWYG editor out there that was used more or less universally, then this would be a non-issue.
Lack Of A Good Module
History has shown that all big improvements to core start with contrib modules that are eventually imported into core. Why? Because nothing big is going to make it into core without being tested and proving itself tried and true. This is the case with CCK, Views, ImageCache (which is in the works for D7), Vertical Tabs, Token, etc. All of these contrib modules work, and they work well. WYSIWYG, on the other hand, isn’t in good shape. The WYSIWYG API module (which allows you to use multiple RTE’s just by changing the input type) is a step forward, but still 75% of our client support requests come from the editor (be it TinyMCE, FCKEditor, YUI, whatever) either screwing up the code, or the user screwing up while using the editor. Until an accepted contrib solution pops up, there’s not going to be much talk of core.
Hope that clears some stuff up.
