Talk:WYSIWYG editor: Difference between revisions

Content deleted Content added

Inline

Revision as of 11:29, 25 August 2006

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)[reply]

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

Gwicke 03:20, 14 Mar 2004 (UTC)

HTML to wikitext converter

There are a few out there, including Magnus Manske's C++ version and David Wheeler's version in en:C, but I decided to create my own en:HTML to en:wikitext converter anyway. It differs from others in that:

it's got a web-based interface (http://diberri.dyndns.org/html2wiki.html)
it's in en:object-oriented en:Perl, as HTML::WikiConverter
it shouldn't break on considerably broken HTML code (though I don't know the exact threshold for other converters)
it has some nice image-handling en:DWIMmery (read more at the URL above)

When I get a chance, I'll upload the Perl module to en:CPAN, but for now I figured I'd share the tool with the WP community. Please comment on my talk page. --Diberri | Talk

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)[reply]

FWIW, I've uploaded the module to en: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...

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 [[Wikipedia|link text]] would be outputted something like <a href="http://en.wikipedia.org/wiki/Wikipedia" wiki:linktype="internal">link text</a>.
Use IE/Gecko's built-in editor to edit the document, so you don't have to reinvent the wheel.
Send the edited document back to the server, where the extra XML meta data is used to transform the document back into wikitext.

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.

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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.

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.

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.

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)[reply]

As far I support WYSIWYM extension for wikimedia, I must tell that I was able to teach wiki markup to blondes ;)

Move page to WYSIWYM Editor, and put in a redirect

Often Critics comes from the misunderstanding of WYSIWYG and WYSIWYM (see top discussion), has anybody something against to move this page to WYSIWYM Editor, and put in a redirect? At some point at last we need to become correct. --Axel Kittenberger 20:53, 26 April 2006 (UTC)[reply]

The most common name for this technology is WYSIWYG. The WYM thing is precise but rare. Rather than force-feeding a new acronym to people, let's concentrate on how to make this technology work. --Evan 14:21, 15 July 2006 (UTC)[reply]

As I said the renaming is due to the fact, some people hate WYSIWYG because they take that get to narrow. So I do think that calling it proper, does help in creation of something like that. Since the graphical editor view does not have to be exactly like that the webpage will look like. A strong requirement for true WYSIWYG that we don't really want. --Axel Kittenberger 10:23, 22 July 2006 (UTC)[reply]

Take also a look here in the distinction why wikipedia especially does proparly need WYSIWYM and never really wants WYSIWYG: Lyx quote: LyX is a document processor following the self-coined "what you see is what you mean" paradigm (WYSIWYM), as opposed to the WYSIWYG ideas used by word processors. This means that the user only has to care about the structure and content of the text, while the formatting is done by LaTeX, an advanced typesetting system. LyX is designed for authors who want professional output with a minimum of effort and without becoming specialists in typesetting. --Axel Kittenberger 08:19, 23 July 2006 (UTC)[reply]

recently added to the article:

An editor should support the user in getting a headline right instead of using a big font, marking a citation instead of italicizing text, and so on. Imho most wysiwyg-editors lures people away from thinking about the meaning, and this is wrong. -- ∂ 01:47, 6 August 2006 (UTC)[reply]

