What’s wrong with the Geshi extension? It’s actively maintained and is used by a number of high-profile Mediawiki sites, including Wikipedia.

This extension is being used on one or more of Wikimedia’s wikis. It means that the extension is stable and works well enough to be used by such high traffic websites.

Eric: any chance that research is published somewhere? We’re looking at migrating from a MediaWiki to DekiWiki – and part of that involves some evaluation & research. I’m hoping to be lazy and take a look at some of what you guys did for MDC.

From my exploration of the limited documentation I have not been able to find what the capabilities of the WYSIWYG style editor are. Is there a ‘edit source’ mode to edit the xhtml/etc. code directly? Or do human editors that need to edit a page that cannot be edited with the WYSIWYG editor have to submit revisions with an external tool?

For example, is it possible to create per-page CSS for use in tables (where it is much less readable and maintainable to mark the style of each cell individually)? That has been a holdup for introducing flowable, editable component block diagrams in html such as in this mockup page (best viewed with Mozilla browsers) from bug 334225 (”CSS style rules for component stack diagrams, component block diagrams”).

For anyone looking for prerequisites documentation, unfortunately the download links take you directly to a sourceforge download, not to a download description page. (240MB is too much for some of us to wait to download without having a clue whether it will be able to run.) Site search field didn’t help much; I eventually had more success with off-site Google.

https://help.mindtouch.com/Deki_Deployment/System_requirements

http://wiki.opengarden.org/Deki_Wiki/Installation_and_Upgrade

http://wiki.opengarden.org/Deki_Wiki/Installation_and_Upgrade/Installation_FAQ/Deki_Wiki_Dependency_Lists

So everything’s stored as XHTML? I’m curious how well this roundtrips edits, because if it doesn’t do so well it limits you to the flexibility that the WYSIWYG interface exposes. I’m also minimally concerned about consistent style (particularly for some of the things we attack with templates right now), but I guess the intent is that editors not have to think about that. If you drop to source-editing mode, do you get a pretty-printed version that’s more amenable to edits?

How do intrawiki links work at source level for preserving wiki location migration?

Does it have support for some form of a prebuilt page store, so that, say, I can copy the format of a CSS property page when documenting a new property on a new page?

What support is provided for articles intended to be read in series, or for books presented in chapters?

I’m sure I have more questions to ask, but I should definitely put off asking them to a different time.

The top menu at wiki.mindtouch.com relies on javascript. I can’t seem to find a demo of dekiwiki, the best I can hope for is that it’ll work without script as I regularly consult MDC for the DOM and Javascript materials.

I have complained loud about invalid markup code regarding the current MDC, regarding the webpages themselves and regarding the examples (having validation markup errors or using/relying on transitional DTD) shown for demonstration purposes in the webpages. Deki Wiki is not (will not be) an improvement in that regard. MDC currently does not teach by example and the proposed changed is not an improvement.

Code validity, clear separation of content from presentation, triggering standards compliant rendering mode, semantic markup, properly structured markup code, CSS code reusability, etc.. are important and should always be important.

Many authors have said that XHTML is dead. Why do we keep authoring with XHTML served as text/html? A few years ago, mozilla.org style and markup guidelines were set: why MDC never followed such guidelines, authoring guidelines?

Transitional DTD: why is that in end of 2007?

Gérard