Talk:WYSIWYG editor

Bold, anyone?
Is it impossible to implement bold and italic into the text editor, without caring about extras like pictures and tables? Can't we just read and write in the same environment, like in any text editor? Because it simply looks like crap.

BBComposer : A WISIWYG Wiki editor
It can be used to edit simple Wiki : BBComposer

If you want to help me improve the Wiki support of the BBComposer, Contact me.

There are 2 ways to improve him :

This message was created with the BBComposer by Nicolas FROIDURE
 * Improve the html to wiki convertion functions (html2wiki and wiki2html) in the mediawiki.js file.
 * Create an extension for the BBComposer adding a sidebar with some buttons for internal Wiki syntax and other stuff. If someone feels able to create it, an externalisation of the conversion functions can be done too.

--Thanks, Manuel (Oct 26,2009)
 * Question: How to configure the Settings für uploading images?

wikipedia WYSIWYG(?)
Where do I get the Wikipedia WYSIWYG(?) The MediaWiki download doesnt come with as many functions as can be seen on WikiPedia. --Magick 21:22, 6 November 2006 (UTC)

Semi WYSIWYG(?)
I think this misses the point. Wiki is so popular because the markup is easy to learn and once you get hold of it is so much more convenient than unpredictable WYSIWYG behavior (I have MS Word on my mind).

I used various on-line WYSIWYG editors and they are -- obviosuly -- just so terribly clumsy to use (much worse than MS Word). Therefore I think a semi-WYSIWYG mode would work better for Wiki. The only thing that people need from an editor is simple things: show boldface as boldface, show italics as italics (instead of the ... markup), underline external links, etc.

Other than that it is very convenient to mark lists with a *, indent paragraphs with :, etc.

--A2 19:06, 5 April 2006 (UTC)

Removed

 * Opera plans to support either the IE or the Moz API in its upcoming version 8, so pretty much all browsers in use today will be supported (the only not-yet-supported one is khtml).

Opera 7.5 is not even out yet, and Opera 8 is nothing but a concept at the moment. If anyone from Opera indeed did state either API would be supported I would really like to see a quote. Darkelf 00:48, 14 Mar 2004 (UTC)

Alexander Limi, one of the main plone developers is involved with opera (does some of their css stuff etc) and mentioned these plans on #plone at 2004-01-24:

(19:37:52) ***limi discovers yet another insanely cool feature in Opera 7.50 :) (19:38:35) limi: sm, well, mostly to avoid two doctype declarations in Plone, as it's decided by main_template and not the individual templates anymore (19:38:41) Shifters: thought the latest was 7.23 ? (19:39:05) limi: there is a Tech Preview out (19:39:11) limi: TP2 coming soon :) (19:39:27) limi: one of my closest friends is the UI designer there (19:39:40) gwicke: all this shameless Opera promotion... (19:39:41) limi: so I normally run the "nightly build" :] (19:39:43) limi: hehe (19:39:44) Tiran: dreamcatcher: ayt? (19:40:01) Tiran: dreamcatcher: could you pls read my four lines above? (19:40:09) limi: gwicke, Superior Norwegian Technology! ;) (19:40:59) gwicke: bah... all those random bugs... (19:41:02) dreamcatcher: Tiran: uh? (19:41:40) gwicke: limi: they don't even support Epoz, do they? (19:42:19) dreamcatcher: Tiran: does that only happens for metadata? (19:43:06) Tiran: dreamcatcher: I'm not shure but I think that the Descrption method is not created (19:44:11) Tiran: dreamcatcher: that's why the description of the parent folder is shown instead of the right description (19:44:29) dreamcatcher: uhm.... doesnt sound like it (19:46:11) Tiran: dreamcatcher: adding this method to ExtensibleMetadata solved it (19:50:00) jmce [jmce@195-23-9-8.nr.ip.pt] entered the room. (19:52:28) limi: gwicke, not yet - the Epoz stuff is two different techs invented by IE and Mozilla developers, so it's not really a standard. I believe they have plans to support it in 2.0, though (19:52:38) limi: uhm, 8.0 (19:53:14) gwicke: limi: following the moz api? (19:53:59) gwicke: hopefully not yet another one... (19:54:14) limi: gwicke, either the Moz or IE APIs ]

