Orlok: Schnittstellen

Hallo

Wie einige von euch sicherlich festgestellt haben, liegt in Bezug auf die Struktur der JavaScript-Sektion im Wiki immernoch vieles im Argen, sprich, die Trennung des Sprachkerns ECMAScript von den verschiedenen Schnittstellen einerseits, so wie andererseits auch die Abstraktion zwischen den diversen APIs selbst ist nach wie vor unzureichend, auch wenn es hier, dank des Engagements von Matthias Scharwies, gegenüber dem früheren Zustand bereits Fortschritte zu verzeichnen gibt.

Tatsächlich ist die korrekte Abbildung der diversen Schnittstellen, der built-in objects und ihrer Eigenschaften und Methoden keine ganz triviale Aufgabe, wobei die Arbeit hier unter anderem dadurch erschwert wird, dass im Wiki ja nicht bei null angefangen wird, sondern eine bereits bestehende Struktur transformiert werden muss.


Zur Veranschaulichung des Themas sei vielleicht zunächst ein kleines Beispiel angeführt:

(function (param) {
  var get = Object.getPrototypeOf;
  var proto = get(param), con;
  while (proto !== null) {
    con = proto.constructor;
    console.log(con.name || con);
    proto = get(con.prototype);
  }
}(document.body));

Hier haben wir zunächst einen anonymen IIFE (Immediately-Invoked Function Expression), welchem das Element Body als Argument übergeben wird, wobei dieses über die Eigenschaft gleichen Namens des Objektes document referenziert wird. Diese Eigenschaft stellt eine HTML-spezifische Erweiterung der Schnittstelle Document des DOM dar. In der Praxis bedeutet dies, dass die Eigenschaft mit dem Bezeichner body je nach Implementierung entweder eine eigene Eigenschaft des Objektes ist, welches in der prototype-Eigenschaft des Konstruktors HTMLDocument hinterlegt ist, oder aber sie wird direkt von Document.prototype an die Instanz document vererbt, wobei ich Letzteres für keine gute Entscheidung der einschlägigen Browserhersteller halte, da hierbei eigentlich separate Schnittstellen vermischt werden.

Innerhalb der Funktion wird nun zunächst die Methode getPrototypeOf des Konstruktors Object der lokalen Variable mit dem Bezeichner get als Wert zugewiesen. Wird dieser Methode bei ihrem Aufruf ein Objekt übergeben, dann gibt sie den Wert der internen Eigenschaft [[Prototype]] dieses Objektes zurück, also gewissermaßen den nächsten Vorfahren innerhalb der jeweiligen Prototypenkette.

Diese Methode wird nun in einem nächsten Schritt für den mit Body initialisierten Parameter der Funktion aufgerufen und der Rückgabewert in der Variable mit dem Bezeichner proto hinterlegt. Die folgende Schleife sorgt nun dafür, dass solange der Wert von proto nicht null ist, der Wert der prototype-Eigenschaft constructor in der Variable con gespeichert wird. Der Wert dieser Eigenschaft ist wie der Name schon vermuten lässt immer eine Referenz auf den jeweiligen Konstruktor, dessen Name in einem nächsten Schritt in die Konsole geschrieben wird, sofern die Eigenschaft name unterstützt wird. Dies geschieht freilich unter Verwendung des nicht standardisierten Console-API, dessen Instanzobjekt im globalen Namensraum Eigenschaft des von Browser bereitgestellten window-Objektes ist. Schließlich wird proto für den nächsten Schleifendurchlauf mit dem Prototypen des Vorfahren initialisiert. Die Prüfung gegen null erflogt hier, da dies der Wert der internen Eigenschaft [[Prototype]] von Object.prototype ist, welche das letzte Glied in der prototype chain darstellt. Im Ergebnis werden dann dem zur Folge durch die Funktion alle Namen der Konstrukoren eines Objektes in die Konsole geschrieben, was für Body im Firefox so aussehen würde:

HTMLBodyElement
HTMLElement
Element
Node
EventTarget
Object

Diese built-in objects repräsentieren hier also die verschiedenen Schnittstellen, die Eigenschaften und Methoden an das Objekt vererben, welches das Element Body repräsentiert, wobei sich die jeweiligen Implementierungen allerdings wie bereits gesehen in Details unterscheiden können.

Jedenfalls beginnt die Kette hier erwartungsgemäß mit Object, welches bekanntermaßen Teil des Sprachkerns ECMAScript ist. Dann haben wir hier die Schnittstelle EventTarget des DOM, welche unter anderem die Methode addEventListener an unser Element vererbt. Weiterhin werden Eigenschaften und Methoden der Schnittstellen Node und Element des Document Object Models vererbt, wie etwa die Eigenschaft textContent durch Node.prototype oder die Eigenschaft tagName durch Element.prototype. Schließlich vererben die HTML-spezifischen Schnittstellen HTMLElement und HTMLBodyElement eigene Eigenschaften wie beispielsweise offsetTop oder onhashchange.

Es wird also deutlich, dass wenn es das Ziel des Wikis sein soll, eine halbwegs präzise Vorstellung vom Zusammenwirken der verschiedenen Schnittstellen zu vermitteln, der Aufbau der Sektion auch die tatsächlichen Strukturen entsprechend soweit wie möglich widerspiegeln sollte, womit wir dann beim derzeitigen Stand der Dinge angelangt wären.


Dem aufmerksamen Beobachter wird wie eingangs bereits erwähnt aufgefallen sein, dass sich in der letzten Zeit hier durchaus einiges getan hat. So wurde beispielsweise die Rubrik DOM aus der Rubrik Objekte herausgelöst und bestehende Artikel wurden neu gegliedert.

Nichtsdestotrotz ist die Aufteilung meiner Ansicht nach jedoch noch nicht ideal. Zwar sind nun innerhalb der Rubrik Objekte die built-in objects von ECMAScript, also etwa Object, Function oder Math, von nicht zugehörigen Objekten optisch abgesetzt aufgelistet, jedoch sollten diese nicht zum Sprachkern gehörigen Objekte im Sinne einer strikten Trennung von Sprache und Schnittstellen dort eigentlich gar nicht stehen, sondern statt dessen unter APIs aufgeführt sein. – Also, nochmal zur Verdeutlichung, im Moment sieht es so aus:

Objekte

  • navigator
  • screen
  • window
    • document
      • forms
        • elements
    • history
    • location

|und davon leicht abgesetzt|

  • Object
  • Array
  • Boolean
  • Date
  • Function (usw.)

Hier fällt zunächst einmal auf, dass mindestens einmal der Artikel zu document deplaziert ist. Das Instanzobjekt document ist zwar wie alle eingebauten Objekte als Bestandteil des globalen Namensraums Eigenschaft des Objektes window, aber im Sinne der inhaltlichen Zugehörigkeit sollte dieser Artikel neben node unter der Rubrik DOM aufgeführt sein, dessen Schnittstelle Document es repräsentiert, und bei den Eigenschaften von window lediglich verlinkt werden. Was die forms-Schnittstelle angeht, so handelt es sich hier ebenso wie bei der Dokumenteigenschaft body aus dem Eingangsbeispiel um eine HTML-spezifische Erweiterung der Schnittstelle Document des DOM. Dazu aber später noch etwas mehr.

Jedenfalls denke ich, dass die Punkte Window, Screen, Location, Navigator und History am besten unter einer gemeinsamen Rubrik Browser zusammengefasst werden sollten, wobei die Objekte zwar auch als Eigenschaften von window aufgeführt und entsprechend verlinkt sein sollten, sie jedoch wie ich meine davon abgesehen als separate Punkte aufgelistet gehören.

Browser

  • Window
    • document (link)
    • innerHeight
    • innerWidth
    • navigator (link)
  • Navigator
  • History
  • Location
  • Screen

Die Auswahl an Unterpunkten zu Window ist jetzt hier nur zu Demonstrationszwecken aufgelistet. Auf der Startseite der JavaScript-Sektion würde es wohl genügen wenn die entsprechenden Listenpunkte erst beim Klick auf die Überschrift Browser beziehungsweise auf Window sichtbar werden. Darüber hinaus denke ich, dass diese gemeinsame Rubrik Browser ebenso wie zuvor schon die Rubrik DOM aus Objekte herausgelöst und auf die rechte Seite des Zwei-Spalten-Layouts verfrachtet werden sollte.

Es bietet sich in dieser Hinsicht wie ich meine gerade zu an, die beiden Spalten zur Trennung von Sprachkern und Schnittstellen zu verwenden und entsprechende Überschriften einzufügen. Denn momentan ist es ja noch so, dass von der Vermischung innerhalb von Objekte einmal abgesehen, auch die Überschriften auf der rechten Seite des Layouts etwas missverständlich sind:

  • DOM
  • Event
  • APIs

Denn einerseits sind Event und EventTarget Schnittstellen des DOM, und andererseits ist das Document Object Model selbst natürlich auch eine Ansammlung von Schnittstellen, weshalb hier beim dritten Punkt wenn überhaupt die Überschrift andere APIs sinnvoll erschiene.

Jedenfalls habe ich mir über diesen Aspekt meine Gedanken gemacht und bin zu dem Ergebnis gekommen, dass es erstens, im Gegensatz etwa zur Handhabung im MDN, nicht sinnvoll ist, die „Web-APIs“ aus der JavaScript-Sektion vollkommen auszugliedern, zumindest nicht, solange JavaScript als Sprache der Browser keine ernsthafte Konkurrenz erwächst, und dass es zweitens notwendig ist, wenn man sich schon entscheidet, die Schnittstellen grundsätzlich in dieser Sektion des Wikis zu belassen, sowohl durch Überschriften als auch hinsichtlich der optischen Gliederung die Trennung von Sprachkern und APIs klar zu kommunizieren. Ich würde also dazu tendieren, die Überschrift APIs als globale Überschrift für die rechte Spalte einzusetzen, so dass diese Seite hernach etwa so auschauen würde:

APIs

  • DOM

    • Document
    • Node
    • Event (usw.)
  • Browser

    • Window
    • History (usw.)
  • Console

  • Geolocation

  • File Upload

  • WebGL (usw.)

Dabei sollte man vielleicht auch darüber nachdenken, ob APIs als Überschrift allein aus Anfängersicht gesehen so aussagekräftig ist. Vielleicht wäre es doch besser hier von ‚Schnittstellen‘ zu sprechen!?

Um abschließend nocheinmal auf die Abgrenzung zwischen DOM und HTML zurückzukommen: Ich denke, hier muss nicht zwingend eine eigene Rubrik eingerichtet werden, schon allein weil die Implementierungen hier nicht immer einheitlich sind, aber es sollte sowohl bei der Beschreibung der DOM-Objekte als auch bei der Auflistung der Eigenschaften und Methoden so klar wie möglich abgegrenzt werden.


Soweit meine Ansicht zum Thema. Vielleicht hat ja noch jemand Ideen, wie die Sektion besser zu gliedern wäre? Das würde mich interessieren! Und ich möchte am Ende auch noch einmal darauf hinweisen, dass unabhängig von den geäußerten Erwägungen gerade in der DOM-Rubrik ein paar ausführlichere Beschreibungen von Nöten sind. – Es wäre toll, wenn sich da jemand einbringen würde! ;-)

Gruß,

Orlok

--
„Das Wesentliche einer Kerze ist nicht das Wachs, das seine Spuren hinterlässt, sondern das Licht.“ Antoine de Saint-Exupéry

