Talk:WYSIWYG editor

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 C, but I decided to create my own HTML to wikitext converter anyway. It differs from others in that:


 * 1) 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)

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
 * 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...


 * 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 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.

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)

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.

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)