Kaum noch zu gebrauchen

[Sabine Hallig]

Ich habe nun von mehreren Anfragen zu JavaScript keine einzige vernünftige Anleitung/Beispiele gefunden - früher hat man Alles bei SelfHTML gefunden. Die alte Version funktioniert auch nicht mehr und verlinkt nur noch auf das Wiki. Spaßeshalber hab ich bei W3 nachgeschlagen und die Antworten innerhalb weniger Sekunden gefunden, statt halber, teilweise falscher und veralteter Infos. Tut mir leid Leute, aber ihr seid grad dabei, dieses früher mal großartige Kompendium an die Wand zu fahren.

[Matthias Scharwies]

Servus!

Ich habe nun von mehreren Anfragen zu JavaScript keine einzige vernünftige Anleitung/Beispiele gefunden - früher hat man Alles bei SelfHTML gefunden. Die alte Version funktioniert auch nicht mehr und verlinkt nur noch auf das Wiki.

Die Welt hat sich verändert seit 2003:

• Ich kann an meinem Auto nichts mehr selber machen, dazu braucht man Computer.

• HTML5 und JavaScript sind komplexer als früher, da ...

• ... die Computer und Smartphones mit denen von vor 10 Jahren auch nicht mehr zu vergleichen sind.

Spaßeshalber hab ich bei W3 nachgeschlagen und die Antworten innerhalb weniger Sekunden gefunden, statt halber, teilweise falscher und veralteter Infos.

Du bist herzlich eingeladen halbe, teilweise falsche und veraltete Infos selber zu verbessern, dann profitieren die Leute nach dir! Am Wiki kann jeder mitarbeiten.

Matthias Scharwies

[Orlok]

Hallo Matthias

Wo wir gerade beim Thema sind: Ich habe mir nach unserem Gespräch wie angekündigt die meisten Artikel in der JavaScript-Sektion mal durchgelesen…

Zunächst einmal sind mir dabei zwei Duplikate aufgefallen:

• Die durchaus noch leicht verbesserungswürdigen Beschreibungen zu Kommentaren in JavaScript sind unter der Rubrik Allgemeine Regeln für JavaScript aufgeführt, obwohl sie auch ihr eigenes Kapitel Kommentare haben. Identischer Inhalt. Ich würde sagen eine von beiden Versionen ist überflüssig.

• Das Tutorial „Fader-Framework“, welches definitiv veraltet und stark überarbeitungsbedürftig ist, ist sowohl unter Tutorials als auch unter Anwendung und Praxis verlinkt. Ich denke, das sollte zumindest bei Tutorials herausgenommen werden. Das Setzen von Styles über JavaScript und das Animieren mit setTimeout sind nicht wirklich Dinge, die in einem selfHTML-Tutorial stehen sollten.

Darüber hinaus empfinde ich – wie ich in meiner letzten Mail an dich schon geschrieben habe – die strukturelle Vermischung von Informationen über die Sprache JavaScript mit solchen betreffend das Document Object Model als problematisch:

Wenn man die Startseite JavaScript aufruft, findet man zunächst die folgende Einteilung: Einführung, Sprachelemente, Objekte und APIs, wobei rein visuell schonmal nicht ersichtlich ist, ob die Rubriken Objekte und APIs hier als Unterpunkte zu Sprachelemente gedacht sind oder als eigenständige Sektionen.

Ich halte diese Aufteilung für sehr unglücklich, denn es erweckt den Eindruck, das DOM wäre Teil der Sprache selbst, was nicht der Fall ist, zumal das Document Object Model eine Schnittstelle darstellt, beziehungsweise eine Ansammlung von Schnittstellen, und dementsprechend rein formal betrachtet unter APIs aufgeführt sein sollte.

Allerdings denke ich, dass das DOM aufgrund seiner Relevanz durchaus eine eigene Rubrik beanspruchen könnte, wobei verschiedene Möglichkeiten denkbar wären:

• Auf einer Stufe mit HTML, CSS und JavaScript.
• Innerhalb von JavaScript in Abgrenzung zum Sprachkern und der Liste der anderen APIs.
• Optisch hervorgehoben und prominent plaziert innerhalb der APIs-Rubrik.