[jmce@195-23-9-8.nr.ip.pt] Gwicke 03:20, 14 Mar 2004 (UTC)]

[jmce@195-23-9-8.nr.ip.pt] HTML to wikitext converter ]
[jmce@195-23-9-8.nr.ip.pt] There are a few out there, including Magnus Manske's C++ version and David Wheeler's version in C, but I decided to create my own HTML to wikitext converter anyway. It differs from others in that:]

When I get a chance, I'll upload the Perl module to CPAN, but for now I figured I'd share the tool with the WP community. Please comment on my talk page. --Diberri | Talk
 * 1) [jmce@195-23-9-8.nr.ip.pt] it's got a web-based interface (]http://diberri.dyndns.org/html2wiki.html)
 * 2) it's in object-oriented Perl, as
 * 3) it shouldn't break on considerably broken HTML code (though I don't know the exact threshold for other converters)
 * 4) it has some nice image-handling DWIMmery (read more at the URL above)
 * Combining one of these converters with Epoz could be a good start for WYSIWYG editing (See WYSIWYG editor). -- Gabriel Wicke 01:01, 8 May 2004 (UTC)

FWIW, I've uploaded the module to CPAN. It's available at my CPAN author page. --Diberri | Talk 00:38, May 11, 2004 (UTC)

My WYSIWYG editor proposal
Here's my idea for how a WYSIWYG editor could work...

As far as I can see, this would allow for lossless editing. Every single little bit of information would be transformed into XML and back again.
 * 1) The article is sent to the browser as standard XHTML, but with extra meta information. All information contained in the wiki source is translated to custom XML attributes, for instance link text would be outputted something like "http://en.wikipedia.org/wiki/Wikipedia" wiki:linktype"internal">link text.
 * 2) Use IE/Gecko's built-in editor to edit the document, so you don't have to reinvent the wheel.
 * 3) Send the edited document back to the server, where the extra XML meta data is used to transform the document back into wikitext.

Can anyone see any major issues with this? Thanks, Tom- 22:12, 20 Sep 2004 (UTC)


 * Sounds smart to me Axel Kittenberger 16:14, 26 March 2006 (UTC)


 * I did make a look into it, actually coding this... the Problem is that the wikipedia wikitext parser is really a very big chaotic thing. First there are no seperated wikiparse - html generation parts, so you could split up xhtml generation. It does parsing and html generation in one mixed up step. Axel Kittenberger 06:57, 16 April 2006 (UTC)

Why is WYSIWYG taking so long?
This really isn't that complicated. Let's make a WYSIWYG editor a priority please! Before Microsoft figures out that Wiki's are important and build MSWiki 1.0.


 * I wish there were a quick dirty and simple implementation of this ASAP. bold, ital, simple tables. just the basics. non-wiki types are really really put off by code of any sort.


 * Too late, MS just built wiki functionality into the forthcoming version of Sharepoint
 * So is it too late for Wikipedia also? Since MS Encarta is also already shipped ;) Axel Kittenberger 20:49, 26 April 2006 (UTC)
 * The wiki in Sharepoint is a joke, it misses most of the functionality beyond rich text and links.

Hmm.
I couldn't comment on why it's taking long - it would probably be a very involved thing to program it (or maybe not), though I believe if it were a high priority it would already be coded :)

