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