Ich persönlich tendiere hier zum zweiten Punkt, was uns dann auch schon direkt zur nächsten Problematik führt, nämlich der von dir bereits erkannten unzureichenden Differenzierung zwischen den APIs des DOM selbst, sowie auch in Richtung der HTML-spezifischen Schnittstellen:

So stellt beispielsweise die Forms API eine HTML-spezifische Erweiterung der Schnittstelle Document des DOM dar.

Auch sind Eigenschaften wie firstChild oder nodeName Bestandteil der DOM-Schnittstelle Node, nicht jedoch eigene Eigenschaften der Elemente, wie durch die undifferenzierte Auflistung unter der gleichnamigen Rubrik im Wiki suggeriert wird (obschon es hierzu an anderer Stelle eine Erklärung gibt und die Auflistung aufgrund der Vererbung ja auch nicht falsch ist, sondern bloß ungenau).

Zudem ist beispielsweise die Methode addEventListener bei Objekte/DOM/Events nicht wirklich passend, zumal die Benennung der Rubrik impliziert, dass es hier um Event-Objekte geht. Die genannte Methode addEventListener ist jedoch ein Teil der DOM-Schnittstelle EventTarget, welche ja nicht den Events selbst (Schnittstelle Event), sondern den anderen DOM-Objekten vererbt wird, auf welche die Methode angewandt werden soll.

Jedenfalls halte ich die Rubrik DOM für einen der größten Schwachpunkte der ganzen Sektion: Nicht nur weil die Abgrenzung zum Sprachkern von JavaScript und zu anderen APIs nicht gewährleistet ist oder weil bei den vorhandenen Unterpunkten nicht hinreichend differenziert wird, sondern weil es hier überhaupt und grundsätzlich an Erklärungen mangelt, welche die Hintergründe beleuchten und die jeweiligen Aspekte des Themas in einen allgemein verständlichen Zusammenhang bringen würden.

So wie ich die Sache sehe, müsste also in einem ersten Schritt zunächst die Sektion DOM aus der Sektion Objekte herausgelöst werden um die unvorteilhafte Vermischung mit denjenigen Elementen aufzuheben, die Teil des Sprachkerns von JavaScript sind, welcher als ECMAScript standardisiert ist.

Womit wir dann auch bei der Frage der grundsätzlichen Gliederung der JavaScript-Sektion wären:

Ich denke, hier sollten wir uns zunächst auf das Verhältnis der Rubrik Objekte zu den unter der Überschrift Sprachelemente aufgeführten Artikeln konzentrieren:

Hier stellen wir zum Beispiel fest, dass der gerade so ausreichende Artikel zum Thema Arrays unter Objekte/Array aufgeführt ist, ein entsprechender Artikel unter Sprachelemente jedoch fehlt.

Im Gegensatz dazu findet sich unter Objekte/Function nur eine sehr kurze Beschreibung des Function-Konstruktors, ohne Erwähnung der Eigenschaften desselben oder der Methoden von Function.prototype, wohingegen unter Sprachelemente ein entsprechender Artikel über Funktionen existiert, welcher aber extrem verbesserungswürdig ist.

Weiterhin stellen wir fest, dass – zumindest in der Shortlist – der Rubrik Objekte zwar Links zu navigator oder screen verfügbar sind, welche insgesamt doch eher von nachrangiger Bedeutung sind, wohingegen eine direkte Referenz auf das grundlegendste „Objekt“ in JavaScript hier jedoch fehlt, nämlich Object, beziehungsweise der entsprechende Link erst beim Besuch der Seite JavaScript/Objekte sichtbar wird, und dieser dann auf eine sehr knappe Erklärung von Molily verweist.

Eine Übersicht über die verschiedenen Objekteigenschaften und -methoden fehlt hier völlig.

Statt dessen gibt es unter Sprachelemente einen Artikel Grundlegende Konzepte (Objekte, Eigenschaften und Methoden), welcher jedweder Beschreibung spottet…

Meiner Ansicht nach gibt es hier also im Wesentlichen zwei Optionen, wie man die entsprechenden Inhalte gliedern kann:

• Entweder man verzichtet komplett auf die Sektion Objekte und setzt die Links zu den jeweiligen Eigenschaften und Methoden in den Kopfbereich der zugehörigen unter Sprachelemente aufgeführten Artikel

• oder wenn man die Sektion Objekte beibehalten will, sollten dort auch wirklich nur die Beschreibungen der jeweiligen Eigenschaften und Methoden aufgeführt sein, wohingegen zusammenhängende Artikel konsequent unter Sprachelemente aufgelistet sein sollten.

Dabei wäre es womöglich auch nicht schlecht, einmal darüber nachzudenken, ob die jeweiligen Überschriften nicht vielleicht etwas präziser formuliert werden können…

Jedenfalls wäre in diesem Zusammenhang auch zu prüfen, ob die Liste der Events nicht doch besser unter DOM/Events aufgehoben wäre, wohingegen der von mir in Bearbeitung befindliche Artikel zur Ereignisverarbeitung vielleicht eher zu den allgemeinen Artikeln unter der etwas unglücklich gewählten Überschrift Sprachelemente einzureihen wäre.

Darüber hinaus fehlt soweit ich das erkenne in der JavaScript-Sektion auch ein Artikel, welcher sich einmal etwas näher mit dem Thema Vererbung auseinandersetzt, und auch der bestehende Artikel zum Thema Variablen müsste mal etwas ausführlicher gefasst werden, dito die Einführung.

Was ich von meiner Seite aus anbieten kann ist, in den nächsten Wochen nach der Fertigstellung des Artikels zum Thema Event-Handling mich der Themen: Objekte, Funktionen und Vererbung anzunehmen, sowie eventuell den Artikel „Variablen“ um tiefergehende Betrachtungen zum Thema Scope und Beschreibungen von let und const anzureichern, sofern mir in dieser Hinsicht niemand zuvorkommt…

Die Neufassung der Einführung, die Umsetzung der Trennung von JavaScript und DOM sowie die meiner Ansicht nach dringend notwendige Verbesserung der Inhalte zum Thema Document Object Model würde ich hingegen gerne anderen überlassen. ;-)

Gruß,

Orlok

[Felix Riesterer]

Lieber Orlok,

vielen Dank für Deine umfassenden Ausführungen! Das bietet viele wertvolle Ansätze, um die Doku auf Vordermann zu bringen!

• Das Tutorial „Fader-Framework“, welches definitiv veraltet und stark überarbeitungsbedürftig ist,

Magst Du mir erklären, welche Aspekte Du genau meinst? Meiner Meinung nach sollte es als "damals hat man das vielleicht so gemacht, heute bieten sich diverse alternative Vorgehensweisen an, die aufgrund besserer Browserunterstützung mit diesen Mitteln so umgesetzt werden" stehen bleiben. Aber selbstverständlich können an den passenden Stellen Anmerkungen dran, dass dieses oder jenes nun wirklich keine gute Idee mehr ist - mit Link zu einer zeitgemäßeren Lösung und Ausprobier-Seite.

Sollte der Artikel inhaltlich aber rettungslos verloren sein, so kommt er eben weg. Damals hatte ich damit viel gelernt und wollte zu den Feature-Artikeln beitragen. Aber sieben Jahre sind halt doch drei-einhalb Generationen in der IT-Welt...

Liebe Grüße,

Felix Riesterer.

[Orlok]

Hallo Felix

Als ich „überarbeitungsbedürftig“ schrieb, meinte ich auch genau das, und nicht etwa „in die Tonne treten“ oder sowas in der Art. ;-)

Es ging mir an dieser Stelle darum, einerseits auf die doppelte Verlinkung hinzuweisen und andererseits darauf aufmerksam zu machen, dass dieser Artikel nach heutigen Maßstäben nicht mehr uneingeschränkt zu empfehlen ist.

Dabei denke ich, dass du selbst recht gut weißt, welche Teile des Tutorials heutzutage überholt sind, nämlich im Wesentlichen alles, was JavaScript-gesteuerte Animationen betrifft, und die unschönen Seiteneffekte, die diese Vorgehensweise so mit sich bringt, weshalb ich auch nicht wirklich einen Sinn darin sehe, jetzt und an dieser Stelle deinen sieben Jahre alten Code zu zerpflücken. ;-)