May I be frank? Programmers often take for granted the level of thier abilities, leaving other people confused. I believe adding WYSIWYG to MediaWiki would increase usability for common people tenfold. Someone at this news group said writers on a team didn't like wiki markup, and someone in response said essentailly "wiki markup really isn't hard to learn." It may not be hard to you, but it is hard to learn for those writers. Techy people have an easier time with code/markup. But no matter how simple it is, a non-technical person will look at it and balk/panic. I sincerely believe that most people would far prefer editing pages just as if they were using Word. To heed that, I believe, would make MediaWiki enormously more popular - and it wouldn't have to be such that you can only edit with the WYSIWYG, but use markup also - as I believe has been proposed.

--Mr alex hall 18:36, 24 Dec 2004 (UTC)
 * Well said!

--Timothy Takemoto 18:36, 24 Dec 2004 (UTC) I hacked my movable type to use htmltarea, and I am a moron. Surely someone must have dones this already? Ther article is long and theoretical, but it does not say how to. Please can you have a how to give your media wiki a Html area section?


 * MediaWiki's markup IS NOT HTML. --brion 12:17, 26 Apr 2005 (UTC)
 * no, but it´s still a ML... --84.169.33.33 10:04, 12 Jun 2005 (UTC)

is something out there already?
I was planning to use a wisiwig editor for wikipedia for a gadget and was just wondering if someone didn't do already this in an external webpage. I mean there are so many external tools(hacks) for flickr and google maps, I wonder why there are so few external for wikipedia. Maybe everyone just thinks that " Why am I going to do this on my site? those nice wiki guys will surely put that on wikipedia officially anytime soon"...
 * see FCKeditor Mafs 7 July 2005 20:17 (UTC)

OpenOffice 2.0 (Open Document) to MediaWiki format
Is there a macro or export filter that will allow one to create documents in OpenOffice, and export them in MediaWiki format? -- 68.10.113.7 21:08, 29 August 2005 (UTC)


 * Yea this is what Im hoping for. I want an easy way to make some coloured tables, and Im sure a wysiwyg editor is the easiest... --70.77.45.209 04:18, 13 May 2007 (UTC)

I hope there will never be a WYSIWYG editor
I hope there will never be a WYSIWYG editor in the strict sense. If there really were such an editor we would see all the problems all too common with Word documents surfacing on Wikipedia.

With a "What you see is what you get" editor people will focuses, as they do with Word, on what they see, and if it looks right to them they will submit. They will also start worrying about the layout of the page. If the font is too small on their Computer, instead of adjusting their browsers setting, they will increase the font size of an article. There will be edit wars over Arial, Verdana and Times New Roman.
 * People will use blank lines to insert space between paragraphs.
 * Spaces will be used to align text.
 * "Headings" will be made by selecting a larger font size and inserting blank lines.
 * Inconsistent font sizes will be used.

A "What you see is what you mean" editor similar to Lyx might be usefull.


 * I don't see why there needs to be support for font sizes or font styles. I've never seen a page that changes font size or style. And aren't multiple blank lines automatically conflated down to a single blank line? Same for spaces?