akzeptierte Antworten

  1. Tach!

    Soweit meine Ansicht zum Thema. Vielleicht hat ja noch jemand Ideen, wie die Sektion besser zu gliedern wäre? Das würde mich interessieren!

    Die Frage ist nicht nur, ob das formal technisch korrekt abgebildet werden soll beziehungsweise muss (was ja nicht in allen Punkten wegen der unterschiedlichen Implementierungen klappt), sondern vor allem auch, wie es der Leser erwartet, sonst hagelt es wieder Beschwerden, dass man da nichts finde. Da, wo der gemeine Leser keine Trennung vornehmen würde, weil man das üblicherweise einfach zusammen verwendet, ohne sich groß einen Kopf um die Zugehörigkeiten zu machen, kann man das ruhig auch so darstellen, finde ich. Das kann dann im Text näher erklärt werden, vielleicht als Textbaustein, weil es ja öfter eingebaut werden muss. Oder gibt es gewichtige Gründe, das unbedingt zu trennen, weil es sonst für das allgemeine Verständnis ungünstig ist, oder ähnliches?

    dedlfix.

    1. Hallo dedlfix

      Die Frage ist nicht nur, ob das formal technisch korrekt abgebildet werden soll beziehungsweise muss (was ja nicht in allen Punkten wegen der unterschiedlichen Implementierungen klappt) […]

      Nur kurz dazu: Wie schon mehrfach gesagt ist es zwar richtig, dass sich die Implementierungen im Detail unterscheiden, aber auch wenn eine bestimmte Eigenschaft beispiels- und sinnloserweise im IE direkt Document.prototype zugeschlagen wird, obwohl dies eigentlich eine HTML-Erweiterung ist, heißt das ja nicht, dass dieser Browser HTMLDocument grundsätzlich nicht implementiert hätte. Dieses Argument ist in meinen Augen nur von geringem Gewicht, da es erstens kein Problem ist, welches exklusiv in Bezug auf JavaScript besteht, und da zweitens auch nur vergleichsweise wenige APIs oder Teile davon betroffen sind und im Wiki ja auch genug Raum ist, entsprechend auf die Unterschiede hinzuweisen.

      […] sondern vor allem auch, wie es der Leser erwartet, sonst hagelt es wieder Beschwerden, dass man da nichts finde.

      Ich würde meinen, der Leser erwartet im Wiki vor allem „formal und technisch korrekte“ Beschreibungen der behandelten Materie. Sicher, aus der Sicht eines kompletten Anfängers macht es keinen Unterschied, woher die Objekte kommen mit denen er arbeiten kann. Aber es sollte ja nicht das Ziel des Wikis sein, ihn in seinem Unwissen auch noch zu bestätigen, indem die tatsächlichen technischen Hintergründe bewusst verschleiert beziehungsweise verwischt werden.

      Da, wo der gemeine Leser keine Trennung vornehmen würde, weil man das üblicherweise einfach zusammen verwendet, ohne sich groß einen Kopf um die Zugehörigkeiten zu machen, kann man das ruhig auch so darstellen, finde ich. Das kann dann im Text näher erklärt werden.

      Jetzt mal nur bezogen auf die Abgrenzung von DOM und HTML stimme ich dir da absolut zu. Dies war für mich auch einer der Hauptgründe, weshalb ich mich in meinem Posting dafür ausgesprochen hatte, bei den Schnittstellen keine separate Rubrik für HTML-APIs einzurichten, sondern die entsprechenden Informationen im Zuge der Erläuterungen zum Document Object Model einzugliedern. Allerdings würde ich es dann halt gerne sehen, wenn in diesen Artikeln zum DOM dann auf die Unterschiede eingegangen wird. Also, um im Beispiel zu bleiben, dass etwa im Artikel zur Schnittstelle Document entsprechend auf HTMLDocument hingewiesen wird, und bei der Auflistung der Eigenschaften und Methoden auf dieser Seite dann ein extra Absatz und eine Überschrift eingefügt wird, so dass dem Leser die Information zumindest nicht vorenthalten wird und er verstehen kann, dass hier formal betrachtet abstrahiert werden müsste.

      Oder gibt es gewichtige Gründe, das unbedingt zu trennen, weil es sonst für das allgemeine Verständnis ungünstig ist, oder ähnliches?

      Wenn es beispielsweise um die Trennung von ECMAScript und APIs geht, würde ich sagen: Auf jeden Fall! Für mich sind das zwei vollkommen verschiedene Paar Schuhe, und ich kann mir umgekehrt nur sehr schwer vorstellen, welchen Vorteil es für das Verständnis haben sollte, hier nicht zu trennen. ;-)

      Gruß,

      Orlok

      --
      „Das Wesentliche einer Kerze ist nicht das Wachs, das seine Spuren hinterlässt, sondern das Licht.“ Antoine de Saint-Exupéry
      1. Tach!

        […] sondern vor allem auch, wie es der Leser erwartet, sonst hagelt es wieder Beschwerden, dass man da nichts finde.

        Ich würde meinen, der Leser erwartet im Wiki vor allem „formal und technisch korrekte“ Beschreibungen der behandelten Materie. Sicher, aus der Sicht eines kompletten Anfängers macht es keinen Unterschied, woher die Objekte kommen mit denen er arbeiten kann. Aber es sollte ja nicht das Ziel des Wikis sein, ihn in seinem Unwissen auch noch zu bestätigen, indem die tatsächlichen technischen Hintergründe bewusst verschleiert beziehungsweise verwischt werden.

        Wenn im Alltag manche Dinge vermischt werden, ohne dass Nachteile entstehen, warum sollte man das dann zwingend getrennt dokumentieren, wenn sich dadurch auch noch Nachteile in der Benutzbarkeit/Auffindbarkeit ergeben? Es geht mir nicht darum, Dinge zu verstecken oder unter den Tisch fallen zu lassen, sondern um eine gute Balance zwischen Notwendigkeit und Benutzbarkeit. Wenn ich mir zum Finden die Trennung bewusst machen muss, sie aber sonst so gut wie nie notwendig ist, dann empfinde ich das als überflüssig und eher störend als gewinnbringend. Das heißt nicht, dass man die Zugehörigkeit verschweigen soll, sondern nur als nebensächlichen Fakt in die Beschreibungsseite aufnimmt.

        Jetzt mal nur bezogen auf die Abgrenzung von DOM und HTML stimme ich dir da absolut zu. Dies war für mich auch einer der Hauptgründe, weshalb ich mich in meinem Posting dafür ausgesprochen hatte, bei den Schnittstellen keine separate Rubrik für HTML-APIs einzurichten, sondern die entsprechenden Informationen im Zuge der Erläuterungen zum Document Object Model einzugliedern. Allerdings würde ich es dann halt gerne sehen, wenn in diesen Artikeln zum DOM dann auf die Unterschiede eingegangen wird. Also, um im Beispiel zu bleiben, dass etwa im Artikel zur Schnittstelle Document entsprechend auf HTMLDocument hingewiesen wird, und bei der Auflistung der Eigenschaften und Methoden auf dieser Seite dann ein extra Absatz und eine Überschrift eingefügt wird, so dass dem Leser die Information zumindest nicht vorenthalten wird und er verstehen kann, dass hier formal betrachtet abstrahiert werden müsste.

        Genauso meine ich das. Da ist die Trennung eher störend, weil kaum wahrgenommen und unwichtig. Bei den anderen APIs, wie File oder Storage, ist die Trennung geboten, weil sie üblicherweise auch so abgegrenzt wahrgenommen werden und auch die Verwendung der Namen geläufig ist.

        Dass komplette Anfänger sich in das Thema einarbeiten und erst eine Übersicht gewinnen müssen, bevor sie etwas finden, ist klar. Aber für den Einstieg sind ja auch Tutorials gedacht und nicht gleich die API-Beschreibungen.

        Vermutlich sind wir näher beieinander, als du annimmst. Mir war es nur wichtig, den Aspekt zu betonen, dass der Anwender nicht aus den Augen verloren werden darf und man nicht alles nur aus den Augen des Insiders betrachten sollte.

        dedlfix.

        1. Servus!

          Die Frage ist nicht nur, ob das formal technisch korrekt abgebildet werden soll beziehungsweise muss (was ja nicht in allen Punkten wegen der unterschiedlichen Implementierungen klappt), sondern vor allem auch, wie es der Leser erwartet, sonst hagelt es wieder Beschwerden, dass man da nichts finde.

          Bei jeder Neuorganisation sind m.E. auch die Pfade und Hierarchien zu beachten. Die Wikipedia hat alle Seiten im Hauptnamensraum, während bei uns versucht wird, passende Hierarchien zu finden.

          Ein Änderung der Überschrift API in Schnittstellen würde konsequenterweise dann auch die Umbenennung in [[JavaScript/Schnittstellen]] nach sich ziehen, eine Eingliederung des DOM dann also

          [[JavaScript/Schnittstellen/DOM]]

          Wollen wir das?

          Alternativ könnte man analog zu [[JavaScript/DOM]] alles aus [[JavaScript/API/..]] in [[JavaScript/..]] verschieben.

          Ich persönlich war schon stolz, dass die Namensräume Themen: und Artikel: jetzt direkt unter ../Tutorials/.. und ../Anwendung und Praxis/ integriert sind, wobei die Trennung der beiden auch nur sinnvoll ist, wenn es überhaupt Anfängertutorials gibt.

          Dort sehe ich meine Aufgabe und versuche Inhalte zu entwickeln. Ich bin grad an einem DOM-Tutorial dran. Dabei merke ich immer wieder, dass gerade zu DOM und Ereignisverarbeitung noch Inhalte fehlen auf die man im Tutorial verlinken kann.

          |>Und ich möchte am Ende auch noch einmal darauf hinweisen, dass unabhängig von den geäußerten Erwägungen gerade in der DOM-Rubrik ein paar ausführlichere Beschreibungen von Nöten sind. – Es wäre toll, wenn sich da jemand einbringen würde! ;-)

          Full ACK - Die Lücken sind sind in der [ToDo-Liste](http://wiki.selfhtml.org /wiki/Kategorie:ToDo) aufgeführt. Eine Mitarbeit im Wiki ist immer willkommen!

          Wenn ich es schaffe, werde ich zum DOM einige Übersichtsgrafiken (vielleicht sogar in SVG?) erstellen, die zusammen mit Erklärungen vielleicht einige der Überlegungen dieses Thread mit aufnehmen.

          Herzliche Grüße

          Matthias Scharwies

          1. Hallo Matthias Scharwies,

            Bei jeder Neuorganisation sind m.E. auch die Pfade und Hierarchien zu beachten.

            Ja. Vor allem, weil es diese Struktur ja tatsächlich gibt, sie nicht nur von uns ausgedacht wurde, weil wir etwa Brotkrümelnavigationen so toll finden.

            Die Wikipedia hat alle Seiten im Hauptnamensraum, während bei uns versucht wird, passende Hierarchien zu finden.

            Wir bemühen uns, alle Stichpunkte auch im Hauptnamensraum zu haben, wobei das dann natürlich Weiterleitungen sind.

            Bis demnächst
            Matthias

            --
            Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)
            1. Servus!

              Bei jeder Neuorganisation sind m.E. auch die Pfade und Hierarchien zu beachten.

              Ja. Vor allem, weil es diese Struktur ja tatsächlich gibt, sie nicht nur von uns ausgedacht wurde, weil wir etwa Brotkrümelnavigationen so toll finden.

              Nein. Aus den ersten 4 Beiträgen dieses Threads kann man ja schon ableiten, dass es diese Struktur ja [zwar] tatsächlich gibt, sie aber wohl je nach Kontext verschieden angeordnet werden kann.

              Die Drag & Drop API findest du unter:

              Wie man das in eine Struktur gießt, ist halt eben nicht wahr oder falsch, sondern Gegenstand der Diskussion.

              Die Wikipedia hat alle Seiten im Hauptnamensraum, während bei uns versucht wird, passende Hierarchien zu finden.

              Wir bemühen uns, alle Stichpunkte auch im Hauptnamensraum zu haben, wobei das dann natürlich Weiterleitungen sind.

              Natürlich, mir ging's nur drum, bei Umbenennungen und Hierarchien auf der Portalseite [[JavaScript]] auch zu bedenken, wie diese dann in der Seitenhierarchie umgesetzt würden.

              [dedlfix] war es nur wichtig, den Aspekt zu betonen, dass der Anwender nicht aus den Augen verloren werden darf und man nicht alles nur aus den Augen des Insiders betrachten sollte.

              Lieber eine übersichtliche Struktur auf den Portalseiten und Verknüpfungen/Zugehörigkeiten wie

              • window/document

              bzw.

              • DOM/document

              in verständlichen (leider noch zu schreibenden) Artikeln zu illustrieren und zu erklären.

              Herzliche Grüße

              Matthias Scharwies

              1. Hallo Matthias

                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. ;-)

                Wenn es um die Gliederung der Portalseite [JavaScript] geht, denke ich, dass wir die Bereiche Tutorials, Anwendung und Praxis sowie weiterführende Informationen, welche sich weiter unten auf der Seite befinden, an dieser Stelle mal nicht weiter zu diskutieren brauchen. Hierbei möchte ich nur zu bedenken geben, dass der Punkt weiterführende Informationen der Einheitlichkeit wegen vielleicht ebenso wie die anderen beiden Überschriften auf eine eigene Seite verlinkt werden sollte, also [JavaScript/weiterführende_Informationen].

                Worum es hier also eigentlich geht ist der Kopf der Seite mit seinen zwei Spalten, welche, nur um das nochmal zu verdeutlichen, im Moment ja folgendermaßen gegliedert sind:


                [Linke Spalte]

                Sprachelemente [nicht verlinkt]

                • Kommentare
                • Bezeichner (selbstvergebene Namen)
                • Reservierte Wörter
                • Steuerzeichen und besondere Notationen
                • Variablen
                • Datentypen
                • Operatoren
                • Funktionen

                Kontrollstrukturen [nicht verlinkt]

                • Anweisungen
                • Bedingte Anweisungen
                • Schleifen

                Grundlegende Konzepte [nicht verlinkt]

                • Objekte - Eigenschaften und Methoden
                • Module und Kapselung
                • Vererbung
                • Objektverfügbarkeit und this-Kontext

                Objekte [JavaScript/Objekte]

                • navigator
                • screen
                • window
                  • document
                    • forms
                      • elements
                  • history
                  • location

                | Zwei Leerzeilen |

                • Object
                • Array
                • Boolean
                • Date
                • Function
                • Math
                • Number
                • RegExp
                • String

                [Rechte Spalte]

                DOM [JavaScript/DOM]

                • node

                Event [JavaScript/Event]

                • Ereignisüberwachung
                • Übersicht über alle Events

                APIs [JavaScript/API]

                • Canvas 2D
                • Drag & Drop
                • File Upload
                • Geolocation
                • Google Maps-API einbinden
                • IndexedDB
                • Shared Worker
                • Video [nicht verlinkt]
                • Web Animation
                • WebGL (3D Grafik) [nicht verlinkt]
                • Web Storage
                • Web Worker
                • XMLHttpRequest

                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.

                Weiterhin ist festzuhalten, dass wohl dahingehend Einigkeit besteht, dass das DOM und die anderen Browser built-ins grundsätzlich nicht aus der JavaScript-Sektion ausgegliedert werden sollten, so dass die Frage bleibt, wie diese Trennung innerhalb des Portals [JavaScript] am besten darzustellen ist, wobei es mehrere Möglichkeiten gibt.

                Eine Möglichkeit wäre, die Browser built-ins aus dem Kopfbereich komplett herauszunehmen und direkt darunter einen eigenen Abschnitt einzufügen, also analog zu Tutorials oder Anwendung und Praxis. Eine andere und meiner Ansicht nach bessere Möglichkeit wäre, die Aufteilung innerhalb des Kopfbereichs vorzunehmen, indem etwa der rechten Spalte eine globale Überschrift gegeben wird, wie ich das in meinem Eröffnungsbeitrag beispielhaft dargestellt hatte. In beiden Fällen wäre das Kriterium der Abgrenzung wohl hinreichend erfüllt.

                Auch hinsichtlich der zu wählenden Überschriften kommen mehrere Möglichkeiten in Betracht, wie zum Beispiel APIs, Schnittstellen, Browser-APIs oder auch Browser built-ins, wobei sich letztere an der Sprachregelung der ECMAScript 2015-Spezifikation orientieren würde. Die Bezeichnungen APIs und Schnittstellen kommen mir hier etwas zu unbestimmt daher, weshalb für mich nach reiflicher Überlegung eigentlich nur Browser-APIs und Browser built-ins in die engere Auswahl kommen, wobei der jeweilige Begriff auf der verlinkten Seite einleitend nochmal erklärt werden kann, so wie es ja im Moment auf der Seite [JavaScript/API] auch schon der Fall ist. Umgekehrt wäre dann die Rubrik Objekte, welche dann nur noch die ECMAScript-eigenen APIs enthält, meiner Ansicht nach idealerweise in Standard-APIs oder Standard built-ins umzubenennen.

                Wie ich an anderer Stelle bereits erwähnt hatte, halte ich es für wichtig, dass die Struktur des Portals grundsätzlich die tatsächlichen Implementierungen reflektieren sollte, soweit dies überhaupt möglich ist. Aber ich sehe auch, ebenso wie dedlfix, dass an manchen Stellen Zugeständnisse an die Bedienbarkeit gemacht werden müssen, wobei dies in meinen Augen im Wesentlichen nur die Abstraktion zwischen dem DOM und seinen sprachspezifischen Erweiterungen betrifft. Nichtsdestoweniger würde ich vorschlagen, unabhängig von der Gliederung der Portalseite eine eigene Seite einzurichten, auf welcher alle Schnittstellen und ihre Eigenschaften und Methoden einmal komplett aufgelistet sind, also gewissermaßen für den Schnellzugriff, wobei auch auf dieser site map natürlich durch Überschriften und Absätze die jeweiligen inhaltlichen Zugehörikeiten kenntlich gemacht werden sollten.

                Unabhängig davon ob eine solche Seite eingerichtet wird oder nicht, wird sich in Zukunft aber auch irgendwann die Frage stellen, welche APIs auf der Portalseite direkt verlinkt werden sollten, egal ob nun ECMAScript-eigene oder durch den Browser bereitgestellte, denn es ist klar, dass die bislang aufgeführten Schnittstellen nur sehr unvollständig sind, und sofern sich dies in Zukunft einmal ändert, eine tatsächlich vollständige Auflistung auf der Portalseite für deren Bedienbarkeit nicht gerade zuträglich wäre.

                Grundsätzlich fände ich die folgende (immernoch unvollständige) Einteilung jedenfalls nicht schlecht:


                [Linke Spalte]

                [Die Artikel lasse ich hier mal weg]

                Standard APIs [JavaScript/Standard_APIs]

                • Array
                • ArrayBuffer
                • Boolean
                • DataView
                • Date
                • Function
                • Generator
                • Map
                • Math
                • Number
                • Object
                • Promise
                • Reflect
                • RegExp
                • String
                • Symbol
                • TypedArray

                [Rechte Spalte]

                Browser APIs [JavaScript/Browser_APIs]

                • DOM [JavaScript/Browser_APIs/DOM]
                  • Document
                  • Element
                  • Event
                  • EventTarget
                  • Node
                  • Range
                  • Selection

                |Leerzeile|

                • Window
                • Screen
                • Navigator
                • History
                • Location

                |Leerzeile|

                • Canvas 2D
                • Console
                • Drag & Drop
                • File Upload
                • Geolocation (usw.)

                Wenn das irgendwann mal too much wird, werden halt bestimmte Punkte erst sichtbar, wenn man die jeweiligen Seiten [JavaScript/Standard_APIs] oder [JavaScript/Browser_APIs] öffnet.

                Bezogen auf den Fall Window bin ich, wie ich schon in meinem ersten Beitrag sagte, der Ansicht, dass bei den Artikeln zu den Eigenschaften immer genau geprüft werden sollte, ob es sich hier wirklich um eigene Eigenschaften handelt oder um solche, über die window nur aufgrund seiner Rolle als globales Objekt verfügt, so dass die Artikel für Letztere dann im Zweifel an anderer Stelle besser untergebracht wären und sie bei Window nur verlinkt werden sollten.

                Wie dem auch sei, ob die Gliederung wie ich sie hier ins Spiel gebracht habe der Weisheit letzter Schluss ist kann ich nicht sagen, aber ich denke im Vergleich mit der bisherigen Aufteilung wäre es formal betrachtet korrekter, ohne dass dabei die Übersichtlichkeit und damit die Bedienbarkeit der Seite in Mitleidenschaft gezogen würde…


                Naja, jedenfalls fände ich es schön, wenn sich hierzu auch nochmal ein paar andere äußern und eigene Vorschläge einbringen würden. – Oder wenigstens ihre Zustimmung zu diesen Vorschlägen signalisieren würden. ;-)

                Viele Grüße,

                Orlok

                --
                „Das Wesentliche einer Kerze ist nicht das Wachs, das seine Spuren hinterlässt, sondern das Licht.“ Antoine de Saint-Exupéry
                1. Tach!

                  Grundsätzlich fände ich die folgende (immernoch unvollständige) Einteilung jedenfalls nicht schlecht:


                  [Linke Spalte]

                  [Die Artikel lasse ich hier mal weg]

                  Standard APIs [JavaScript/Standard_APIs]

                  • Array
                  • ArrayBuffer
                  • Boolean
                  • DataView
                  • Date
                  • Function
                  • Generator
                  • Map
                  • Math
                  • Number
                  • Object
                  • Promise
                  • Reflect
                  • RegExp
                  • String
                  • Symbol
                  • TypedArray

                  [Rechte Spalte]

                  Browser APIs [JavaScript/Browser_APIs]

                  • DOM [JavaScript/Browser_APIs/DOM]
                    • Document
                    • Element
                    • Event
                    • EventTarget
                    • Node
                    • Range
                    • Selection

                  |Leerzeile|

                  • Window
                  • Screen
                  • Navigator
                  • History
                  • Location

                  |Leerzeile|

                  • Canvas 2D
                  • Console
                  • Drag & Drop
                  • File Upload
                  • Geolocation (usw.)

                  Dagegen hab ich keinen Einwand vorzubringen. Das entspricht der Aufteilung, wie ich sie mir vorstelle, wenn ich etwas zu suchen gedenke.

                  dedlfix.

                2. Servus!

                  Hallo Matthias

                  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. ;-)

                  Sorry, das ich 32h für eine Antwort gebraucht habe. Ich habe eine Familie mit Frau und Kind und bin nebenbei berufstätig, wo ich manchmal auch was machen muss. :-(

                  Das Wiki ist eben nicht so sexy wie Anfänger-Bashing oder Menschelei-Thread-Drift im Hauptforum, das muss jedem klar sein, der sich im Wiki engagiert.

                  Grundsätzlich fände ich die folgende (immernoch unvollständige) Einteilung jedenfalls nicht schlecht: [Rechte Spalte]

                  Browser APIs [JavaScript/Browser_APIs]

                  • DOM [JavaScript/Browser_APIs/DOM]
                    • Document
                    • Element
                    • Event

                  Willst du wirklich

                  • JavaScript/Event

                  in

                  • JavaScript/Browser_APIs/DOM/Event

                  einsortieren?

                  In meiner Antwort habe ich schon auf die Pfade und ihre Problematik aufmerksam gemacht.

                  Ich würde lieber die von Dir vorgestellte Aufteilung in Übersichtsseiten wie [[JavaScript/API]] (wie auch immer die dann heißen mag) präsentieren und erklären, aber nicht in die Hierarchien der Seiten übernehmen.

                  Bei den Grundlegenden Konzepten JavaScript/Konzepte befinden sich die Unterseiten auch in der gleichen Ebene:

                  Herzliche Grüße

                  Matthias Scharwies

                  1. Hallo Matthias

                    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. ;-)

                    Sorry, das ich 32h für eine Antwort gebraucht habe. Ich habe eine Familie mit Frau und Kind und bin nebenbei berufstätig, wo ich manchmal auch was machen muss. :-(

                    Oha, ich schätze da bin ich völlig falsch rübergekommen! Erstens sollte der Smiley am Ende eigentlich signalisieren, dass ich nicht wirklich vorhatte die beleidigte Leberwurst zu spielen, und zweitens, selbst wenn ich hier tatsächlich ‚ein klein wenig enttäuscht‘ gewesen sein sollte, dann wärst du mit Sicherheit der Allerletzte, der sich hierbei hätte angesprochen fühlen müssen!

                    Im Gegenteil wollte ich mit dem von dir zitierten ersten Absatz meines Beitrages eigentlich nur deutlich machen, wie sehr ich mich darüber gefreut habe, dass du dich hier eingebracht hast, weil ich dadurch das Gefühl bekommen habe, dass mein Engagement in der Sache doch nicht vollkommen umsonst gewesen ist. :-)

                    Das Wiki ist eben nicht so sexy wie Anfänger-Bashing oder Menschelei-Thread-Drift im Hauptforum, das muss jedem klar sein, der sich im Wiki engagiert.

                    Tja, ich schätze da hast du wohl recht. Ein paar zotige Kommentare im Hauptforum hätten meinem Punktestand vermutlich besser getan als die ellenlangen Beiträge hier im Thread. Aber darum geht es mir ja nicht. :-D

                    In meiner Antwort habe ich schon auf die Pfade und ihre Problematik aufmerksam gemacht.

                    Hmmh. Also mal rein theroretisch betrachtet gibt es ja nur zwei sinnvolle Lösungen, nämlich entweder schmeißt man alles im Namensraum [JavaScript] zusammen, wobei dann natürlich bei manchen Artikeln die Namen entsprechend angepasst werden müssen, da sonst das „globale Variablen“-Problem entsteht, wie etwa bei den verschiedenen Varianten von valueOf, oder man legt die Pfade so an, dass sie die gewünschte Struktur repräsentieren. Wobei es dann aber vermutlich auch gut wäre, wenn man sich konsequent für eine Vorgehensweise entscheidet.

                    Bei den Grundlegenden Konzepten JavaScript/Konzepte befinden sich die Unterseiten auch in der gleichen Ebene:

                    Eigentlich denke ich, dass diese Artikel unter JavaScript/Grundlegende_Konzepte/ abgelegt werden sollten und auch eine entsprechende Seite beim Klick auf die Überschrift erscheinen sollte. Das fände ich, unter der Voraussetzung, dass wir uns grundsätzlich dafür entscheiden, dass die Pfade die Struktur entsprechend repräsentieren sollen, im Prinzip besser.

                    Aber der entscheidende Punkt ist hier wohl: Wer macht's?

                    Und ich verstehe sehr gut deine Besorgnis, dass die damit verbundene Arbeit letztlich wieder an dir hängen bleiben würde! ;-)

                    Insofern ist das hier von mir natürlich nur leeres Geschwätz. Ich kann dir sagen, dass ich etwa [JavaScript/Browser_APIs/DOM/Event] tatsächlich gut fände, da auf diese Weise schon in der Navigationszeile die Struktur deutlich wird. Aber selbst wenn wir hierüber zu einem Konsens kämen, was würde das schon bedeuten?

                    Wenn wir uns grundsätzlich entscheiden (oder entschieden haben), die Hierarchien entsprechend darzustellen, dann sollten wir das auch versuchen so umzusetzen, aber es sollte eben auch klar sein, dass damit Arbeit verbunden ist. Ich habe also absolut kein Problem damit, wenn etwa [JavaScript/DOM] erstmal so bleibt wie es ist. Oder irgendetwas anderes. Denn wenn ich will, dass sich das ändert liegt es an mir dafür zu sorgen dass dies auch passiert. ;-)

                    Viele Grüße,

                    Orlok

                    --
                    „Das Wesentliche einer Kerze ist nicht das Wachs, das seine Spuren hinterlässt, sondern das Licht.“ Antoine de Saint-Exupéry
                    1. Hallo Orlok,

                      Vielen Dank für deine Mühe, deinen Elan, deinen Fleiß.

                      Leider habe ich zuwenig Ahnung von JavaScript, als dass ich jetzt für oder gegen die vorgeschlagene Struktur ins Feld ziehen könnte. Meine Intension wäre: Möglichst flache Strukturen. Da aber dedlfix deinen Vorschlag befürwortet, kann es meinetwegen auch so umgesetzt werden. Und wenn keiner mit AHnung sich dagegen ausspricht, würde ich beim Verschieben auch helfen.

                      Bis demnächst
                      Matthias

                      --
                      Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)
                3. 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:[
                  1. Hallo Camping_RIDER

                    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 ;)

                    Wie schon an anderer Stelle gesagt: Kein Problem.

                    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.

                    Ich versuche mich kürzer zu fassen.

                    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.

                    Ok.

                    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 habe ich an keiner Stelle behauptet. Allgemein gefasste Artikel wie Tutorials oder solche zum Thema Anwendung und Praxis beziehen natürlich Aspekte aus den verschiedensten Teilbereichen mit ein. Das ist so und sollte sich auch nicht ändern.

                    JavaScript mag aus diesen Bestandteilen bestehen, daraus lässt sich aber keine Notwendigkeit ableiten, die Bestandteile einzeln zu behandeln.

                    Wieso entweder oder? Die Bestandteile sollten einerseits einzeln behandelt, andererseits aber natürlich auch in allgemeineren Artikeln im Gesamtkontext dargestellt werden. Wo ist da der Widerspruch?

                    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

                    „zelebriert“ – lol

                    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. […] 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.

                    Also um noch mal kurz zum Vergleich meinen Vorschlag einzufügen:


                    [Linke Spalte]

                    [Die Artikel lasse ich hier mal weg]

                    Standard APIs [JavaScript/Standard_APIs]

                    • Array
                    • ArrayBuffer
                    • Boolean
                    • DataView
                    • Date
                    • Function
                    • Generator
                    • Map
                    • Math
                    • Number
                    • Object
                    • Promise
                    • Reflect
                    • RegExp
                    • String
                    • Symbol
                    • TypedArray

                    [Rechte Spalte]

                    Browser APIs [JavaScript/Browser_APIs]

                    • DOM [JavaScript/Browser_APIs/DOM]
                      • Document
                      • Element
                      • Event
                      • EventTarget
                      • Node
                      • Range
                      • Selection

                    |Leerzeile|

                    • Window
                    • Screen
                    • Navigator
                    • History
                    • Location

                    |Leerzeile|

                    • Canvas 2D
                    • Console
                    • Drag & Drop
                    • File Upload
                    • Geolocation (usw.)

                    Dadurch findest du wird die „Zugänglichkeit zum Verständnis des Gesamtbildes verkompliziert“?

                    Ich nehmen an, du hättest es also lieber nach dem Schema:

                    Objekte

                    • Array
                    • ArrayBuffer
                    • Attr
                    • Boolean
                    • Canvas 2D
                    • Console
                    • Document
                    • Event
                    • Element
                    • File Upload
                    • Forms
                    • Function
                    • Geolocation
                    • History
                    • IndexedDB
                    • Location
                    • Map
                    • Math
                    • Navigator
                    • Node
                    • Number
                    • Promise
                    • Range
                    • RegExp
                    • Screen
                    • Selection
                    • String
                    • TypedArray
                    • WebGL
                    • XMLHttpRequest

                    Ich würde meinen, hier geht die Übersicht flöten. Aber das kann man natürlich so machen. Allerdings ist es meiner Erfahrung nach aus Sicht des Lernenden absolut von Vorteil, wenn innerhalb eines komplexen Systems Strukturen erkennbar werden, will sagen, um ehrlich zu sein widerspricht dein Ansatz vollkommen dem, was mir selbst stets als am nutzbringendsten erschien beim Wissenserwerb.

                    Wahrscheinlich ist die Welt nicht so schwarz-weiß wie du oder ich das hier darstellen, aber sollte dein Ansatz wirklich die Mehrheitsmeinung hier darstellen und in letzter Konsequenz umgesetzt werden, dann heißt das für mich ganz klar, dass ich das Konzept nicht mittragen kann, will und werde. Und das ist nur eine nüchterne Feststellung, nichts weiter.

                    Gruß,

                    Orlok

                    --
                    „Das Wesentliche einer Kerze ist nicht das Wachs, das seine Spuren hinterlässt, sondern das Licht.“ Antoine de Saint-Exupéry
                    1. Aloha ;)

                      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.

                      Ich versuche mich kürzer zu fassen.

                      Sehr gut, der Effekt ist spürbar ;) Tut mir leid, dass ich dafür jetzt so viel in die Tasten haue.

                      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.

                      Ok.

                      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 habe ich an keiner Stelle behauptet. Allgemein gefasste Artikel wie Tutorials oder solche zum Thema Anwendung und Praxis beziehen natürlich Aspekte aus den verschiedensten Teilbereichen mit ein. Das ist so und sollte sich auch nicht ändern.

                      Okay, dann ist der Extremfall, den meine Kritik unter anderem beschreibt, vom Tisch.

                      JavaScript mag aus diesen Bestandteilen bestehen, daraus lässt sich aber keine Notwendigkeit ableiten, die Bestandteile einzeln zu behandeln.

                      Wieso entweder oder? Die Bestandteile sollten einerseits einzeln behandelt, andererseits aber natürlich auch in allgemeineren Artikeln im Gesamtkontext dargestellt werden. Wo ist da der Widerspruch?

                      Darin steckt kein Widerspruch. Die Frage ist nur, nach welchem Leitbild (Einzelteile vs. Gesamtkonzept) sich die Struktur richten sollte (was aber auch von weiteren Faktoren abhängt). Dass der Inhalt der Artikel nicht nur differenzieren darf, sondern sogar sollte, hatte ich ja durchaus auch geschrieben.

                      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.

                      Also um noch mal kurz zum Vergleich meinen Vorschlag einzufügen:

                      Ich springe schon hier, vor dem Vorschlag, ein. Ich möchte noch einmal betonen, dass mein vehementer Widerspruch sich vor allem gegen das von dir formulierte Grundprinzip "strikte Trennung zwischen ECMAScript und APIs" richtet - sinngemäß und Hervorhebung von mir.

                      Strikte Trennung zu fordern (Stichwort unabdingbar) ist nämlich das, was ich an anderer Stelle mit dem Wort "zelebrieren" bedacht habe.

                      Wenn es darum geht, den Unterschied zwischen ECMAScript und APIs zu thematisieren, egal in welcher Form, wäre ich grundsätzlich schon bei dir.

                      Eine strikte Trennung, auch in der Struktur, ist aber nur dann sinnvoll, wenn die Dinge auch getrennt gehören. Also, strikte Trennung wie in "strikte Trennung zwischen Inhalt und Darstellung" oder so. Im Fall JavaScript ist es aber doch so, dass ECMAScript und APIs nur zwei Teile eines Ganzen sind, die nur in ihrer Gesamtheit die Bezeichnung JavaScript rechtfertigen.

                      Man kann in so einem Fall vielleicht Unterschiede herausarbeiten oder die Herkunft einzelner Eigenschaften/Methoden klarmachen, aber sicher keine strikte Trennung begründen.

                      Darauf vor Allem war mein vehementer Protest bezogen, vielleicht habe ich mich auch zu stark an dieser einen Aussage (die ich so einfach nicht stehen lassen konnte/kann) aufgehängt. Sollte ich deine Aussage hier in ihrer Schärfe (strictness :P) überbewertet haben, tut es mir leid.

                      Eine Anpassung der Struktur dahingehend, dass sie Elemente zugunsten der Übersichtlichkeit gruppiert (auch anhand der Spec, in der die jeweiligen Elemente definiert sind) ist nicht per se schlecht; das muss konkret beleuchtet werden (was ich bisher nicht getan habe).


                      Nun konkret zu deinem Vorschlag, zu dem ich mich bisher nicht geäußert hatte.

                      [...Vorschlag...] Dadurch findest du wird die „Zugänglichkeit zum Verständnis des Gesamtbildes verkompliziert“?

                      Ja, in gewisser Weise, siehe unten.

                      Ich nehmen an, du hättest es also lieber nach dem Schema:

                      Objekte

                      [...alles in einem Topf...]

                      Nein.

                      Ich würde meinen, hier geht die Übersicht flöten.

                      Richtig.

                      Wir müssen nicht darüber diskutieren, dass die Vielzahl von Objekten strukturiert werden sollte, nein, muss. Wir müssen auch nicht darüber diskutieren, dass deine Anordnung der Objekte fachlich sinnvoll ist.

                      Wir müssen aber darüber diskutieren, wie weit die Strukturänderung gehen muss und ob diese Strukturänderung auch didaktisch sinnvoll ist. Für die Portalseite halte ich eine Struktur, wie du sie vorschlägst für prinzipiell denkbar. Hier wird man sonst, wie du richtig sagst, von der Vielzahl unstrukturierter Objekte überrannt. Ich bin prinzipiell also durchaus bei dir - allerdings nicht weil ich denke, dass das aus Prinzip getrennt werden muss (so hatte ich dich verstanden), sondern weil ich überzeugt bin, dass man sonst von der Fülle der Einträge unnötig überwältigt wird und die Trennung nach ECMAScript und APIs eine sinnvolle Möglichkeit (von mehreren) ist, wenn man denn trennen muss.

                      Jetzt dazu, warum ich die Trennung wie du sie vorschlägst für potenziell unzugänglich halte.

                      Sobald wir uns auch nur einen Millimeter von den unterschiedlichen Specs weg und zur tatsächlichen Praxis hinbewegen, wird die Verflechtung vom JavaScript-Sprachkern mit dem DOM sehr stark. window entspricht in der Praxis de facto dem globalen Objekt und die Objekte der APIs befinden sich damit auf Augenhöhe mit den Objekten des Sprachkerns.

                      Ich hatte vorher, was vielleicht untergegangen ist, die Frage in den Raum gestellt, welcher praktische Unterschied zwischen ECMAScript-Objekten wie String und DOM-Objekten wie document besteht. Und die Antwort ist mMn: eigentlich keiner. Natürlich gibt es viele Unterschiede in Funktionalität , Ursprung, Benutzbarkeit außerhalb des Browsers, aber im Browser sind es im Prinzip einfach nur zwei unterschiedliche Objekte im globalen Raum.

                      Da also die Frage, aus welchem Spezifikationssatz ein Objekt stammt, nicht weiter relevant zu sein scheint ist doch die Frage, warum wir unsere Struktur daran ausrichten sollen - und nicht an anderen Kriterien, die vielleicht näher am Endanwender sind, der sich nicht zwangsläufig für die Spezifikationshierarchie interessiert (und das, mangels praktischer Relevanz, eigentlich auch nicht muss).

                      Einfaches Beispiel zur Illustration: JavaScript/Browser_APIs/DOM/Event ist für mich nicht besonders zugänglich oder intuitiv - das ist schon sehr tief in der Hierarchie für ein Element von JavaScript, das in der Praxis eine sehr große Bedeutung hat. Ich gehe soweit mit, dass JavaScript/Event (die aktuelle Lösung) auch nicht optimal ist. Für intuitiv würde ich hier halten: JavaScript/DOM/Event. Die Zuordnung von Event zu DOM ist sinnvoll, aber die Information, dass DOM streng genommen eine API ist, ist weder intuitiv noch Endbenutzer-relevant.

                      Aus dem selben Grund würde ich die Drag & Drop-API intuitiv wohl eher unter JavaScript/Drag & Drop einordnen, als unter (wie im Moment) JavaScript/API/Drag & Drop. Auch hier halte ich die Information, dass es sich um eine API handelt, für irrelevant.

                      Tatsächlich würde ich auch all die Objekte, die du unter Standard_APIs zusammengefasst hast, so zusammenfassen - allerdings aus anderen Gründen. Mir geht es nicht darum, wo die Objekte definiert sind, sondern was sie tun - und diese Objekte erfüllen einen ganz bestimmten Zweck, sie stellen elementare Funktionalitäten bereit. Ich würde sie deshalb aber nicht Standard_APIs nennen, sondern, nach ihrer Funktion, ganz banal "Sprachkern", oder "Kernobjekte" oder "primitive Objekte" (wegen mir auch "Standardobjekte") - darunter kann man sich als Endanwender dann auch deutlich mehr praktisch vorstellen.

                      Vielleicht an dieser Stelle nochmal, weil meine Kritik jetzt vielleicht etwas klarer wird: Ich kritisiere nicht die Idee, eine (Um-)Strukturierung vorzunehmen, sondern ich kritisiere, dass sich eine Strukturierung nach Spec sehr viel weniger eignet als eine Strukturierung, die sich tatsächlich am Bedürfnis des Endanwenders orientiert.

                      Umrissen könnte ich mir einen ähnlichen Vorschlag wie deinen vorstellen, allerdings von anderen Motiven geleitet:


                      Primitive Objekte

                      • Array
                      • ArrayBuffer
                      • Boolean
                      • DataView
                      • Date
                      • Function
                      • Generator
                      • Map
                      • Math
                      • Number
                      • Object
                      • Promise
                      • Reflect
                      • RegExp
                      • String
                      • Symbol
                      • TypedArray

                      DOM

                      • Document
                      • Element
                      • Event
                      • EventTarget
                      • Node
                      • Range
                      • Selection

                      Browser-Objekte

                      • Window
                      • Screen
                      • Navigator
                      • History
                      • Location

                      Schnittstellen

                      • Canvas 2D
                      • Console
                      • Drag & Drop
                      • File Upload
                      • Geolocation (usw.)

                      Wie gesagt, nur mal ins Blaue geschossen, mit eher Funktions-orientierter Sortierung bzw. Bezeichnung, orientiert an dem Endanwender, der die Portalseite nachher besucht.

                      Und auch da ist dann die Frage: Reicht es nicht vielleicht sogar, die Übersichtsseite so zu strukturieren und die URLs ganz simpel, flach zu machen, also tatsächlich alles mit

                      Javascript/...
                      ...Array
                      ...document
                      ...event
                      ...Navigator
                      ...Drag & Drop
                      ...usw-usf.

                      Denn während mir für die Portalseite einleuchtet, dass eine Nutzerführung und Ordnung der Objekte sinnvoll ist, so muss das nicht unbedingt auch für die tatsächliche Strukturierung gelten. Hier greift das Argument der Übersichtlichkeit mMn nicht mehr - und damit gewinnt für mich im Fall der URLs/Seitentitel die Sichtweise "Event ist genauso ein Sprachelement von JavaScript wie Array" die Oberhand, aber wie gesagt, nur weil mir da kein Grund einfällt, der für die Änderung der Seitentitel spricht, heißt nicht, dass es keinen gibt...

                      In meinen Augen stellt eine rein optische, nach Sichtweise der Funktionalität geordnete Struktur der Links auf der Portalseite gepaart mit konsequent flacher Hierarchie einen Zustand dar, der alle Bedürfnisse befriedigen sollte - außer dem nach einer Widerspiegelung der Trennung zwischen ECMAScript und APIs, welches aber mMn so gut wie nichts mit Gründen aus der Praxis zu tun hat.

                      [...] sollte dein Ansatz wirklich die Mehrheitsmeinung hier darstellen [...]

                      Mein Ansatz und meine Meinung sind gewöhnlich nicht deckungsgleich mit der Mehrheitsmeinung und zudem grundsätzlich offen für Diskussionen.

                      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:[
                      1. Tach!

                        Primitive Objekte

                        Das sind aus Javascript-Sicht nur String, Boolean und Number und auch nur diese drei nennt man so. Ansonsten lohnt es sich nicht, für diese drei eine Trennung vorzunehmen. Das würde sie nur zu sehr prominent hinstellen. In der Praxis macht man meist und aus gutem Grund einen großen Bogen darum und verwendet stattdessen ihre Pendants die primitiven Typen.

                        Du meinst vermutlich nicht primitiv sondern sowas wie "allgemein". Und damit gehören sie mehr zum Kern der Sprache, weil sie neben den Kontrollstrukturen einigermaßen essentiell sind. Ohne sie kann man keine Javascript-Programme erstellen, ohne die anderen APIs aber schon. Da wir uns aber vorwiegend um im Browser ablaufendes Javascript und weniger um serverseitiges kümmern werden, würde ich neben diesen allgemeinen auch noch die anderen allgemeinen browserspezifischen Objekte zumindest in ihrer unmittelbaren Nähe aufführen. Etwas abseits davon kämen die themenorientierten APIs an die Reihe.

                        Man kann ja mal einen Abstecher ins PHP-Manual werfen. Auch da gibts die allgemeinen Sprachelemente (Language Reference) und mehr oder weniger themenspezifisch die Function Reference. Der Anfänger mag da noch keine große Unterscheidung treffen, aber als Fortgeschrittener wird man diese schätzen. Ein Anfänger braucht immer Einarbeitungszeit, aber eine solche Aufteilung wird ihn jetzt nicht grundsätzlich behindern.

                        Ich bitte darum, den Vergleich mit dem PHP-Handbuch nicht zu detailreich zu betrachten, denn da gibt die Sprache und deren Historie ganz andere Bedingungen vor, als sie Javascript hat. Zum Beispiel hängen die Stringfunktionen als Methoden am String-Objekt und werden mit ihm zusammen beschrieben, bei PHP sind es separate Funktionen und stehen extra.

                        Wie gesagt, nur mal ins Blaue geschossen, mit eher Funktions-orientierter Sortierung bzw. Bezeichnung, orientiert an dem Endanwender, der die Portalseite nachher besucht.

                        Es wäre auch schön, nicht nur die Anfänger anzusprechen, sondern auch den Fortgeschrittenen noch einen Grund zu bieten, nicht gleich zum MDN zu verschwinden. Insofern sollten wir nicht nur eine homogene Masse sondern unterschiedliche Bedürfnisse berücksichtigen und da einen guten Kompromiss finden.

                        Und auch da ist dann die Frage: Reicht es nicht vielleicht sogar, die Übersichtsseite so zu strukturieren und die URLs ganz simpel, flach zu machen, also tatsächlich alles mit [...] Denn während mir für die Portalseite einleuchtet, dass eine Nutzerführung und Ordnung der Objekte sinnvoll ist, so muss das nicht unbedingt auch für die tatsächliche Strukturierung gelten.

                        Vielleicht nicht ganz flach, denn davon hängt auch die Brotkrümelnavigation ab, bei der es durchaus bei einigen Themen sinnvoll ist, nicht nur generell zu "Javascript" zurückspringen zu können. Zu lang sollte die URL und damit die Navigation aber auch nicht werden. Insofern ist sicherlich der URL-Bestandteil Browser-API verzichtbar, DOM aber eher nicht.

                        dedlfix.

                        1. Aloha ;)

                          Du meinst vermutlich nicht primitiv sondern sowas wie "allgemein". Und damit gehören sie mehr zum Kern der Sprache, weil sie neben den Kontrollstrukturen einigermaßen essentiell sind. Ohne sie kann man keine Javascript-Programme erstellen, ohne die anderen APIs aber schon.

                          Genau das, mir fehlt nur der passende/griffige Bezeichner dafür, deshalb habe ich zu "primitive Objekte" gegriffen, finde aber z.B. "Kernobjekte" oder "Sprachkern" auch gut/besser - oder gerne auch einen anderen Begriff, der die Aussage griffig rüberbringt :)

                          Da wir uns aber vorwiegend um im Browser ablaufendes Javascript und weniger um serverseitiges kümmern werden, würde ich neben diesen allgemeinen auch noch die anderen allgemeinen browserspezifischen Objekte zumindest in ihrer unmittelbaren Nähe aufführen. Etwas abseits davon kämen die themenorientierten APIs an die Reihe.

                          Ja, halte ich für sinnvoll.

                          Man kann ja mal einen Abstecher ins PHP-Manual werfen. Auch da gibts die allgemeinen Sprachelemente (Language Reference) und mehr oder weniger themenspezifisch die Function Reference. Der Anfänger mag da noch keine große Unterscheidung treffen, aber als Fortgeschrittener wird man diese schätzen.

                          Das war ungefähr das, was ich meinte mit

                          Wir müssen nicht darüber diskutieren, dass die Vielzahl von Objekten strukturiert werden sollte, nein, muss.

                          Es wäre auch schön, nicht nur die Anfänger anzusprechen, sondern auch den Fortgeschrittenen noch einen Grund zu bieten, nicht gleich zum MDN zu verschwinden. Insofern sollten wir nicht nur eine homogene Masse sondern unterschiedliche Bedürfnisse berücksichtigen und da einen guten Kompromiss finden.

                          Selbstverständlich. Ich habe absichtlich nicht von "Anfänger" sondern von "Endanwender" gesprochen - auch wenn sich das vielleicht in meinem Vorschlag eher wie "Anfänger" angehört hat. Natürlich sollten wir beide ins Boot holen.

                          Allerdings ist die Unterscheidung zwischen ECMAScript und APIs mMn auch für einen Fortgeschrittenen nicht von großer Bedeutung, da darf man aber gerne auch anderer Meinung sein ;)

                          AFAIS ist der einzige Punkt, an dem man als Anwender diese Unterscheidung benötigt der, an dem man selbst was in einer Spec nachschlagen möchte. Und das betrifft dann, so wie ich das sehe, wirklich erst die Profis; die profitieren dann aber gar nicht mehr von einer Abbildung der Spec-Realität in der Struktur, weil sie im Zweifelsfall ja dann doch eher nicht bei uns ins Wiki schauen. Deshalb: Spec-Zuordnung in den Inhalt des Artikels, gerne auch gut sichtbar, sodass man im Zweifelsfall auch herausfindet in welcher Spec man nachschauen muss, aber nicht überrepräsentieren und die Struktur da unbedingt reinpressen.

                          Vielleicht nicht ganz flach, denn davon hängt auch die Brotkrümelnavigation ab, bei der es durchaus bei einigen Themen sinnvoll ist, nicht nur generell zu "Javascript" zurückspringen zu können. Zu lang sollte die URL und damit die Navigation aber auch nicht werden. Insofern ist sicherlich der URL-Bestandteil Browser-API verzichtbar, DOM aber eher nicht.

                          FACK. Der "ganz flache" Gegenvorschlag war auch nur das andere Extrem, ein wohl durchdachter Mittelweg wäre wünschenswert.

                          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:[
                          1. Hallo Camping_RIDER

                            Nachdem dedlfix ja nun schon einige Punkte angesprochen hat, die ich ebenfalls hätte ansprechen wollen, kann ich mich an dieser Stelle zumindest etwas kürzer fassen, obwohl ich die Befürchtung habe, dass dieser Beitrag doch wieder ein wenig länger wird. Sorry dafür. ;-)

                            Jedenfalls bin ich beim Lesen deines Beitrags zu dem Schluss gekommen, dass wir vermutlich wirklich nicht soweit auseinanderliegen wie wir beide wohl gedacht haben und dass die Unterschiede, was unsere Einschätzungen angeht, eigentlich nicht so sehr grundsätzlicher Natur sind, sondern sie eher die Beurteilung von Details betreffen.

                            Es war zweifellos unglücklich formuliert, als ich von „unabdingbarer strikter Trennung“ schrieb, ohne dies aber zu begründen. Zwar hattest du nicht vollkommen unrecht getan mir zu unterstellen, dass ich diese Trennung aus der unterschiedlichen Spezifikation der Objekte herleite, aber die Annahme, dies wäre mein einziges Motiv, war unzutreffend, denn mindestens von gleichem Gewicht war für mich die Begründung, die du selbst angeführt hast, als du die standard built-ins in deinem eigenen Vorschlag zusammen aufgelistet hast, Stichwort „elementare Funktionalität“.

                            Freilich kann diese Begründung nicht in jedem Einzelfall als geeignetes Abgrenzungskriterium dienen, da je nach Anwendungsfall auch durch nicht in ECMAScript spezifizierte APIs eine grundlegende Funktionalität bereitgestellt wird, wie etwa durch die Schnittstelle Event, aber bezogen auf eine grobe Einteilung hat dieses Argument dennoch einiges Gewicht.

                            Ebenfalls zu berücksichtigen ist natürlich die Frage der Gebundenheit an eine Ausführungsumgebung, was zwar wie du richtig sagst meistens keine Rolle spielt, meiner Ansicht nach aber dennoch nicht komplett von der Hand zu weisen ist, so dass dies zumindest zu einem kleinen Teil ebenfalls meine Beurteilung beeinflusst hat.

                            Schließlich kommt noch eine in gewissem Sinne tautologische Begründung hinzu, nämlich der Umstand, dass das Wiki nicht die einzige Quelle von Informationen zum Thema ist und die meisten anderen Portale vermutlich aus den oben genannten Gründen ebenfalls danach verfahren, die standard built-ins separat zu behandeln. Es hat also wie ich meine durchaus eine gewisse Relevanz, dass ein nicht geringer Teil der potentiellen Besucher des Wikis auch eine dahingehende Erwartungshaltung mitbringen dürfte.

                            In der Summe bedarf es nach meinem Dafürhalten also schon einiger sehr gewichtiger Gründe, um eine diesbezügliche Trennung nicht vorzunehmen, und ich bin einfach stillschweigend davon ausgegangen, dass bei entsprechender Würdigung aller Umstände niemand solche Gründe würde vorbringen können, weshalb ich mir in diesem Punkt weitere Erklärungen erspart hatte. Also ganz im Sinne deines Ratschlags, ich müsse in meinen Beiträgen zwecks besserer Lesbarkeit ja nicht jedes Detail mit einbeziehen. :-P

                            Ich denke wir kommen also soweit überein, dass es erstens aus Gründen der Zugänglichkeit notwendig ist, dass die diversen built-in objects überhaupt in irgendeiner Form strukturiert dargestellt werden, und dass es zweitens aus verschiedenen Gründen sinnvoll ist, diejenigen Objekte, welche zum ‚Kern der Sprache‘ gehören, auch in einer gemeinsamen Rubrik aufzuführen.

                            Darüber hinaus glaube ich sind wir uns ebenfalls in dem Punkt einig, dass die Artikel selbst der am besten geeignete Ort sind, den Gesamtkontext sowie die Hintergründe und die Zusammenhänge entsprechend kenntlich zu machen, so dass wir hierüber an dieser Stelle auch nicht weiter diskutieren brauchen.

                            Nachdem ich nun also bereitwillig die Hauptverantwortung dafür auf meine Schultern nehme, dass wir hier im Wesentlichen aneinander vorbei geredet haben, möchte ich aber doch noch einmal zu bedenken geben, dass du, wo du doch nach eigenem Bekunden den ganzen Thread gelesen hast, durchaus auch hättest zur Kenntnis nehmen können, dass ich bereits frühzeitig dem impliziten Vorwurf entgegengetreten bin, ich würde die Perspektive der ‚praktischen Benutzbarkeit‘ außer Acht lassen, als ich in Bezug auf die erste Antwort von dedlfix schrieb, dass ich wie er der Ansicht bin, dass es Fälle gibt, in denen eine formal gebotene strukturelle Trennung tatsächlich nicht sinnvoll ist, da eine solche in der Praxis kaum Relevanz besitzt. Daraus hätte man schon schlussfolgern können, dass ich mir bei meiner Argumentation dieses Aspektes grundsätzlich bewusst gewesen bin, und ich meine Vorschläge hier nicht bloß auf unhinterfragten formalen Prinzipien gründe. Aber wie gesagt, das ändert nichts daran, dass ich das schlecht kommuniziert habe. ;-)

                            Jedenfalls, nachdem wir im Ergebnis offenbar darin übereinstimmen, die standard built-ins in einer gemeinsamen Rubrik aufzuführen, stellt sich die Frage, wie diese Rubrik zu benennen wäre. Hier habe ich selbst in meinen verschiedenen Beiträgen in diesem Thread diverse Bezeichnungen ins Spiel gebracht, und ich muss gestehen, dass ich hier keine über jeden Zweifel erhabene Lösung präsentieren kann. Die Überschrift Standard APIs schien mir noch am passendsten, aber auch Standardobjekte, wie du es vorgeschlagen hast, dürfte dem Inhalt hinreichend gerecht werden. Also wenn dir Standardobjekte besser gefällt und niemand begründeten Einspruch erhebt, habe ich damit kein Problem.

                            Die zweite Frage, die sich in diesem Zusammenhang stellt, ist die Frage nach den URLs. Da zumindest die wichtigsten und darum potentiell am häufigsten nachgefragten Artikel dieser Rubrik ohnehin auf der Portalseite direkt aufgelistet werden, würde ich kein Problem darin sehen, wenn diese direkt im Namensraum [JavaScript] hinterlegt werden, also beispielsweise JavaScript/Array. Ich stimme dir in dieser Hinsicht auch grundsätzlich zu, dass bezogen auf die URLs eine zusätzliche Hierarchieebene nach dem Schema JavaScript/APIs/Title nicht erforderlich ist. Zwar denke ich auch, dass eine solche Ebene ansich nicht wirklich schaden würde, aber hier bin ich ambivalent und erkenne Vorteile wie Nachteile in beiden Lösungen, weshalb ich mich diesbezüglich deiner Meinung gerne anschließen will.

                            Bleibt also noch die Frage, wie mit den anderen Schnittstellen zu verfahren sei. Auch hier hatte ich im Verlauf des Threads ja mehrere Varianten ins Spiel gebracht, welche du dankbarerweise noch um eine eigene Version ergänzt hast. Ich denke, hier kommen wir soweit überein, dass sowohl das DOM, als auch die APIs Window, Screen, Location, History und Navigator, sowie die anderen Schnittstellen voneinander abgegrenzt dargestellt werden sollten, wobei man bei den „anderen APIs“ sicher, wenn nicht jetzt, dann zumindest irgendwann einmal, auch noch thematische Gemeinsamkeiten finden wird, welche eine eigene Gruppierung rechtfertigen können.

                            Allerdings finde ich die von dir gewählten Überschriften etwas missverständlich, denn man könnte hier jeweils den Umkehrschluss ziehen, dass es sich bei den Browser-Objekten oder dem DOM nicht um Schnittstellen handelt, oder beim DOM oder den Schnittstellen nicht um Browser-Objekte. ;-)

                            Auch sehe ich, obwohl ich es in meinem Eröffnungsbeitrag bei meinem ersten Vorschlag ja selbst ebenso gehandhabt habe, eigentlich keine Notwendigkeit, die jeweiligen Gruppierungen mit extra Überschriften zu versehen. Ich denke, ein oder zwei Leerzeilen sollten hier vollkommen genügen. Andererseits würde ich eine globale Überschrift begrüßen, welche allerdings wie bereits oben gesagt, nicht zwingend eine eigene Hierarchieebene begründen muss, sondern die nur zu Abgrenzung auf der Portalseite dient. Dabei bin ich auch nicht auf Browser APIs fixiert, zumal ich ja bereits in meinem ersten Beitrag die Frage aufgeworfen hatte, ob aus Anfängersicht nicht der Begriff ‚Schnittstellen‘ zugänglicher wäre.

                            Im Lichte der bisherigen Erkenntnisse würde ich also abschließend gerne nocheinmal einen neuen Vorschlag zur Gliederung der Seite vortragen:


                            [Linke Spalte]

                            [Die Artikel lasse ich hier wieder weg.]

                            Standardobjekte

                            • Array [JavaScript/Array]
                            • ArrayBuffer
                            • Boolean
                            • DataView
                            • Date
                            • Function
                            • Generator
                            • Map
                            • Math
                            • Number
                            • Object
                            • Promise
                            • Reflect
                            • RegExp
                            • String
                            • Symbol
                            • TypedArray

                            [Rechte Spalte]

                            Schnittstellen

                            • DOM [JavaScript/DOM]
                              • Document
                              • Element
                              • Event [JavaScript/DOM/Event]
                              • EventTarget
                              • Node
                              • Range
                              • Selection

                            |Ein oder zwei Leerzeilen|

                            • Window [JavaScript/Window]
                            • Screen
                            • Navigator
                            • History
                            • Location

                            |Ein oder zwei Leerzeilen|

                            • Canvas 2D [JavaScript/Canvas_2D]
                            • Console
                            • Drag & Drop
                            • File Upload
                            • Geolocation (usw.)

                            Beim DOM denke ich, dass die wichtigsten Punkte, wie hier demonstriert, bereits auf der Portalseite sichtbar sein sollten. Ansonsten halte ich die Gruppierung ohne extra Überschriften für ausreichend. Aber wenn jemand hier gute Ideen hat, wie man bestimmte Gruppierungen unmissverständlich unter einer Überschrift zusammenfassen kann, dann würde daraus sicherlich auch kein Schaden erwachsen, zumal wir uns ja wohl soweit einig sind, dass diese Überschriften ohnehin keinen eigenen Pfad bedingen müssen.

                            Jedenfalls bin ich froh, dass du dich eingebracht hast und ich hoffe, ich konnte uns mit diesem Beitrag einem Konsens ein Stück näher bringen. Und ich entschuldige mich nochmals dafür, dass wieder so ein Roman daraus geworden ist. ;-)

                            Viele Grüße,

                            Orlok

                            --
                            „Das Wesentliche einer Kerze ist nicht das Wachs, das seine Spuren hinterlässt, sondern das Licht.“ Antoine de Saint-Exupéry
                            1. Wow, es ist schwer hier mitzukommen weil ihr soviel Text mit so langen Sätzen produziert. :D Aber eine Anmerkung zur Struktur:

                              [Linke Spalte]

                              [Die Artikel lasse ich hier wieder weg.]

                              Standardobjekte

                              "Standard" finde ich hier verwirrend, als wären die anderen Objekte nicht standardisiert. Das Wort hat leider viele Bedeutungen. Sollte zumindest irgendwo erklärt werden, was das bedeutet.

                              Vielleicht "Sprachkern", "Kern-Objekte"?

                              • Array [JavaScript/Array]
                              • ArrayBuffer
                              • Boolean
                              • DataView
                              • Date
                              • Function
                              • Generator
                              • Map
                              • Math
                              • Number
                              • Object
                              • Promise
                              • Reflect
                              • RegExp
                              • String
                              • Symbol
                              • TypedArray

                              Die Liste wird leztlich noch länger werden, wenn man die wirklich alle abbilden will. Vgl https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects Oder ist das schon absichtlich eine verkürzte Liste? Dann frage ich mich, warum z.B. "Set" fehlt aber "Map" da ist.

                              [Rechte Spalte]

                              Schnittstellen

                              Kein Anfänger-verständlicher Name, aber was besseres fällt mir hier auch nicht ein.

                              |Ein oder zwei Leerzeilen|

                              • Window [JavaScript/Window]
                              • Screen
                              • Navigator
                              • History
                              • Location

                              Dieser Abschnitt kommt logisch und praktisch VOR dem DOM.

                              Streng genommen ist Window sogar das Wichtigste und zählt zu den "Standardobjekten". Schließlich nimmt es die Rolle des globalen Objektes ein, das zwar in ECMAScript keinen Namen hat, aber es ist die "Wurzel" vom ganzen Rest.

                              Deshalb stand es in der alten (hierarchischen) "Objektreferenz" von Selfhtml auch ganz am Anfang.

                              Auch sehe ich ... eigentlich keine Notwendigkeit, die jeweiligen Gruppierungen mit extra Überschriften zu versehen. Ich denke, ein oder zwei Leerzeilen sollten hier vollkommen genügen.

                              Ich finde Überschriften durchaus hilfreich.

                              Die Aufteilung in Kern, Browser und DOM trägt zum Verständnis bei. Der Rest sind feine Unterschiede bei denen eine Gruppierung / Unterteilung weniger wichtig ist.

                              1. Hallo Erik2

                                Wow, es ist schwer hier mitzukommen weil ihr soviel Text mit so langen Sätzen produziert. :D

                                Ja, zweifellos. Aber wir bemühen uns um Besserung. ;-)

                                Aber eine Anmerkung zur Struktur:

                                Standardobjekte

                                "Standard" finde ich hier verwirrend, als wären die anderen Objekte nicht standardisiert.

                                Manche sind es tatsächlich nicht. Aber ich sehe worauf du hinaus willst. :-)

                                Das Wort hat leider viele Bedeutungen. Sollte zumindest irgendwo erklärt werden, was das bedeutet.

                                Vielleicht "Sprachkern", "Kern-Objekte"?

                                Die passenden Überschriften zu finden ist hier wirklich keine einfache Aufgabe. Der Anfänger, der gar keine Ahnung hat, wird sich wahrscheinlich unter keiner Überschrift etwas vorstellen können. Für jemanden mit zumindest etwas Ahnung wird andererseits vermutlich keine halbwegs passende Überschrift eine Hürde darstellen.

                                Ob „Sprachkern“ oder „Kern-Objekte“ wirklich verständlicher sind wage ich zu bezweifeln, aber zumindest ersteres könnte ich mir als Alternative für die von Camping_RIDER vorgeschlagenen „Standardobjekte“ durchaus vorstellen.

                                Ja, die Liste wird definitiv noch länger werden. Und ja, es ist eine absichtlich verkürzte Liste. Allerdings soll dies nicht die tatsächliche Auswahl für die Portalseite darstellen, sondern das ist nur eine willkürlich zusammengewürfelte Auflistung zu Demonstrationszwecken.

                                Schnittstellen

                                Kein Anfänger-verständlicher Name, aber was besseres fällt mir hier auch nicht ein.

                                Naja, viel Anfänger-verständlicher geht es ja nun wirklich kaum. Außerdem bin ich der Ansicht, dass die Seite nicht einzig und allein nur für totale Anfänger optimiert sein muss, die auch nicht den geringsten Schimmer von irgendwas haben, wenn dies auf Kosten der Mehrheit der Nutzer geht, die über dieses komplette planlos-Stadium bereits hinaus sein dürften.

                                • Window [JavaScript/Window]
                                • Screen
                                • Navigator
                                • History
                                • Location

                                Dieser Abschnitt kommt logisch und praktisch VOR dem DOM.

                                Das ist eine gute Beobachtung. Ich würde es auch begrüßen wenn man den vor das DOM setzt. Danke für den Hinweis!

                                Streng genommen ist Window sogar das Wichtigste und zählt zu den "Standardobjekten". Schließlich nimmt es die Rolle des globalen Objektes ein, das zwar in ECMAScript keinen Namen hat, aber es ist die "Wurzel" vom ganzen Rest.

                                Schon richtig. Allerdings finde ich, dass Window als Browser-spezifisches Objekt dennoch auf der rechten Seite aufgelistet werden sollte. Aber wie du sagst, wäre es dort an erster Stelle sicherlich gut aufgehoben.

                                Auch sehe ich ... eigentlich keine Notwendigkeit, die jeweiligen Gruppierungen mit extra Überschriften zu versehen. Ich denke, ein oder zwei Leerzeilen sollten hier vollkommen genügen.

                                Ich finde Überschriften durchaus hilfreich.

                                Aber du hast auch gesehen, wie schwer es ist Überschriften zu finden, die einerseits den Inhalt adäquat beschreiben, andererseits aber nicht das Risiko in sich tragen, nicht oder nicht richtig verstanden zu werden. Ich bin eben der Ansicht, dass es besser ist keine Überschrift sondern nur eine Leerzeile zu verwenden, als eine Überschrift zu verwenden die missverständlich ist. Aber ich habe am Ende meines Postings ja auch ausdrücklich eingeräumt, dass in dem Fall, dass jemand eine passende und nicht zu Missverständnissen einladende Überschrift für eine Gruppierung vorträgt, diese gerne auch eingebaut werden kann.

                                Gruß,

                                Orlok

                                1. Aloha ;)

                                  Nachdem ich gerade den Konsens (zumindest zwischen uns beiden) verkündet habe möchte ich nur schnell auch hierzu meinen Senf loswerden.

                                  Ob „Sprachkern“ oder „Kern-Objekte“ wirklich verständlicher sind wage ich zu bezweifeln, aber zumindest ersteres könnte ich mir als Alternative für die von Camping_RIDER vorgeschlagenen „Standardobjekte“ durchaus vorstellen.

                                  Genauso wie ich. Also "Sprachkern" als Alternative zu "Standardobjekte". "Kern-Objekte" ist zu holprig. Das Problem, was ich mit "Sprachkern" habe (auch wenn ich die Argumente gegen "Standardobjekte" genauso sehe) ist, dass da die Abgrenzung zu den Sprachelementen wie Schleifen etc. zu schmal wird, weil die auch unter "Sprachkern" fallen würden. Also irgendwie beides keine optimalen Lösungen. Ich wage nochmal einen Wurf: "Allgemeine Objekte"? Oder vielleicht "Objekte im Sprachkern"?

                                  Schnittstellen

                                  Kein Anfänger-verständlicher Name, aber was besseres fällt mir hier auch nicht ein.

                                  Naja, viel Anfänger-verständlicher geht es ja nun wirklich kaum. Außerdem bin ich der Ansicht, dass die Seite nicht einzig und allein nur für totale Anfänger optimiert sein muss, die auch nicht den geringsten Schimmer von irgendwas haben, wenn dies auf Kosten der Mehrheit der Nutzer geht, die über dieses komplette planlos-Stadium bereits hinaus sein dürften.

                                  Genau, und: Die Überschrift oder das Verstehen der Überschrift ist an der Stelle nicht wirklich relevant, weil ihr keine größere Bedeutung zukommt, als dass sie die Artikel unter einem gemeinsamen Begriff fasst - es ist also gar nicht schlimm, wenn der Anfänger nicht begreift was damit gemeint ist, da er die einzelnen Schnittstellen auch verstehen kann ohne zu bemerken, dass es Schnittstellen sind und was Schnittstellen sind.

                                  • Window [JavaScript/Window]
                                  • Screen
                                  • Navigator
                                  • History
                                  • Location

                                  Dieser Abschnitt kommt logisch und praktisch VOR dem DOM.

                                  Das ist eine gute Beobachtung. Ich würde es auch begrüßen wenn man den vor das DOM setzt. Danke für den Hinweis!

                                  Ich würde mich dem auch unbedingt anschließen!

                                  Allerdings finde ich, dass Window als Browser-spezifisches Objekt dennoch auf der rechten Seite aufgelistet werden sollte. Aber wie du sagst, wäre es dort an erster Stelle sicherlich gut aufgehoben.

                                  +1

                                  Ich finde Überschriften durchaus hilfreich.

                                  Aber du hast auch gesehen, wie schwer es ist Überschriften zu finden, die einerseits den Inhalt adäquat beschreiben, andererseits aber nicht das Risiko in sich tragen, nicht oder nicht richtig verstanden zu werden. Ich bin eben der Ansicht, dass es besser ist keine Überschrift sondern nur eine Leerzeile zu verwenden, als eine Überschrift zu verwenden die missverständlich ist. Aber ich habe am Ende meines Postings ja auch ausdrücklich eingeräumt, dass in dem Fall, dass jemand eine passende und nicht zu Missverständnissen einladende Überschrift für eine Gruppierung vorträgt, diese gerne auch eingebaut werden kann.

                                  FACK, Überschriften sind zwar durchaus hilfreich, aber eben nur dann, wenn sie ihrem Wesen nach hilfreich, d.h. nicht Missverständnis-fördernd und gleichzeitig griffig, sind.

                                  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:[
                            2. Aloha ;)

                              Ich denke wir kommen also soweit überein, dass es erstens aus Gründen der Zugänglichkeit notwendig ist, dass die diversen built-in objects überhaupt in irgendeiner Form strukturiert dargestellt werden, und dass es zweitens aus verschiedenen Gründen sinnvoll ist, diejenigen Objekte, welche zum ‚Kern der Sprache‘ gehören, auch in einer gemeinsamen Rubrik aufzuführen.

                              Darüber hinaus glaube ich sind wir uns ebenfalls in dem Punkt einig, dass die Artikel selbst der am besten geeignete Ort sind, den Gesamtkontext sowie die Hintergründe und die Zusammenhänge entsprechend kenntlich zu machen, so dass wir hierüber an dieser Stelle auch nicht weiter diskutieren brauchen.

                              Vollkommen richtig.

                              Nachdem ich nun also bereitwillig die Hauptverantwortung dafür auf meine Schultern nehme, dass wir hier im Wesentlichen aneinander vorbei geredet haben, möchte ich aber doch noch einmal zu bedenken geben, dass du, wo du doch nach eigenem Bekunden den ganzen Thread gelesen hast, durchaus auch hättest zur Kenntnis nehmen können, dass ich bereits frühzeitig dem impliziten Vorwurf entgegengetreten bin, ich würde die Perspektive der ‚praktischen Benutzbarkeit‘ außer Acht lassen, als ich in Bezug auf die erste Antwort von dedlfix schrieb, dass ich wie er der Ansicht bin, dass es Fälle gibt, in denen eine formal gebotene strukturelle Trennung tatsächlich nicht sinnvoll ist, da eine solche in der Praxis kaum Relevanz besitzt. Daraus hätte man schon schlussfolgern können, dass ich mir bei meiner Argumentation dieses Aspektes grundsätzlich bewusst gewesen bin, und ich meine Vorschläge hier nicht bloß auf unhinterfragten formalen Prinzipien gründe.

                              Geschenkt ;) Du hast vollkommen Recht, ich hatte diese Aussagen deinerseits gelesen - mir war allerdings dann im endgültigen Vorschlag zu wenig der Quintessenz davon enthalten, und hielt es deshalb doch für nötig, zu widersprechen. Nichtsdestotrotz war meine ursprüngliche Kritik dann aber etwas einseitig - vielleicht unnötig einseitig. Dafür übernehme ich die Verantwortung ;)

                              Jedenfalls, nachdem wir im Ergebnis offenbar darin übereinstimmen, die standard built-ins in einer gemeinsamen Rubrik aufzuführen, stellt sich die Frage, wie diese Rubrik zu benennen wäre. Hier habe ich selbst in meinen verschiedenen Beiträgen in diesem Thread diverse Bezeichnungen ins Spiel gebracht, und ich muss gestehen, dass ich hier keine über jeden Zweifel erhabene Lösung präsentieren kann. Die Überschrift Standard APIs schien mir noch am passendsten, aber auch Standardobjekte, wie du es vorgeschlagen hast, dürfte dem Inhalt hinreichend gerecht werden. Also wenn dir Standardobjekte besser gefällt und niemand begründeten Einspruch erhebt, habe ich damit kein Problem.

                              Mein Ziel war es, den Begriff "API" an der Stelle außen vor zu lassen, weil API in diesem Fall nach mehr aussieht als damit gemeint wird - deshalb sehe ich potenzielle Verwirrungsgefahr (gerade für Anfänger, Fortgeschrittenen dürfte es wohl egal sein, ob Standardobjekte oder Standard APIs). Natürlich sind es im Endeffekt Schnittstellen, der Anfänger stellt sich aber unter dem Begriff Schnittstelle (und noch viel mehr unter dem wichtig-klingenden, englischen API :P) mit an Sicherheit grenzender Wahrscheinlichkeit eher ein umfassenderes System vor. Deshalb der Vorschlag Standardobjekte, mit dem ich sehr zufrieden wäre.

                              Ich stimme dir in dieser Hinsicht auch grundsätzlich zu, dass bezogen auf die URLs eine zusätzliche Hierarchieebene nach dem Schema JavaScript/APIs/Title nicht erforderlich ist. Zwar denke ich auch, dass eine solche Ebene ansich nicht wirklich schaden würde, aber hier bin ich ambivalent und erkenne Vorteile wie Nachteile in beiden Lösungen, weshalb ich mich diesbezüglich deiner Meinung gerne anschließen will.

                              Sehr schön, das war mit meine Hauptsorge.

                              Allerdings finde ich die von dir gewählten Überschriften etwas missverständlich, denn man könnte hier jeweils den Umkehrschluss ziehen, dass es sich bei den Browser-Objekten oder dem DOM nicht um Schnittstellen handelt, oder beim DOM oder den Schnittstellen nicht um Browser-Objekte. ;-)

                              Ja - mein Vorschlag war begrifflich nicht ausgefeilt.

                              Im Lichte der bisherigen Erkenntnisse würde ich also abschließend gerne nocheinmal einen neuen Vorschlag zur Gliederung der Seite vortragen:


                              [Linke Spalte]

                              [Die Artikel lasse ich hier wieder weg.]

                              Standardobjekte

                              • Array [JavaScript/Array]
                              • ArrayBuffer
                              • Boolean
                              • DataView
                              • Date
                              • Function
                              • Generator
                              • Map
                              • Math
                              • Number
                              • Object
                              • Promise
                              • Reflect
                              • RegExp
                              • String
                              • Symbol
                              • TypedArray

                              [Rechte Spalte]

                              Schnittstellen

                              • DOM [JavaScript/DOM]
                                • Document
                                • Element
                                • Event [JavaScript/DOM/Event]
                                • EventTarget
                                • Node
                                • Range
                                • Selection

                              |Ein oder zwei Leerzeilen|

                              • Window [JavaScript/Window]
                              • Screen
                              • Navigator
                              • History
                              • Location

                              |Ein oder zwei Leerzeilen|

                              • Canvas 2D [JavaScript/Canvas_2D]
                              • Console
                              • Drag & Drop
                              • File Upload
                              • Geolocation (usw.)

                              Damit wäre ich sowohl einverstanden als auch sehr zufrieden.

                              Beim DOM denke ich, dass die wichtigsten Punkte, wie hier demonstriert, bereits auf der Portalseite sichtbar sein sollten. Ansonsten halte ich die Gruppierung ohne extra Überschriften für ausreichend. Aber wenn jemand hier gute Ideen hat, wie man bestimmte Gruppierungen unmissverständlich unter einer Überschrift zusammenfassen kann, dann würde daraus sicherlich auch kein Schaden erwachsen, zumal wir uns ja wohl soweit einig sind, dass diese Überschriften ohnehin keinen eigenen Pfad bedingen müssen.

                              Ich hatte beim nochmal nachlesen im Zusammenhang mit navigator, history und Co. auch die Bezeichnung BOM wiederentdeckt (Browser Object Model, hatte sie dann aber schon in meinem Vorschlag doch nicht gebracht, weil es die Dinge noch komplizierter gemacht hätte. Ich bin mit der Lösung, keine Extra Überschrift zu vergeben, sondern nur eine visuelle Trennung umzusetzen, also vollkommen d'accord. Schnittstellen als Überschrift für die drei Teilgruppen ist völlig in Ordnung.

                              Jedenfalls bin ich froh, dass du dich eingebracht hast und ich hoffe, ich konnte uns mit diesem Beitrag einem Konsens ein Stück näher bringen.

                              Vielen Dank an der Stelle für die Zugeständnisse, für mich wäre damit ein Konsens (zumindest zwischen uns beiden, und afais auch mit @dedlfix) erreicht.

                              Und ich entschuldige mich nochmals dafür, dass wieder so ein Roman daraus geworden ist. ;-)

                              Kein Grund sich zu entschuldigen, er war trotz Länge leicht verdaubar ;)

                              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:[
                        2. Servus!

                          Es wäre auch schön, nicht nur die Anfänger anzusprechen, sondern auch den Fortgeschrittenen noch einen Grund zu bieten, nicht gleich zum MDN zu verschwinden.

                          Mal ehrlich, haben wir da sowohl quantitativ als auch qualitativ die Inhalte dafür?

                          Vielleicht nicht ganz flach, denn davon hängt auch die Brotkrümelnavigation ab, bei der es durchaus bei einigen Themen sinnvoll ist, nicht nur generell zu "Javascript" zurückspringen zu können. Zu lang sollte die URL und damit die Navigation aber auch nicht werden. Insofern ist sicherlich der URL-Bestandteil Browser-API verzichtbar, DOM aber eher nicht.

                          Dann sollte man im Benutzerraum eine Testseite einrichten, um sich das ganze mal anschauen zu können.

                          dedlfix.

                          Herzliche Grüße

                          Matthias Scharwies

                          1. Aloha ;)

                            Es wäre auch schön, nicht nur die Anfänger anzusprechen, sondern auch den Fortgeschrittenen noch einen Grund zu bieten, nicht gleich zum MDN zu verschwinden.

                            Mal ehrlich, haben wir da sowohl quantitativ als auch qualitativ die Inhalte dafür?

                            Ist das ein Argument? Wenn nicht, dann sollte das das Ziel sein. Wenn schon, umso besser. Die Frage, ob wir dafür qualitativ und quantitativ die Inhalte haben ist also eher irrelevant, weil selbst ein Nein das Problem deshalb nicht löst.

                            Vielleicht nicht ganz flach, denn davon hängt auch die Brotkrümelnavigation ab, bei der es durchaus bei einigen Themen sinnvoll ist, nicht nur generell zu "Javascript" zurückspringen zu können. Zu lang sollte die URL und damit die Navigation aber auch nicht werden. Insofern ist sicherlich der URL-Bestandteil Browser-API verzichtbar, DOM aber eher nicht.

                            Dann sollte man im Benutzerraum eine Testseite einrichten, um sich das ganze mal anschauen zu können.

                            Ich verstehe nicht ganz, was genau daran auf einer Testseite verdeutlicht/veranschaulicht werden sollte?

                            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:[