Ist denn die Formatierung von SELFHTML so viel komplexer? Hmm,ichfinde, ggf. spezifischer.

Bei den Anschauungsbeispielen "lebt" SelfHTML davon, vorführen zu können, wie bestimmte Anweisungen im Browser aussehen bzw. funktionieren.

durch zentrale CSS-Klassen-Definitionen, welche dann genau wieder das Layout-Korsett liefern würden, was das bisherige SelfLayout auch schon geliefert hat - und welche jeder Verfasser neuer Beiträge dann natürlich lernen müsste.

Die Struktur sollte das CMS/der Editor vorgeben, dargestellt mit semantischen "Anweisungen".

Aber das tut MediaWiki nicht. Genau diese semantischen Anweisungen sind es ja, die einen "ungelernten" Besucher wieder abschrecken würden.

• Die in MediaWiki angebotene (und in Wikipedia verwendete) Suche liefert nach meiner bisherigen Erfahrung Links auf Dokumente, nicht auf Dokumentpositionen.
  Yep, da wäre Überlegung angesagt. Vorstellen könnte ich mir eine rein semantische "Link-Datenbank", in der die semantischen URLs in ihre realen (inkl. Anker) konvertiert werden.

Was ändert das? Die in MediaWiki integrierte Suche ist nicht modular ersetzbar. Wenn das Wiki für Lesen und Eingabe von Texten verwendet wird, dann wird die überall sichtbare integrierte Suche selbstverständlich auch verwendet. Und die produziert keine Links auf Kapitel, sondern Links auf Artikel.

Wobei ich, ehrlich gesagt, kein Freund bin von x Methoden & Eigenschaften auf einer Seite, nur weil sie zu einem Objekt gehören. Ich tendiere eher zu 1 Methode/Seite, die wiederum zu einer Kollektion eines (oder mehrere) Objekte gehört. Also z.B. innerHTML als Seite, die erreichbar ist vom IE-DOM (all) und W3C-DOM (getElement...).

Aber "innerHTML" ist gemäß der bisherigen Struktur von SelfHTML ein Element einer Gruppe inhaltlich zusammengehöriger Elemente, die in einem gemeinsamen, kapitel-strukturierten HTML-Dokument beschrieben wird. In der bisherigen Implementierungsform hast Du beides - sowohl den Zusammenhang aller "verwandten" Sprachelemente in einem Dokument als auch die deep links der Suchfunktion direkt auf das gesuchte Element. Bei MediaWiki müsstest Du Dich zwischen diesen beiden dort unvereinbaren Anforderungen entscheiden.

Für jeden Treffer müsste der Suchende den kompletten Artikel durchlesen, um zu begreifen, wieso die Suchfunktion ihn überhaupt dorthin geschickt hat.
Ja, wenn man über die Suchfunktion geht (und: ist das jetzt anders?).

Ja, ist es - wegen der deep links.

»»Also müsste SelfHTML in Wiki-Form mit einer _semantisch_ schlechteren Suchfunktion als das bisherige Angebot leben (und das "kurz bevor" die neue Suchfunktion endlich fertig wird... ;-).
Das sehe ich als zwingend an, daß während des Übergangs das Wiki die schlechteren Ergebnisse liefert. Aber nur weil man nicht bei 100% startet, muß man es ja nicht gleich ganz sein lassen. ;-)

Willst Du die integrierte Suchfunktion von MediaWiki umprogrammieren?

Aber wodurch definiert sich "Wiki"? IMHO erstmal darin, daß jeder relativ unkompliziert Änderungen/Ergänzungen/neue Einträge vornehen kann. Wenn das erfüllt ist, ist's mir grad egal wie's heißt. ;-)

Den Benutzern, die ein bestimmtes, verbreitetes Wiki gewohnt sind (nämlich von Wikipedia etc.), möglicherweise nicht.

Ein weiterer Grund, klein (also manuell) anzufangen. So sieht man schnell, wo Handlungsbedarf ist -oder ob es überhaupt nicht funktioniert.

Ganz im Gegenteil: Du siehst dann erst nach Monaten die wirklich schweren bis unlösbaren Probleme. Wenn du die einfachen Probleme maschinell lösen kannst, bleiben viel früher die schweren übrig.