454131 - WYSIWYG editor

Status: RESOLVED INCOMPLETE

(support.mozilla.org :: Knowledge Base Software, task)

Description

[Chris Ilias [:cilias]]

The article editor should be WYSIWYG.

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Could we use contentEditable?

Comment 2

[David Tenser [:djst]]

Sylvie and/or Nelson: Do you have any comments on the feasibility of this feature? Have you thought of this in upstream TikiWiki before? Any insights or pointers very welcome. Thanks!

Comment 3

[Nelson Ko [:nkoth]]

http://doc.tikiwiki.org/wysiwyg has been in Tiki but there are some issues. It is based on FCKEditor.

I know Council of Europe uses it inhouse, and I use it for some sites too. But not for content as complex as what we have in SUMO. And we all struggle with limits (so we impose constraints on ourselves)

The more major issues I have encountered:

1) Going back and forth between wysiwyg and non-wysiwyg tends to mess up content, or the layout of the content. So we have been basically be using wysiwyg, or not, but not both.

IMO, this is potentially fixable, but it takes discipline to test it on all types of content and get this right.

2) Lists and such, as well as paragraph spacing, gets really messed up when wiki auto-paragraph mode is off. But I think it is set to on in SUMO, so that is good.

3) Not all wiki syntax stays as wiki syntax after wysiwyg editing. It may become HTML (which has then to be edited in wysiwyg mode alone, or through the wysiwyg tools).

4) Paragraph spacing seems to go weird sometimes. (caused by empty paras appearing between paras that just won't go away).

Comment 4

[David Tenser [:djst]]

Thanks for your list, Nelson. #1 seems like the most serious problem here which would definitely have to be solved somehow.

#2 is not a problem on SUMO as we have auto-paragraph on.

#3 and #4 sound more like plain bugs that could be fixed, but obviously hard to know how hard it would be.

Another thing that makes things complicated on SUMO is SHOWFOR. That would require some very specific UI to create blocks of content that would change depending on OS. Ideally, it would be some sort of box with tabs for each OS/version, but I can see how this could get very complex.

Comment 5

[Nelson Ko [:nkoth]]

Plugin editing again poses an interesting problem.

I think you need custom FCK editor buttons. Similar to what was done here: http://doc.tikiwiki.org/tiki-index.php?page=WysiwygPluginButton, or a variant of that that operates on selected text.

This presumes you are OK with having the plugin code in the wysiwyg content, of course. There is currently no way to hide all that.

Comment 6

[Nelson Ko [:nkoth]]

(In reply to comment #1)
> Could we use contentEditable?

As far as I know, the stable 2.x version of FCKEditor we are using does not support contentEditable, but the new 3.x version (now in beta does). See bug http://dev.fckeditor.net/ticket/2657

Comment 7

[Nelson Ko [:nkoth]]

From first look, I think there is a lot of potential in http://ckeditor.com/   I am not sure about the development time needed in integrating this though. Checking with nyloth to see if he has any comments...

Comment 8

[Nelson Ko [:nkoth]]

Someone's been working on code that solves #3 I think. But not sure if it solves #1 completely. See:

http://sourceforge.net/mailarchive/forum.php?thread_name=20090610201257.GB91709%40gromalin.logidee.com&forum_name=tikiwiki-devel

Comment 9

[Chris Ilias [:cilias]]

Regarding #1, is there any reason to make a tikiwiki markup editor still available?

Comment 10

[Majken Connor [:Kensie]]

(In reply to comment #9)
> Regarding #1, is there any reason to make a tikiwiki markup editor still
> available?

if all the buttons have keyboard shortcuts, then probably not, but once you actually know the syntax some things are much faster to do since you don't have to take your hands off the kb.

I'm really only familiar with the wysiwyg on SFx (which is fck as well) so I don't know if this is possible, but it'd be great if you could still type in tiki syntax and it would automatically reformat it for you, eg after you're done typing ((Safe mode)) it would turn it into a WYSIWYG link.

I have a question though. If I understand this correctly the problem is the WYSIWYG doesn't store the doc in tiki syntax, it's storing bold with <strong> instead of __text__.  Won't this make the pages messy for going back through and editing?

Comment 11

[Marc Laporte]

Related links:
http://dev.tikiwiki.org/WYSIWYG
http://dev.tikiwiki.org/WYSIWYG+observations

This is not easy. 

And a quote from http://www.mediawiki.org/wiki/WYSIWYG_editor

__State of WYSIWYG and MediaWiki software__

In 2009, there is no available 'ready-to-go' package for incorporating full WYSIWYG into the MediaWiki software.

The problem is that any WYSIWYG editor would have to know wikitext grammar, and no full grammar for wikitext exists - the "parser" doesn't parse, it's a twisty series of regular expressions. So present WYSIWYG editors either have to (a) reverse-engineer as much of a grammar as they can, or (b) forget wikitext and just write HTML.

A proper grammar is not sufficient for a proper WYSIWYM editor, as opposed to WYSIAYG (what you see is all you get), but it is necessary. A proper grammar is a highly-desired thing for many other purposes as well, and present efforts are at "promising vapourware" status. See Markup spec.