Ich möchte mich statt dessen lieber in konstruktiver Kritik üben und dir widersprechen, wenn du schreibst:

Meiner Meinung nach sollte es als "damals hat man das vielleicht so gemacht, heute bieten sich diverse alternative Vorgehensweisen an, die aufgrund besserer Browserunterstützung mit diesen Mitteln so umgesetzt werden" stehen bleiben. Aber selbstverständlich können an den passenden Stellen Anmerkungen dran, dass dieses oder jenes nun wirklich keine gute Idee mehr ist - mit Link zu einer zeitgemäßeren Lösung und Ausprobier-Seite.

Statt lediglich ein paar Warnhinweise anzubringen und das Tutorial langsam in der Versenkung verschwinden zu lassen, fände ich es besser, wenn sich jemand die Mühe machen würde, es auf den aktuellen Stand der Technik zu bringen.

Das heißt, ich würde eher eine Generalüberholung des Artikels begrüßen, in dem Sinne, dass gezeigt wird, wie man mit CSS-Animationen eine Slideshow erstellt, die ohne JavaScript funktioniert, und wie man als progressive enhancement mit JavaScript die Möglichkeit der Benutzerinteraktion hinzufügt.

Wenn ich an die vielen Möglichkeiten denke, die Animationen und Transformationen in CSS bieten, was mit den Canvas-APIs heute möglich ist und welche Features der Benutzersteuerung mit JavaScript darüber hinaus noch hinzugefügt werden könnten, denke ich, dass dieses Tutorial in einer überarbeiteten Version eine absolute Bereicherung für das Wiki sein könnte, gewissermaßen als Paradebeispiel für unobtrusive JavaScript!

Es müsste sich halt nur jemand die Arbeit machen…

Vielleicht du? ;-)

Gruß,

Orlok

[Felix Riesterer]

Lieber Orlok,

Als ich „überarbeitungsbedürftig“ schrieb, meinte ich auch genau das, und nicht etwa „in die Tonne treten“ oder sowas in der Art. ;-)

ist ja schon gut, ich fühle mich nicht im Mindesten angegriffen! Mir war schon während der Veröffentlichung klar, dass Teile meines technischen Vorgehens nicht mehr so wirklich zeitgemäß waren - was das Entwickeln einer Slideshow angeht. Das war nur der Aufhänger. Wesentlich wichtiger war mir der Aspekt, wie man ein Script konzipieren kann, das sich störungsfrei mit anderen Scripts verträgt. Selbst dieses Jahr meine ich im Forum wieder die Standardfrage gelesen zu haben "wie kann ich Script-A und Script-B gleichzeitig in meine Seite einbinden?", sodass der didaktische Ansatz mit dem Vorführen der unterschiedlichsten Aspekte, wie man ein Script schreiben kann, noch nicht wirklich ganz überholt ist. Auch wenn man heute (oder schon damals?) speziell für eine Bilderslideshow anders vorgehen sollte.

Es ging mir an dieser Stelle darum, einerseits auf die doppelte Verlinkung hinzuweisen und andererseits darauf aufmerksam zu machen, dass dieser Artikel nach heutigen Maßstäben nicht mehr uneingeschränkt zu empfehlen ist.

OK.

Dabei denke ich, dass du selbst recht gut weißt, welche Teile des Tutorials heutzutage überholt sind, nämlich im Wesentlichen alles, was JavaScript-gesteuerte Animationen betrifft,

Das war von Anfang an ein Kritikpunkt, den insbesondere @Gunnar Bittersmann nicht müde wurde zu betonen. Schon damals hatte er damit absolut Recht. Jedoch war das Herstellen eines Slideshow-Scripts nur der Aufhänger...

Ich möchte mich statt dessen lieber in konstruktiver Kritik üben und dir widersprechen, wenn du schreibst:

[...] können an den passenden Stellen Anmerkungen dran, dass dieses oder jenes nun wirklich keine gute Idee mehr ist - mit Link zu einer zeitgemäßeren Lösung und Ausprobier-Seite.

Statt lediglich ein paar Warnhinweise anzubringen und das Tutorial langsam in der Versenkung verschwinden zu lassen, fände ich es besser, wenn sich jemand die Mühe machen würde, es auf den aktuellen Stand der Technik zu bringen.