Thats just another example why we certantly DONT want WYSIWYG but DO want WYSIWYM! And another example why there is objections because people misunderstand the Get in WYSIWYG. (which means a graphic editor where e.g. italics and citations are graphed differently altough they might look the same in the resulting article, we don't see what we get! An objection that would not even be necesarry if we would just label the project correctly. --Axel Kittenberger 12:24, 8 August 2006 (UTC)[reply]

i think the real problem is, most new users do in fact want WYSIWYG: most of them want to make their writings look pretty. not as many, but still a lot are willing to conform to "the rules" as far as is concerns the looks. but only few really want to think about what they mean, because thinking is wearisome.

if you are a newbie, and i guess newbies form the majority of the target group for a visual editor, you have enough other things to think about when editing a wiki, so the reaction to avoid thinking is perfectly natural. there's only one way to get around this: think for them as much as possible, and put it in software. you'll still have to deal with the kind of people talking like "if you want italics, just use the 'cite'-button".. -- ∂ 14:53, 8 August 2006 (UTC)[reply]

If for example a citation would look in the editor as text with a green squared background, with the small letters "Citation" on the upper left side, its obvios for every user that this is not the same as "italic", although in the standard article presentation it may look italic. Thats why such a graphic editor would not be WYSIWYG but WYSIWYM an thats what IMHO we want. --Axel Kittenberger 11:43, 10 August 2006 (UTC)[reply]

I agree with -Christiaan =

I am just waiting for somebody to implement a stable enouph free wiki with wysiwyg, the wysiwyg editor is the killer application that people want, the 1st wiki to implement it stable and free wins.

People just want to write stuff and share/embelish the same information, they dont want to be tortured with new syntax or markup languages. People have already learnt word, they are familiar with the interface, now they want to make sure that 5 people in the same organisation do not write the same piece of documentation, so what we want is word + wiki.

How difficult can it be to jack this FCKeditor into mediawiki, make it work and lets get on!. I am being held back from media wiki because of this and am reluctantly using alternatives.

The most practical wiki I have seen that matches the needs of the people who could not care less about the syntaz is MoinMoinWiki, but it is still buggy. it integrates the FCKeditor and passes the my criteria of being able to link within the wiki and externally, WITH NO FUSS!. I am sticking with it until wikimedia gets there act together on this. Asking people to learn the table syntax, is not practicle, when there are simple, intuitive interfaces to build tables.

Possible desicion

Talking about how the method should work we should remember that not every one prefer visual editing to wikitext. So we should give users an option to select the most confortable way of editing (dinamicaly at run-time if possible). I'm already working over it. At that very moment I've integrated InstaView with FCKeditor. And for the back html2wiki transformation I use my own development (though I used another open source project as origin). This approach is working in spite of FCKeditor doesn't preserve line-breaks and both wiki2html and html2wiki are rather limited now (in development). So if the idea seems interesting please contact me via mail, leave a message on my user page or just continue this thread. --Shtriter 08:31, 17 July 2006 (UTC)[reply]

Table

Perhaps this will be useful: I am pretty sure WYSIWYG should include the functionality discussed at w:Wikipedia:Table: namespace and editor.--Piotrus 20:49, 5 August 2006 (UTC)[reply]

Im pretty sure if at first step having an editor that will only handle bold text (self reference), sections and links might be a real big step forward already, leave tables, templates, graphics and all that fancy stuff for WYSWYM version 2.0. Keep the milestone goals realistic ;o) --Axel Kittenberger 11:46, 10 August 2006 (UTC)[reply]

FCKeditor fails