No wysiwyg or wysiwym is the single impediment in my office
I've implented MediaWiki for our office intranet. The single impediment to its wide spread use in our office is the need to learn wiki markup. I've searched in vain looking for alternatives but no one so far has nailed it Wiki WYSIWYG. I've stuck with MediaWiki for now because of its large userbase and resigned myself to the fact that I have to do most of the editing of our intranet until WYSIWYG is supported natively or via an extension. I really hate to think of the amount of people who are excluded from participating in wikis around the world because of this impediment. -Christiaan 13:53, 7 April 2006 (UTC)
 * As far I support WYSIWYM extension for wikimedia, I must tell that I was able to teach wiki markup to blondes ;). But it seems you can't teach ease of use to some people.


 * Wiki markup has some "sticker shock" effect on lots of people, particularly when they contemplate creating complex wiki pages from scratch, and they have never edited on a wiki before. However, almost anyone can click the edit links on an existing marked-up wiki page, distinguish the markup code from the visible text, and make small edits to the visible text, on the very first attempt. Learning enough basic markup to get by isn't that hard, and could be eased considerably by printing out cheat sheets and hanging them up around the office. Also, check out the MediaWiki training videos. I expect that with the proliferation of public wikis, it's only a matter of time before just about everybody needs to edit on one. Back in the early days of the Web, HTML was also held to be a massive deterrent to broad participation, but zillions of non-technical people easily learned enough HTML to make simple Web pages once they understood the benefits enough to become motivated to learn a little. Wikis do make it practical, at least in theory, to hire editing help from anywhere in the world, perhaps from English-speaking countries with technically trained workforces and low labor costs (hello, India). Then people who refuse to learn wiki markup can easily paste in ugly messes of plain text inside  and   pseudo-selectors to add "tags" to marked elements. That part works in Firefox but not in IE. Hiding the table of contents also works in Firefox but not IE. Category links are made visible and templates are marked with a dashed red border. Tell me what you think. James A. Overton 19:29, 2 September 2006 (UTC) Please take a look at Writely.com 'Have you guys seen Writely? Isn't that inspiring as an example of WYSIWYG editor? I would really love to see anything similar for MediaWiki. Some features could actually be ignored, as is the case with cooperative editing and more pure visual editing (like font sizes and faces). Of course, table editing is absolutely necessary. And what about the technology? AJAX is *the* solution.'And please let me oppose to the idea that newbies would be the main target audience of a WYSIWYG (or WYSIWYM) editor. I use MediaWiki as a knowledge and information base to assure that distributed teams of software developers cooperate. We really use MediaWiki features extensively. Despite that, we consider that a WYSIWYG editor would be a very important factor to stimulate the use of the wiki. Agility is the word. With AJAX we could eliminate the unpleasant cycle that includes following an edit link + page reload + losing visual formatting. We could simply edit what is right in front of us when we are reading it. And if people use different colors and fonts in some cases, this will be fixed in the end by the very nature of wikis anyway... The important thing is getting people to write it down.'Despite being rather new, Writely is so nice and appealing that several documents once put in our wiki have been moved to Writely in the past few weeks (in fact, an important feature is that Writely allows uploads and downloads in .doc and .odt formats). And remember... Google is behind Writely now. So I would't be surprised at all should they start their own wiki software (read 'Just my two cents.Intuative use of WYSIWYM[http://evolvingtrends.wordpress.com/?s%3Ch1%3Egoogle+wiki%3C/a%3E%29. There still just doesn't seem to be anything that isn't a compromise compared to a fat client type system (i.e. I've used Lotus Notes in the past)

The ideal would be being able to copy text, tables, images from any other window and paste them into a Wiki page and hit save. Currently as I understand it, to get a screen shot into a Wiki page you have to: - Capture the screen in the paste buffer - Open a graphics program and paste the buffer into a new image - Save the image file somewhere - Upload the image file to the Wiki server - Start editing the Wiki page and create a link to the image Where as what would be far more sensible (forgetting how it would be achieved for a minute): - Capture the screen in the paste buffer - Open the Wiki page for editing and select paste with the cursor at the appropriate point Is there a way to achieve that with a Wiki? Or is there something about the underlying technology that just needs a different approach. ]''[http://evolvingtrends.wordpress.com/?s%3Ch1%3Egoogle+wiki%3C/a%3E%29. MediaWiki+FCKeditor ][http://evolvingtrends.wordpress.com/?s%3Ch1%3Egoogle+wiki%3C/a%3E%29. We have just started a project called MediaWiki+FCKeditor: http://mediawiki.fckeditor.net. ]''[http://evolvingtrends.wordpress.com/?s%3Ch1%3Egoogle+wiki%3C/a%3E%29. I would love to hear comments about it.
 * FredCK 17:34, 28 July 2007 (UTC)]It is the best attempt I have seen so far!!! I have started reporting issues on the main page's "Discussion" page. Basically, the main stopper for me is that it does not support so built in MW tags (like "nowiki"), and parser extension tags.--[[User:Y.combarnous|Y.combarnous] 22:23, 28 July 2007 (UTC)]'peblusto says: yes, it must be 100% compatible with current wiki markup. the current fckeditor also looses the existing wikimarkup toolbar so we can't even toggle back and forth between wikimarkup toolbar and fckeditor toolbar - bad idea. also, the content of typing seems at risk where whatever i typed under fckeditor seemed to disappear when i click on the wikitext button, so i retyped it, then when i saved, it appeared twice - where was it hiding? i almost abandoned my edit because i thought it was lost! there's much work to do. too bad word perfect isn't in the running here since their reveal codes would have been the perfect web editor. macromedia dreamweaver came close, but they're an adobe module now. anyway, i salute anyone addressing the challenge of how to edit comfortably for anyone who shows up to contribute to a wiki. revealing wiki markup is off putting to non-coders. perhaps something that analyzes your typing in real time and converts whatever is convertible whenever we type a word break character (space or punctuation). that way the codes would disappear and be interpreted as soon as they made sense, and one screen could be used for either type of editing or toolbar input. [[User:Peblusto|peblusto] 19:04, 7 November 2007 (UTC)]'I want to implement a ulipad plugin to edit media wiki code'ulipad: http://code.google.com/p/ulipad/'I try all the editor of [http://en.wikipedia.org/wiki/Wikipedia:Text_editor_support Wikipedia:Text_editor_support and think none of them is good to use.I just want to make the editor support feature like wikEd,though wikEd should use firefox...