Wenn man den Aspekt des "ich schreibe ein Script so, dass es sich mit anderen verträgt" in den Vordergrund stellt, dann sollte das Tutorial noch immer einen Wert haben - auch in seinem in die Jahre gekommenen Stil. Immerhin wird gezeigt, wie man Objekt-Literale in einem Script nutzen kann, wie man sich Closures zunutze machen kann, und wie man weitere Dateien ins Dokument "nachlädt".

Das heißt, ich würde eher eine Generalüberholung des Artikels begrüßen, in dem Sinne, dass gezeigt wird, wie man mit CSS-Animationen eine Slideshow erstellt, die ohne JavaScript funktioniert, und wie man als progressive enhancement mit JavaScript die Möglichkeit der Benutzerinteraktion hinzufügt.

Das wäre ein deutlich anderer Ansatz, als ihn mein Tutorial hat. Die verschiedenen Vorgehensweisen, die sich zum Teil in ihrer Handhabung widersprechen (warum sollte ich ein Objekt window.FaderFramework haben wollen, wenn ich an anderer Stelle grundsätzlich zu lokalen Variablen rate?), sind ja geradezu deshalb aufgeführt, um zu zeigen, was möglich und in welchem Kontext jeweils sinnvoll und ratsam ist. Deshalb auch die Zwischenlösungen.

Wenn ich an die vielen Möglichkeiten denke, die Animationen und Transformationen in CSS bieten, was mit den Canvas-APIs heute möglich ist und welche Features der Benutzersteuerung mit JavaScript darüber hinaus noch hinzugefügt werden könnten, denke ich, dass dieses Tutorial in einer überarbeiteten Version eine absolute Bereicherung für das Wiki sein könnte, gewissermaßen als Paradebeispiel für unobtrusive JavaScript!

Nein, es wäre ein Paradebeispiel, wie man auf Webseiten mit modernsten Browserstandards animiert, im Wesentlichen ohne JavaScript und wenn mit, dann nur mit JavaScript als übergeordneter Steuerzentrale, die die Animationen eher "beobachtet", als sie aktiv umzusetzen.

Dabei lernt man, wie man Transitions von CSS abarbeiten lässt, um auf neue Ereignisse zu reagieren.

Es müsste sich halt nur jemand die Arbeit machen…

Vielleicht du? ;-)

Ich sehe den didaktischen Ansatz in meinem Tutorial noch nicht als überholt. Daher möchte ich ihn nicht grundsätzlich im Hinblick auf "vernünftige Slideshow-Umsetzung" umarbeiten. Wenn überhaupt, dann möchte ich ihn im Hinblick auf meinen Ansatz "vernünftiges Schreiben eines JavaScriptes" mit meinen inzwischen gemachten Erfahrungen verfeinern.

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

Schon damals hatte er damit absolut Recht.

Hatte ich geklagt? Oder hatte ich **r**echt?

Oder hat die Rechtschreibreform der deutschen Sprache Unrecht angetan?

LLAP 🖖

[Matthias Scharwies]

Servus!

Vielen Dank für die umfangreiche und qualifizierte Rückmeldung.

Wir werden versuchen, sobald wie möglich eine fachlich genaue Struktur umzusetzen und verbesserungswürdige Artikel mit {{ToDo}}s zu versehen, so dass diese dann nach und nach abgearbeitet werden können.

Was ich von meiner Seite aus anbieten kann ...

@Orlok - Vielen Dank für deine Hilfe. Ich freue mich schon auf den Beitrag zum Event-Handling!

... würde ich hingegen gerne anderen überlassen. ;-)

@all @andere - Das Wiki kann nur qualitativ und quantitativ wachsen, wenn möglichst viele dazu beitragen. Springt über euren Schatten und werdet aktiv! Jetzt wird's Herbst, perfekte Zeit zum Artikel schreiben.

Herzliche Grüße!

Matthias Scharwies

[1unitedpower]

