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