[development] Status update: WYSIWYG support in Drupal core

[larry at garfieldtech.com]

Naheem Zaffar wrote:
> I think many people will be happy with a(n easily 
> customiseable/extendable) tag editor in core - even those who want a 
> full fledged wysiwyg, if their only other option is no editor in core at 
> all.
> 
> I myself prefer a simple  tag editor too - it also has this "ability" to 
> strip out all the extra markup when copying and pasting from word...
> 
> Ofcourse most developers, if asked for an opinion will choose the editor 
> they like and personally prefer to be the one that is included in core, 
> but that cannot happen, so what is probably needed is someone to lead 
> the effort. Someone who has buy in with the developers to decide "This 
> is the editor that we want in. Either it gets in or nothing" and after 
> that point, I suspect most of the bike shedding will be less common and 
> people may try to work on the actual issues to get that to happen.

It's not that simple.

I have build sites for "clients" where we installed a WYSIWYG and it was 
good.

I have built sites for "clients" where we installed a tag editor or 
wiki-style input filter, and it was good.

I have built sites for "clients" where we gave them just the plain 
textarea and let them write tags themselves, and it was good.

And I have sites where I would want to do a little of each for different 
textareas.

Bottom line:

Those who say that we have no need for a WYSIWYG editor and we shouldn't 
bother with it (whatever the justification given) are wrong.  Flat out, 
unequivocally, wrong.  Period.

Those who insist that we need a WYSIWYG editor in core by default so 
that it's always available are also wrong.  Flat out, unequivocally, 
wrong.  Period.

Drupal is a flexible multi-purpose tool, and in some use cases a fancy 
schmancy editor is absolutely critical.  In others it would totally 
destroy the usability of the site.

So what are we supposed to do with that?  What we should always do when 
faced with that sort of dilemma: Make it as dead-simple to extend and 
customize as humanly possible.  I want to be able to change between a 
heavy WYSIWYG of my choice, a tightly filtered set of manual HTML tags, 
an liberal set of manual HTML tags, a wiki-style syntax, and absolutely 
plain text only input... *per text area, per user, per user preference*, 
for multiple combinations of those.  Why?  Because I have run into use 
cases for every single one of those, in both personal and professional 
work.  That's what we need to be building toward.  The WYSIWYG API 
module is a very good step in that direction but it's not there yet; 
Think of this as the Filter system TNG, which desperately needs someone 
who can champion and drive that the way that the Menu API, DBTNG, and 
the D7 usability work does.  And it goes deep enough that it's something 
that has to happen in core, especially now with Fields in core.

If we don't think holistically like that, we end up with the body field 
teaser splitter button...  A major WTF usability fail that has exactly 
one use case (blogs by people who can't write an HTML comment) that is 
one of the key reasons why Palantir does not use the core body field, 
ever.  It's broken by the flawed concept that there is One True Input 
Workflow, which is simply not true.

Yours is not the only use case or workflow that Drupal needs to support. 
  Whoever you are or whatever your use case, that statement still holds 
true.

--Larry Garfield