We might want to reconsider the 'absolute' support when it comes to
browsers. Do remember that we are also using YUI for the other things.
You noted an error in Netscape 7.1 but if you go and look at YUI's
graded browser support, Netscape isn't even on there as an A-Grade
browser, which means that our normal fancy things aren't meant to
support Netscape. So an error in another browser might be something of
not to much consequence.
http://developer.yahoo.com/yui/articles/gbs/
Hidden text, or hidden inputs?
Well on the note of extra hidden inputs, there's something I should
note. I haven't setup the code yet, but I'm hoping that FCKeditor can be
altered to use the wikitext inside of the textarea field instead of
having the HTML there. Even if that requires adding a hidden field
containing the html that is currently stored there. This is because
right now you need to disable the editor from your preferences if your
browser cannot support it. The editor should be able to leave a good
fallback if a user has no JS enabled. Also, the use of the diff preview
does not work because it is sent html instead of WikiText. But
considering that you can easily switch to a WikiText mode it should be
possible to have it send that data to the diff.
There's also another proposal I'm hoping they'll accept. (Because I'd
rather help contribute to the FCKeditor+MediaWiki project, then start a
fork of it) Many editors dislike the notion of WYSIWYG, but by far would
Love a syntax highlighter. I managed to get EditArea to work purely with
userjs, though my WikiText syntax file isn't to good, and the syntax
Highlighter inside of EditArea is to limited. It does not support
languages inside languages, and I can't create disabling matches such as
making <pre> or <nowiki> disable highlighting in an area.
Because of this, I'm hopping to create a third Syntax Highlighting mode
in FCKeditor+MediaWiki. I'm hoping to use the techniques in some of the
better JS Syntax Highlighting tools (not specifically the editors) and a
few of my own ideas, to create a good one as part of the editor.
In addition to that I'm thinking of a few plugin ideas. Such as requests
to be able to grab WikiText from another Wiki such as Wikipedia or
another Wikia wiki and import it into the current page.
I also do have a small liking to all the preview modes that are
possible, and am hoping to create ways to let users use all of them, but
not lose what is there:
* Hard Preview
** Advantages: Reliable, and we know that the display returned is what
is actually going to be displayed after the save.
** Disadvantages: Requires a hard reload of the entire page.
* AJAX Preview (The one currently used in Wikia's WikiWYG editor)
** Advantages: Uses AJAX to avoid the need to reload the entire page and
produce fair results on what is going to be seen.
** Disadvantages: The text is parsed in a method slightly different than
with the HardPreviews, and in some cases may not match what is going to
be outputted. The JS and CSS previews don't work because those require a
page load, and because the preview is contained inside of a nice extra
box and has no onload, some of the site's CSS won't properly apply to it
so you can't preview that, and since there is no page load, JS like the
Show/Hide, Sortable Tables, or a tab view cannot be previewed.
* WYSIWYG mode
** Advantages: No page load times, and it is possible to edit the HTML
preview that you are seeing so the preview is live.
** Disadvantages: Things like templates, and other things are not viewed
using this method. The html used is not the real html that comes out
from a preview, but instead a mangled one used to allow you to see what
you need to edit. So most css styling and other things will not apply to
the live preview.
As you can see, each mode has it's advantages and disadvantages.
Currently, Wikia's WikiWYG is one which only uses the AJAX preview
method. And the FCKeditor+MediaWiki uses WYSIWYG and Hard Preview.
I'm hoping to add the ability to grab a proper preview for FCKeditor
through AJAX to allow people to use the widest range of previews
possible there are good reasons to use each of them.
I'm also hoping to add a few more abilities to the editor:
* Customize the built in CharInsert to make it a viable replacement for
the normal CharInsert box.
* Allow support for other external libraries like YUI. Some wiki like
Wikia and even me at Wiki-Tools are comfortable with loading a UI like
YUI. FCKeditor currently uses it's own stuff. And while nice the editor
is nice, I have an issue with the popup window used for things like the
charinsert. Browsers with popup blockers will have issues with these
that may confuse normal readers, and on a common browser it at times can
take a bit for these to load. If you're doing a lot of inserts, then
using these popup windows is very annoying. So i'm hoping to have an
option for people to enable the use of external UI's like YUI and it's
containers to replace the use of the windows when a site has them installed.
* I'm also hoping to make some buttons like the bold, italics, etc...
Buttons work to insert the code when you are in modes such as syntax
highlight and plain WikiText.
~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment
Project, and Wiki-Tools.com
Bjørnar Grip Fjær wrote:
> Hello,
>
>
>
>> For FSKEditor and MediaWiki, we took a look at that before venturing
>> down the path of making our own. Here are some of the things I saw on
>> the FSKEditor extension page that led us to our decision:
>>
> I assume this is a typo, and it's FCKEditor being discussed?
>
>
>
>> * On a per-page-basis: Do not add the token "__USE_EDITOR__" on an
>> existing page which contains standard wiki syntax. The fckeditor
>> removes line breaks which corrupts your page layout. (But don't
>> panic, the history function is always available.)The text is
>> stored as *HTML* in the database.
>>
>
> If you run $wgParser->parse(...) in the getContent function under
> includes/EditPage.php you can give the FCKEditor HTMLcode instead of
> Wikicode, so it doesn't mess up anything. This ofcourse gives you a
> table of contents etc as well, but that's easilly removed with a
> couple of preg_replace. It also removes the categories, which can be
> gathered with a preg_match before the content is parsed and appended
> or prepended (whichever you preffer) after the content is parsed.
> There's also the issue with templates, one way to do this is when you
> get the content before you parse it to HTML you use:
> $content = preg_replace('/({{[\w\d\ ]*}})/i', '<nowiki>$1</nowiki>',
> $this-mArticle->getContent());
>
>
>
>> * Removal of unwanted, hidden text properties can be a hard job in
>> some cases.
>>
>
> Do you have any examples?
>
>
>
>> * Using Netscape 7.1 browser, you cannot use the "browser page-back"
>> navigation function beyond a page, where the WYSIWYG editor was
>> invoked for page editing.
>> * /Paste/ function (pasting clipboard content) seems to be
>> prohibited - at least when using Netscape 7.1 browser.
>>
>
> Haven't had this problem with any other browsers.
>
>
>
>> The biggest issue for us, obviously, was that it stored data as HTML.
>> However, I see this page created as of July 17th, 2007(
>> http://mediawiki.fckeditor.net/index.php/Main_Page ) that discusses it
>> storing wikitext, so we need to take another look.
>>
>
> A simple XML parser can parse the content to Wikicode before it's
> saved in the database. PHPs xml_parse should work fine.
>
>
>> Thanks,
>> John Q.
>>
_______________________________________________
Wikia-l mailing list
[email protected]
http://lists.wikia.com/mailman/listinfo/wikia-l
