Hi,

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.

Ich denke da eher "einfacher". Der User soll von der Semantik selbst tunlichst wenig mitbekommen. D.h., das GUI des Editors muß da als Mittler dienen.

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?

Man könnte die Struktur von SELFHTML (viele "Artikel" auf einer Seite addressiert durcht Ankern) beibehalten - inkl. der bisherigen Linkstruktur. Aber wie gesagt: Ich finde, man sollte das bei dieser Gelegenheit ohnehin ändern.

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.

Findest Du? Ich habe einen Artikel über das all-Objekt mit Verweis auch weitere Artikel, wo (jeweils) die Methoden dss Objekts beschrieben sind (u.a. innerHTML & innerText). Ich habe ferner einen Artikel über getElement... oder konkret z.B. getElementById, wo ebenfalls auf entsprechende Artikel verwiesen wird (in der Liste fehlt dann z.B. innerText). Das jetzige System, DOM-Methoden sowohl unter all zu listen, wie auch unter node, finde ich suboptimal (gelinde gesagt). Da gibt es (neben den Unvollständigkeiten) vieles, was (unnötigerweise) doppelt ist, oder?

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.

? Was verstehst Du dann unter "deep link"? Wenn ich die Doku zu setAttribute() suche, dann hilft es mir doch eher, wenn ich in der Suche die entsprechende Seite(n) angezeigt bekomme, als wenn ich, wie jetzt, eine riesige Seite bekommen, mit allen Methoden des all- und eine weitere Seite mit allen Methoden des node- und eine dritte mit allen Methoden des style-Objekts, wo dann irgendwo auf dieser Seite u.a. auch (jeweils) setAttribute() abgehandelt wird.

»»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?

Nö. Ich setze nur als gegeben voraus, daß ein SELFWiki erstmal schlechter sein wird, als SELFHTML.

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.

Tja nun, wir schreiben hier auch in einem Forum, und nicht wie der Rest der IT-Welt in einem Board. :))

Gruß, Cybaer