[development] Status update: WYSIWYG support in Drupal core
larry at garfieldtech.com
larry at garfieldtech.com
Tue May 26 15:58:51 UTC 2009
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
> 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
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
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,
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
More information about the development