Like many of you, I've run into the same no-code culture problem regarding wiki. So, I did push ahead with FCKeditor as a solution; we did get it working after a time and the solution is sound, but it just doesn't cut it for wikitext handling. The problem isn't creating a visual editor; that's simple (well, no, but at the very least it's already been done). The problem is creating a visual editor that plays by the wikitext rules instead of using html. I can't sacrifice one group's ability to use extensions for another group's need to have visual editing, nor can I ask the former group to lose all their work everytime they try to edit (FCKeditor destroys pretty much any existing wikitext tags in parsing... even if you work in source view, you'll have problems next time you edit). What's needed is for someone to take FCKeditor and rip the html out of it. Take their concept and completely rebuild it using wikitext as the target language. The problem is the FCKeditor devs are completely unwilling to do that themselves like the should have. Honestly I think they should be blacklisted by wikimedia. Their extension should be removed from meta and use of FCK discouraged by wikimedia until such time as they make their code work with within the system, instead of forcing people to choose between FCKeditor and practically every other extension that adds functionality to wikitext. -Verlocs 12.104.195.32

Yeah, that's cruel... ;) In general I think there's no need to blacklist FCK devs... Moreover there's no need to rip FCK at all (well, maybe some corrections can be done but by FCKeditor developers only). My solution to the problem can be found here. wclEditor is a combination of some useful js that allows choosing between the original editing style and FCK. The article's text would be saved as wikitext anyway. This approach is similar to FCK VS HTML Converter, but all of the transformations are made on the client-side by js. IMHO, that approach can solve most of the described problems.

PS: The project is in beta stage and there are many things to be done, but on that very moment we can already see the concept and check the correctness of wiki2html and html2wiki transformations (There are no diffs between the result of html2wiki(wiki2html(txt)) transformation and original wikitext for the most elements of the wikitext). --Shtriter 13:18, 19 August 2006 (UTC)[reply]

Javascript editor

Most if not all presented WYSIWYG (or WYSIWYM :) editors are based on browsers "htmlarea". Which is IMHO most times I've seen rather bad implemented. I learned for one to hate the WYSIWYG editors even on clean html editors without the wikitext problematic at all. For example if a line starts with an URL, you can no longer write normal text before the Url.. everything will be part of the URL. Also bullets work strange and so on.

So I'm just wondering, wouldn't it be possible to totally ignore <htmlarea>, and write an editor with javascript-power only? A Javascript that will write html code to a page as keys are pressed on keyboard, and also stores parallel to it how the wikitext looks like. The cursor would be for example be needed to be simulated by a black DIV or so. This way the usual wikitext->html->wikitext conversion problematic with possible contamination of the wikitext just by the conversion circle is circumvented. --Axel Kittenberger 19:24, 19 August 2006 (UTC)[reply]

Well, from my point of view everything is possible. But every brilliant idea needs the brilliant developer to implement it... It seems to me that it would be much easier to adopt existing editors to our needs that to develop new one. I believe that error reporting exists just for such cases - why not to tell about the problems to editor's developers? Besides even if we'll manage to develop such an editor we wouldn't avoid some sort (html2wiki or wiki2html) of text transformation. So what are the advantages? --Shtriter 14:46, 20 August 2006 (UTC)[reply]

With a well customized editor, we would only need a wiki2html transformation ..not a for and back transformation which is unacceptable IMHO. Until the implausible case of perfect transformations in both sites it would alter the original site just by opening and saving. Just look at the wiki2html parser of mediawiki's current implementation how complicated it is. Just the Bold and Italic handling is a science itself. Take for example stuff like this double enclosed. Mediawiki’s implementation does this correctly as you see (produced even valid html, by inviblly closing the bold tag before opening the cursive tag. But which editor would do it? --Axel Kittenberger 21:25, 21 August 2006 (UTC)[reply]

I can't understand why html2wiki transformations are unacceptable. In my project I use both transformations (see the previous thread). As I've already said, those transformations don't affect the original wikitext. Though I test the correctness without the editors for the purity of tests, I can say that I don't get diffs for paragraphs, simple lists, tables, links, nowiki's and preformatted text.

Talking about the MW's parser all I can say that it's not perfect. I've printed it's source and study it regularly, cause I'm developing InstaView. I know, InstaView isn't perfect too (that's why I'm working over it...) but it's source at list 6 times smaller than MW's parser (10 pages against 60+...). And btw, bold/italics handling in InstaView is implemented simpler and rather more beautiful. So there's no need for complicated code in simple cases...

The only idea that I do support is the correctness of visual editor's output. Imho, that's the consequences of the WYSIWYG approach itself. So all I can propose is my project mentioned above. It will give us opportunity to select not only between the original wikitext/visual editing, but in potential we could even select the desired editor... Btw, FCKeditor claims to output valid XHTML in future...

--Shtriter 07:38, 22 August 2006 (UTC)[reply]

Does this work correctly for example? Note that:

<b>this <i> work </b> corectly</i>

is not valid html (or at least XHTML for sure). It has to be e.g.:

<b>this <i> work </i></b><i> corectly</i>

--Axel Kittenberger 14:37, 24 August 2006 (UTC)[reply]

You are right. InstaView's output has to be corrected. Are there any other similar examples? Btw, why not to use RegExp for it? It can be smth. like:

output.replace(/((?!)+?)<\/b>(.+?)<\/i>/gim , '$1$2' );

I guess that this variant is better then following the way of the MediaWiki's parser. I've heard that many developers said that that parser is monstrous and it has to be rewritten. Moreover, even devs don't know everything about wikitext (For example there is no single point of view how nested dl's must be treated - see bug #6569). So I think that we should create smth. like wikitext standard first.

--Shtriter 17:21, 24 August 2006 (UTC)[reply]
I think regexp replacing is an unideal approach all the way. Mediawiki parser works also that way. A far better parser is an: wikitext -> object stream -> html. Where objects are programming language objects for each accepted tag, like text, headline, bold on, link start, bold off, and so on. Then next step to html generation is also far more addaptable, you can create generators for xhtml, or even latex, without to worry about the parser, or parsing differently. Here in my work with "experimental wiki designs" we implemented such a parser in the ruby language, because regexps replaces more and more hit their limits in technology (things you can parse correcly). The new parser is even faster. --Axel Kittenberger 11:28, 25 August 2006 (UTC)[reply]

I'm not an expert into this, but as said all these editors (as far I can tell) use the browsers htmlarea.. which is in core a browser specific editor functionally they hang on, and often the browsers did it bad. I just see this a problem, since we wouldn't have access to alter unwanted behavior, just try to tell internet explorer devs it should handle this or that htmlarea editor stuff better, so it becomes sensefull usable for mediawiki. :o) --Axel Kittenberger 21:30, 21 August 2006 (UTC)[reply]
Imho, it's not interesting for IE devs, they wouldn't do it... And it's still interesting for me who will develop js editor. I don't know such guys though the idea is interesting. The basics can be found here. --Shtriter 07:38, 22 August 2006 (UTC)[reply]

@@ Line 198: / Line 198: @@
  output.replace(/<i>((?!<b>)+?)<\/b>(.+?)<\/i>/gim , '<i>$1</i></b><i>$2</i>' );
 ::: I guess that this variant is better then following the way of the MediaWiki's parser. I've heard that many developers said that that parser is monstrous and it has to be rewritten. Moreover, even devs don't know everything about wikitext (For example there is no single point of view how nested dl's must be treated - see [http://bugzilla.wikimedia.org/show_bug.cgi?id=6569 bug #6569]). So I think that we should create smth. like wikitext standard first.
-:::: I think regexp replacing is an unideal approach all the way. Mediawiki parser works also that way. A far better parser is an: wikitext -> object stream -> html. Where objects are programming language objects for each accepted tag, like text, headline, bold on, link start, bold off, and so on. Then next step to html generation is also far more addaptable, you can create generators for xhtml, or even latex, without to worry about the parser, or parsing differently. Here in my work with "experimental wiki designs" we implemented such a parser in the ruby language, because regexps replaces more and more hit their limits in technology (things you can parse correcly). The new parser is even faster. --[[User:Axel Kittenberger|Axel Kittenberger]] 11:28, 25 August 2006 (UTC)
 ::: --[[User:Shtriter|Shtriter]] 17:21, 24 August 2006 (UTC)
+:::: I think regexp replacing is an unideal approach all the way. Mediawiki parser works also that way. A far better parser is an: wikitext -> object stream -> html. Where objects are programming language objects for each accepted tag, like text, headline, bold on, link start, bold off, and so on. Then next step to html generation is also far more addaptable, you can create generators for xhtml, or even latex, without to worry about the parser, or parsing differently. Here in my work with "experimental wiki designs" we implemented such a parser in the ruby language, because regexps replaces more and more hit their limits in technology (things you can parse correcly). The new parser is even faster. --[[User:Axel Kittenberger|Axel Kittenberger]] 11:28, 25 August 2006 (UTC)
 :: I'm not an expert into this, but as said all these editors (as far I can tell) use the browsers htmlarea.. which is in core a browser specific editor functionally they hang on, and often the browsers did it bad. I just see this a problem, since we wouldn't have access to alter unwanted behavior, just try to tell internet explorer devs it should handle this or that htmlarea editor stuff better, so it becomes sensefull usable for mediawiki. :o) --[[User:Axel Kittenberger|Axel Kittenberger]] 21:30, 21 August 2006 (UTC)
 ::: Imho, it's not interesting for IE devs, they wouldn't do it... And it's still interesting for me who will develop js editor. I don't know such guys though the idea is interesting. The basics can be found [[en:User:Cacycle/editor|here]]. --[[User:Shtriter|Shtriter]] 07:38, 22 August 2006 (UTC)