Aloha ;)
Ich klinke mich jetzt, nachdem ich extra darauf aufmerksam gemacht wurde und den ganzen Thread gelesen habe, mal an dieser Stelle willkürlich ein.
Erstmal vielen Dank für deine Antwort. Nachdem ich mir mit der Aufbereitung des Themas, der Beschreibung der Probleme und der Vorstellung von Lösungsmöglichkeiten in meinem ersten Beitrag doch einige Mühe gegeben hatte, war ich schon etwas enttäuscht, dass abgesehen von dedlfix lange Zeit überhaupt niemand darauf reagiert hat. ;-)
Nun ja. Die Zeit, die ich, beispielsweise, in der letzten Woche im Forum verbracht habe ist sehr überschaubar - ich hatte deinen Thread also nichtmal gesehen ;)
Abgesehen davon: Du machst es einem nicht einfach :P Versuch mal, dich kürzer zu fassen - nötigenfalls auch wenn das bedeutet, dass du nicht jeden relevanten Aspekt beleuchten kannst. Es ist nicht zielführend, die Leser so mit Fakten zu bombardieren - und selbst ich hab manchmal Probleme, die Aufmerksamkeit dann lange genug aufrecht zu erhalten, um den springenden Punkt wirklich zu erkennen.
Gerade wenn du ein breites Meinungsbild möchtest (was angesichts der Thematik auch von Bedeutung ist, immerhin schlägst du weitreichende Veränderungen vor), dann muss du auch sicherstellen, dass nicht die Hälfte der Leserschaft schon am Eröffnungsposting hängen bleibt und nach etwa der Hälfte des Postings beschließt "ach, wird schon stimmen" oder "ach ne, so viel les ich jetzt nicht". Und ich garantiere dir, das ist der Fall - weils auch mir so geht, und ich bin normalerweise der, der die Romane schreibt.
Wie ich sowohl in meinem Eröffnungsbeitrag als auch schon bei früherer Gelegenheit deutlich gemacht hatte, halte ich eine strikte Trennung zwischen dem ‚Sprachkern‘ von JavaScript (ECMAScript) und den verschiedenen nicht zur Sprache selbst gehörenden Schnittstellen für absolut unabdingbar, und ich hoffe, dass, zumindest was dieses Ziel angeht, soweit Konsens besteht.
Leider nein. Zumindest nicht mit mir. Leider wirklich absolut nicht.
Worauf du rausmöchtest, wenn ich mal etwas übertrieben formulieren darf ist, dass wir im Wiki in Zukunft eine Einführung in ECMAScript haben und eine Einführung in die diversen APIs haben werden. Das halte ich nicht für sinnvoll. Meiner Meinung nach behandelt unser Wiki nicht ECMAScript und auch nicht die APIs, meiner Meinung nach behandelt unser Wiki JavaScript.
JavaScript mag aus diesen Bestandteilen bestehen, daraus lässt sich aber keine Notwendigkeit ableiten, die Bestandteile einzeln zu behandeln.
Wir versuchen im Wiki nicht, einen möglichst allgemeinen Weg zu gehen, sondern wir versuchen unseren Lesern praxisnah Verständnis zu vermitteln. Es ist aber alles andere als praxisnah, wenn man die Trennung von Sprachkern und API zelebriert - denn die hat in der späteren Verwendung von JavaScript (als Webtechnologie im Browser (!)) keinerlei Relevanz. Inwiefern spielt es eine Rolle, ob eine Eigenschaft/Methode im DOM definiert ist oder in ECMAScript? MMn überhaupt nicht. Wer zu uns kommt möchte JavaScript lernen um es später innerhalb einer Website einzusetzen, und die Eigenschaft/Methode ist Teil von JavaScript - vollkommen unabhängig davon, ob sie zu DOM oder zu ECMAScript gehört.
Ich gehe vollkommen mit @dedlfix, wenn es darum geht, die Zuordnung innerhalb des Artikels kenntlich zu machen, denn da gehört sie auch hin. Natürlich sollte in einem Artikel zu einer Methode stehen, in welcher Spezifikation sie definiert ist. Diese Information ist aber für das Verständnis von JavaScript und vor allem für das Erlernen von JavaScript für den Einsatz auf Webseiten vollkommen irrelevant. Es ist "nice to know", aber mehr auch nicht - vor allem für Anfänger.
Mir fällt kein Fall ein, in dem mir als Webentwickler aus dem Unwissen über die Trennung zwischen ECMAScript und DOM ein Nachteil erwächst - außer, falls ich irgendwas in der Spec nachschlagen will. Und dafür reicht es dann vollkommen, wenn im Inhalt des Wiki-Artikels die Zuordnung zur entsprechenden Spezifikation enthalten ist.
Wenn du die Trennung zwischen ECMAScript und APIs in der Struktur des JavaScript-Bereichs abbilden willst, dann räumst du dieser mehr Raum ein als sinnvoll ist - mit haufenweise negativen Folgen wie einer schlechteren Erreichbarkeit (weil tiefe statt flache Struktur) oder dem Overhead zum Finden eines Artikels (weil man dazu ja erstmal wissen muss, ob die Eigenschaft/Methode Teil von ECMAScript ist oder nicht) und keinerlei positiven Folgen, außer, dass die Beschreibung ein wenig fachlich-theoretisch sinnvoller ist.
Ich sehe aber das Hauptziel des Wikis bzw. der Selfhtml-Dokumentation nicht in einer fachlich-theoretischen Korrektheit (das auch, aber sekundär) sondern darin, sowohl für Anfänger als auch für Fortgeschrittene eine Einführung und ein Nachschlagewerk zu Webtechnologien zu sein. Wenn es für einfacheres und schnelleres Verständnis sinnvoll ist, theoretische Fakten erst unter der Oberfläche und für die, die es wirklich interessiert, anzubieten, dann sollte das auf jeden Fall getan werden.
Und das ist genau das was passiert, wenn die Trennung zwischen ECMAScript und APIs eben nicht strikt ist, sondern nur im Inhalt der jeweiligen Artikel für die Interessierten aufgelistet ist. Das fällt unter den Begriff didaktische Reduktion, d.h. eine Fokussierung auf die für das Verständnis wesentlichen Aspekte; eine Differenzierung auf Ebene theoretischer Feinheiten (und nichts anderes ist die Trennung zwischen ECMAScript und APIs) kann dann erfolgen, sobald grundsätzliches Verständnis erzeugt wurde.
Leser kommen mit ganz klarer Zielstellung zu uns ins Wiki: um zu lernen, wie sie JavaScript auf ihrer Webseite einsetzen können. Alles, was zum Erreichen dieses Ziels nicht nötig ist oder den Weg dahin sogar erschweren könnte, sollte vermieden werden oder in einer Form vermittelt werden, die Anfänger "überlesen" können.
TL;DR: Tut mir leid, ich bin an allen Stellen dagegen, die Trennung zwischen den Einzelteilen zu thematisieren, in denen die Zugänglichkeit zum Verständnis des Gesamtbilds dadurch verkompliziert wird - was der Fall ist, wenn die Struktur darauf angepasst wird.
@Matthias Apsel: Habe ich nun genug Ahnung für berechtigten Einspruch oder muss zuerst noch jemand anderes widersprechen? :P
Grüße,
RIDER
Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller Erreichbar manchmal im Self-TS (ts.selfhtml.org) oder sonst - wenn online - auf dem eigenen TeamSpeak-Server (fritz.campingrider.de) oder unter: # Facebook # Twitter # Steam # YouTube # Self-Wiki # ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[