Smilodon 02:33, 7 November 2007 (UTC)'' Is anyone still working on this? I feel that Wikipedia must eventually have a WYSIWIG editor. Is anyone still actively interested in this? I notice the posts on this talk page are quite old. '' CharlesGillingham 03:28, 2 June 2009 (UTC): some think that a missing WYSIWYG-Editor is the biggest problems (if you focus the discussion on "how to aquire new authors") so i guess there is still use for one --Suit 19:45, 24 January 2010 (UTC) A semi-WYSIWYG work-around using Tomboy Notes Tomboy Notes with the Copy as... plugin works to some extent. You need to download the mediawiki XSLT file that I wrote. It interprets font sizes to be headings, works with the LaTeX plugin for equation support, and has some functionality with Tomboy's links. So if you're looking for something "right now!" this is a work-around: Create WYSIWYG in Tomboy Notes Click Copy-As... mediawiki - goes into your clipboard On the mediawiki page, paste the contents and preview If it doesn't look right, make minor changes. I used this to move my Tomboy notes archive over to mediawiki, but I have since found it useful as WYSIWYG.Marupio 23:15, 8 April 2010 (UTC)Color-CodingMay I suggest: color coding. I like the recent additions to the editor to make most operations simpler for the user (such as bold, italics, and references), as well as keep the wiki markup displayed for simplicity and more advanced users, but it creates a very cluttered display. Most text editors use a simple color coding to identify strings, integers, and tokens which makes editing lots of text very easy. Why not do this in the media wiki editor?Jacob 22:25, 18 April 2011 (UTC) What about the Wikia editor?When are you guys going to implement the Wikia editor? It works great...!!!http://www.wikia.com/

I totally agree, the Wikia editor is fantastic and would be perfect as a plugin for Mediawiki (and later core?). --Nhudell 15:50, 11 July 2011 (UTC) Labels of pictures disapearing When I edit a page with this editor, the labels of pictures previous placed on the page disappear. For example, "((File:Image.png|thumb|none|300px|Image label))" will become "(([[-File:Image.png|thumb|none|300px))" or sometime "((-File:Image.png|thumb|none|300px|Image.png))" (obviously, the (( and )) represent square brakets in the original code). Has anybody figured out how to fix this?