Ich halte diese Aufteilung für sehr unglücklich, denn es erweckt den Eindruck, das DOM wäre Teil der Sprache selbst, was nicht der Fall ist, zumal das Document Object Model eine Schnittstelle darstellt, beziehungsweise eine Ansammlung von Schnittstellen, und dementsprechend rein formal betrachtet unter APIs aufgeführt sein sollte.

Dem stimme ich zu. Ich würde hier eine mehrschichtige Aufteilung vorschlagen, auf oberster Ebene mit zwei Punkten: Standard APIs und Browser built-ins. Die Wortwahl ist dem ES2015-Standard nachempfunden. Unter "Standard-APIs" würden sich APIs wiederfinden, deren Semantik vom EcmaScript-Standard festgelegt wird, bswp. Object, Array, Date und Math. Unter Browser built-ins fielen in etwa das DOM oder WebGL. Bei Bedarf können diese Punkte in weitere Unterpunkte zerfallen. Das ließe sich in einem Diagramm ähnlich zu http://overapi.com/javascript/ veranschaulichen.

[Matthias Apsel]

Hallo Sabine Hallig,

Spaßeshalber hab ich bei W3 nachgeschlagen und die Antworten innerhalb weniger Sekunden gefunden

Das W3C ist ja auch die Stelle, die quasi die Gesetze macht. Natürlich sind die immer topaktuell, weil sich alle, vor allem die Browserhersteller, nach ihnen richten (sollten) und sie diejenigen sind, die die Entwicklung bestimmen. Ansonsten kann ich mich Matthias Scharwies nur anschließen: Die Dokumentation ist für alle da, sie ist kostenlos, wird durch freiwillige Arbeit voran gebracht. Jeder kann seinen Beitrag dazu leisten. Gib etwas von dem zurück, was du vielleicht bei SELFHTML gelernt hast!

statt halber, teilweise falscher und veralteter Infos

Wenigstens eine konkrete Information, welche teilweise falschen und veralteten Infos du hier gefunden hast, würden uns helfen, die Fehler zu beheben. Optimal wäre natürlich, wenn du selbst die entsprechenden Artikel bearbeiten würdest. Das ist der große Vorteil eines Wikis gegenüber einer abgeschlossenen Dokumentation. Jeder kann sich einbringen, wenn er denn möchte.

Bis demnächst
Matthias

[Felix Riesterer]

Liebe Sabine,

Tut mir leid Leute, aber ihr seid grad dabei, dieses früher mal großartige Kompendium an die Wand zu fahren.

anscheinend hast Du von der Diskussionskultur bei SELFHTML noch nicht genügend mitgenommen... sonst hättest Du wenigstens eine kleine Liste an Links zu den von Dir bemängelten Informationen gepostet. Tut mir leid, aber Dein Posting hat Deine Glaubwürdigkeit gerade ziemlich an die Wand gefahren.

Liebe Grüße,

Felix Riesterer.

[pl]

Guten Morgen,

die Seitenstruktur und logische Gliederung des guten alten SELFHTML fand ich tatsächlich besser als das was ich heute vorfinde. So habe ich mir dieses Grundgerüst als Vorbild genommen: Als eine solide Basis zum Aufbau komplexer Websites in der statische Seiten, Seiten mit multimedialen Inhalten, Seiten verschiedener Content-Types und interaktive Anwendungen in einem einheitlichem Layout nahtlos ineinander übergehen wobei die dahinterliegende Technik dem Benutzer transparent ist.

Für meine Kollegen im Intranet habe ich um 2002 ein SELFHTML-Download wie folgt umgebaut: Von allen HTML-Seiten die <head>-Bereiche entfernt, die Bodies in einer DB gespeichert, eine zentrale Konfiguration erstellt und SELFHTML über ein proprietäres Perl-Framework neu verlinkt (dynamisch). Damit war eine Volltextsuche über alle Inhalte möglich, sprich, ein zügiges Arbeiten mit diesem Kompendium im gewohnten Layout mit gewohnter Navigation (von angepassten <head>-Bereichen abgesehen).

Für diesen Zweck in meiner Firma wars nicht notwendig, aber es wäre ein Einfaches gewesen, aufgrund der Datenhaltung (MySQL) ein Backend fürs Content-Management im Multi-User-Betrieb draufzusetzen. Einschließlich Versionierung einzelner Artikel. pl