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