Status update: WYSIWYG support in Drupal core

[Stefan Nagtegaal-8]

Op 25 mei 2009, om 02:33 heeft Karoly Negyesi het volgende geschreven:

> In a much lower voice, have you seen that Steef largely stopped
> contributing? Guess why: mostly because the old small community
> feeling of Drupal is waning and there is too much "clients" around.
> Think.

True, I have nothing to add here.

I'm glad that at least (by me, the very respected and legendary core  
contributor) Karoly noticed that I sort of gave up on drupal and I'm  
not contributing much at the moment.
That *does* however convince me that I was - in some way - valuable to  
the drupal project in the past and did things which brought drupal to  
a higher level.

It also makes me re-think my consideration of comletely abandoning  
drupal as a whole, although I'm not convinced yet.

Not sure why I answered this e-mail, as it does not add some value to  
the discussion. But I had the feeling that I had to let you guys know,  
how I'm feeling at the moment and the way I'm thinking about drupal.


Kind regards,


Stefan

[Bill Fitzgerald]

When I first read Karoly's response, my inclination was to let this
drop, as I freely admit to not understanding the rationale behind
Karoly's initial response. But, given that my statement -- "But I am a
fan of meeting client expectations" -- has sparked some comments, I
wanted to take a moment to respond.

As I've been thinking about this, I have a hard time understanding the
reaction to the word "client." I suspect that this is largely due to our
client base -- we work mostly with educational orgs and non-profits; our
clients, frankly, are awesome, reasonable people, doing great work. I
feel very fortunate that our work (as a web development shop) supports
their work (as people doing great things to try and make the world a
better place).

But, to state the obvious, many clients are not like that, and I suspect
that when most people hear the word client, they think of corporate
types who think that real issues can be glossed over with better
marketing materials. In my time in the community, I have definitely seen
the tensions between the developer community, and those who think that
Drupal needs a makeover to appeal to a larger corporate audience. The
concerns that Drupal could become too corporate are, IMO, very valid,
and something that the community needs to watch for. In some ways, I see
this mirrored in the discussions about what DrupalCons should be, but
that's a broader topic than can be discussed here.

WRT Word, Oracle, and MS SQL: these are all proprietary apps. In very
general terms, when we look to support people (also known as users, or
clients), we should look for functionality that makes life better for as
many people as possible. The notion that "supporting people" equates
with accepting lower quality code is just not true; shortcuts are not
acceptable. So, any statements that "supporting feature x" will result
in bad code need to fall under the weight of their own inadequacy. Bad
code in pursuit of a real need is still bad code, and will always be
unacceptable.

In looking at the people who use Word, Oracle, and MS SQL, if an org is
using Oracle, they are likely to have some resources on hand, in either
the form of money, staffing, or both. In short, these folks are in a
relatively resource-rich environment. It takes a fair amount of money to
launch an app based on Oracle, and even more in recurring fees.

Word, on the other hand, is used by many people on the lower end of the
technology spectrum. In many non-profits/schools, the people typing in
Word don't have access to support personnel. They just want to get their
work done. In short, these are the people/smaller orgs who are *always*
disempowered by technology -- and there are a lot more of them than
there are Oracle DB Admins. When we look for solutions that help to
empower people, it's *good* to target things that make life easier for
people who have traditionally been shut out -- and this is more likely
to be true of your admin staff working in Word than your Oracle DB Admin
working for Monster Corporation X.

Stefan -- fwiw, I hope you make the choice to continue on with your
involvement in the community.

Cheers,

Bill

--

Bill Fitzgerald
http://funnymonkey.com
FunnyMonkey -- Click. Connect. Learn.
ph. 503 897 7160

[Naheem Zaffar]

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.

[T L-2]

I think it's easy and tempting but ultimately counter-productive to focus on who's right or really gets it or works in the real world.  If it were a simple, one-sided issue, it wouldn't be a problem.  Really, if you remove the specifics, it's yet another debate about what Drupal should or should not include.  This seems natural and inevitable: the many flavors of *nix exemplify, in my mind, that even in the OSS world different people have different needs and want their needs prioritized first (security, usability, stability, maintainability, etc).  It also seems pretty difficult to expect everyone to agree on what the community's needs are, let alone what the order is.  (And hey, the founding members of the community have been pretty amazingly successful at meeting most needs through the modular design.)

So while we could say 'fork it', walk away, or continue to have these passionate but inherently divisive discussions on a case-by-case basis; we could also recognize our common interests and gains by working together and focus on finding an inclusive solution.  That doesn't have to mean compromise, it's not always a binary world.  Globally speaking, I say we concentrate all this energy into discovering creative solutions.

Warm Regards,
Tim

On Mon, May 25, 2009 at 11:25 AM, Naheem Zaffar <naheemzaffar@...> 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.

--

Tim Loudon
t: 781.686.6096
e: tloud365@...

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

[rajasekharan-2]

On Sun, 2009-05-24 at 11:55 -0400, andrew morton wrote:

> One of the things that I found insanely frustrating with pasting from
> Word was that depending on which browser you pasted it into you'd get
> an entirely different DOM tree as a result. IE6 would end up with
> something really broken while FF3 would actually handle it pretty
> well. It added another agonizing level of complexity to the testing
> process.
>
> andrew

The reason for this is that the <div contentEditable="true"> that is
used to provide the WYSIWYG editing is implemented by the browser
rendering engine and not javascript.

Raj

[Mikkel Høgh-3]

On Tue, May 26, 2009 at 5:58 PM, larry@...
<larry@...> wrote:
> 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

I think that is spot on, and perhaps should be promoted to the
official motto of this list.

For the record, I do not think that having WYSIWYG in core is the way
to go. I'm quite comfortable with being able to tack on Markdown, with
or without helpful buttons, WYSIWYG with HTMLawed or just use plain
text based on customer preference.

I think having the WYSIWYG API in core would be encouraging a specific
workflow that core has no business encouraging.

More importantly, I think the default response to any sort of "add x
to core" shoud be a loud and resounding "NO". In my opinion, core
should be as slim and lean as possible. We might consider having more
distributions, like "Drupal ready to go with WYSIWYG, blog and image
gallery", but adding that to the code weight being dragged around
across thousands of servers would be wasteful.

Saying "no" to adding more stuff to core would actually be a great way
to reduce your carbon emissions ;)
--
Kind regards,
Mikkel Høgh

[andrew morton-3]

On Wed, May 27, 2009 at 6:16 AM, Mikkel Høgh <m@...> wrote:
> More importantly, I think the default response to any sort of "add x
> to core" shoud be a loud and resounding "NO". In my opinion, core
> should be as slim and lean as possible. We might consider having more
> distributions, like "Drupal ready to go with WYSIWYG, blog and image
> gallery", but adding that to the code weight being dragged around
> across thousands of servers would be wasteful.

Not to pick on you specifically but I think this kind of a rigid,
absolute thinking is actually as harmful to the project as the idea
that core should be all things to all people. In my mind core should
be about providing APIs that enable contrib.

So while I'd agree that Drupal core should probably not ship with a
WYSIWYG editor, it should provide APIs to make it easy to add them in
contrib--the subject of this thread is WYSIWYG support after all. Any
time you have 5-10 modules doing roughly the same thing in
incompatible ways it's time to look at creating core APIs to allow
them to work together and not duplicate the same functionality. The
successful examples that come to my mind are node access modules from
4.7 to 5 and file modules from 6 to 7 (though it remains to be seen
how well the file API works in practice).

andrew