Weblog-Artikel: Der sinnvolle Einsatz von JavaScript

[molily]

Hallo zusammen,

im jüngsten, etwas längeren Weblog-Beitrag »Der sinnvolle Einsatz von JavaScript« starten wir die öffentliche Diskussion über SELFHTML 9.

Anschließend an die darin vorgestellten Theorien möchten wir hier die Frage stellen, was ihr von den Konzepten haltet und wie wir sie SELFHTML 9 berücksichtigen können.

Im Beitrag werden folgende allgemeine Fragen gestellt:
Welche konkreten Anwendungsbereiche von Javascript gibt es?
Wie kann sich dies im Aufbau des JavaScript-Kapitels niederschlagen?
Welche Javascript-Anwendungen geben ein gutes Beispiel ab und sollten in SELFHTML 9 vorgestellt werden?
Ich bitte euch, zu diesen Fragen Stellung zu nehmen im Anschluss an die Lektüre des Weblog-Eintrags.

Auch ich habe mir Gedanken gemacht und zahlreiche JavaScript-Beispiele im Web durchforstet. Dabei bin ich auf folgende Anwendungsbereiche gestoßen, die mir sinnvoll erscheinen.

Kategorie: Unobtrusive, voll zugänglich und abwärtskompatibel

• Formularvalidierung
  Formularvalidierung wird durchgängig als das Musterbeispiel von sinnvollem JavaScript-Einsatz genannt.

• Interaktive, mehrstufige Formulare mit Fallunterscheidungen, Formular-Eingabehilfen, Formular-Assistenten
  Gewisse komplexe Formulare, bei denen der Benutzer irrelevante Teile überspringen müsste oder unzählige Checkboxen (de-)aktivieren müsste, lassen sich mit etwas JavaScript schneller bedienen und der Benutzer lässt sich besser leiten.

• Darstellung von semantischen Informationen, die schon im Markup untergebracht sind, aber gängigerweise nicht dargestellt werden und mit CSS nicht so komfortabel umgesetzt werden können.
  Beispielsweise wird bei <blockquote cite="..."> ein Link zur Quelle eingefügt, aus meist unsichtbaren link-Elementen im head wird ein Navigationsmenü, beim Bewegen der Maus über Überschrift wird ein Link angezeigt, über den sich der Abschnitt adressieren lässt

• Bildergalerien, Slideshows, Präsentationen

• Aufklappnavigationen, Baumstrukturen einfacher durchstöbern
  (Wert zweifelhaft!)

• Datum-Auswahlboxen in Formularen, Kalender mit Blätterfunktion
  Sieht man z.B. auf Seiten von Airlines, Reiseveranstaltern und anderen Ticket-Shops.

• »Presentational JavaScript«: JavaScript als CSS-Unterstützung.
  Layout-Anpassungen und Layout-Effekte, die nur über JavaScript möglich sind, weil JavaScript besser auf die Umgebungsbedingungen reagieren kann. Effekte, die Änderungen im Markup nötig machten und damit die Trennung von Inhalt und Präsentation durchbrächen, werden dynamisch mit JavaScript eingefügt.

• Stylesheet-Wechsler als Interface für <link rel="stylesheet alternative">
  Allgemeiner Wert zweifelhaft. Sinnvoll vielleicht für: Erhöhter Kontrast, für Mobilgeräte, spaltenlos und anpassungsfähiger, erhöhte Schriftgröße

• Dynamisch eingefügte Navigations- und Lesehilfen.
  Zum Beispiel Hover-Lesemarkierung bei Datentabellen, Daten unterschiedlich anzeigen, sortieren und durchsuchen, Lesen erleichtern, Orientierung geben, Aufmerksamkeit lenken.

• Kennt ihr weitere Bereiche oder lassen sich die Scripte, die ihr für besonders nützlich und beispielhaft erachtet, bereits in diese Bereiche einordnen?

Kategorie: nicht abwärtskompatible, sozusagen "obtrusive"

Eine solche JavaScript-Anwendung soll gemäß dem Unobtrusive-Konzept völlig verworfen werden. Tatsächlich gehören in diese Kategorie alle JavaScript-Anwendungen, die nicht nur "Zusätze" zu bestehenden klassischen HTML-Dokumenten darstellen, indem sie ihnen "Behavior" hinzufügen. Sie sind daher erst einmal nicht von selbst abwärtskompatibel.

Während alle Unobtrusive-Jünger diesen JavaScript-Einsatz verteufeln und für obsolet erklären, bin ich der Meinung, dass JavaScript erst hier sein nützliches Potenzial entfalten kann. Das heißt nicht, dass das Unobtrusive-Konzept irrt. Natürlich sollte man immer dann, wenn unobtrusive möglich ist, nach diesem Schema vorgehen.

Ich habe diejenigen Anwendungen im Kopf, die ihre Quintessenz verlieren, wenn man JavaScript wegnimmt. Zwar lässt sich dieselbe Funktionalität auch abwärtskompatibel bzw. rein serverseitig dynamisch umsetzen, aber die Anwendung bekommt gerade dadurch ihren Mehrwert, dass sie mit JavaScript gelöst ist. Ohne JavaScript würden sie ihren Charakter und ihre Nützlichkeit weitesgehend verlieren.

Ich denke an:

• gewisse Spiele und Quizzes
• Demonstrationen, Simulationen, Animationen
• Kleine Helferlein wie Farbwähler, Konvertierung, Berechnung

Tatsächlich ist diese JavaScript-Anwendung im Web sehr verbreitet und für mich ist es ebenso eine Tatsache, dass diese Anwendungen das Web bereichert. Trotzdem wird in diesem Bereich natürlich der größte Missbrauch betrieben. Durch das Unobtrusive-Konzept lassen sich aber die meisten unangemessenen JavaScript-Anwendungen dieser Kategorie ausschließen.

Eine weitere Kategorie habe ich noch nich näher überdacht: Anwendungsbereiche von XMLHttpRequest bzw. Ajax. Ajax-Anwendungen teilen viel mit der eben beschriebenen Kategorie, sie gehen in ihren Möglichkeiten aber noch weiter. Konkrete Anwendungsbereiche lassen sich schwer benennen, schließlich fallen Ajax-Anwendungen aus dem bisher bekannten Web heraus. Ich möchte hier erst einmal nur auf 10 Places You Must Use Ajax hinweisen und bitte auch dazu um Kommentare und Ergänzungen.

Grüße,
Mathias

[Jörg Peschke]

Hallo,
Sehr großes Kompliment für den sehr gelungenen, sachlichen Artikel!

Zur "obtrusive/unobtrusive"-Diskussion:
Ich finde, eine JavaScript-Anwendung muss nicht zwangsläufig abwärts-kompatibel (d.h. also auch ohne JavaScript nutzbar) gehalten werden.
In Fällen wo sie es nicht ist, sollten aber JavaScript-freie Alternativen angeboten werden.

Google Suggest finde ich z.b. eine hervorragende Sache, solange es das "normale" Google für JavaScript-lose Browser auch noch gibt. Schwierig wäre es nur, wenn ein User Google gar nicht mehr benutzen könnte, wenn er JavaScript ausgeschaltet hat.

Allerdings stellt sich natürlich die Frage, in wievielen Fällen es wirtschaftlich möglich ist, BEIDE Alternativen anzubieten (was natürlich das Optimum ist), und so kommt es letztendlich wieder darauf an, wieviel Freiheiten man dem Benutzer bei der Nutzung lassen will ;)

Gruss,
Jörg

[MudGuard]

Hi,

In Fällen wo sie es nicht ist, sollten aber JavaScript-freie Alternativen angeboten werden.
Google Suggest finde ich z.b. eine hervorragende Sache, solange es das "normale" Google für JavaScript-lose Browser auch noch gibt.

Da braucht es gar keine Alternative, da die Seite so wie sie ist auch ohne Javascript das Suchen ermöglicht. Es gibt dann halt keine Vorschläge - also verhält sich die Seite so wie das "normale" Google, wenn Javascript deaktiviert ist.

google suggest taugt also nicht als Beispiel für eine Seite, zu der es eine javascript-lose Alternative gibt ...

cu,
Andreas

[Jörg Peschke]

Moin,

Da braucht es gar keine Alternative, da die Seite so wie sie ist auch ohne Javascript das Suchen ermöglicht. Es gibt dann halt keine Vorschläge - also verhält sich die Seite so wie das "normale" Google, wenn Javascript deaktiviert ist.

Oh, hoppla. Du hast recht. Ok, schlechtes Beispiel, gebe ich zu ;)

Jörg

[zeek]

Gerade gefunden. Vielleicht für den Einstieg einfacher:
<a href="http://www.microformats.org/blog/2005/12/18/ajax-vs-ahah/">AHAH</a>

[Tim Tepaße]

Hallo,

Gerade gefunden. Vielleicht für den Einstieg einfacher:
<a href="http://www.microformats.org/blog/2005/12/18/ajax-vs-ahah/">AHAH</a>

Hm. Gerade (selbst) erfunden: AIAJ (Asynchrone iFrame-Elemente and JSON)

Im Ernst: Das ist eher eine Erleichterung, den JS-Code beim Cliebt zu minimieren, wobei das Zusammenbasteln dann auf den Server geschehen muss. Das ist auch so nix Neues, viele, die von AJAX reden, ignorieren eh das X und schicken HTML über den Draht. Auch hier im Forum.

Das geht aber am Thema vorbei, schließlich ist nach sinnvollen Anwendungszwecken von Javascript gefragt, nicht wie man das dann eventuell benötigte JS mehr oder weniger effizient gestaltet.

Tim

[Chräcker Heller]

Hallo,

*hüstel* - könnte man nicht pauschal sämtliche Interaktionsfelder, die über die Browsertechniken (da kann man ja auch drauf rumklicken und zum Beispiel einfach wegsurfen) und html-Möglichkeiten (ich interagiere ja auch, wenn ich etwas in ein formular einsetze und das dann abschicke) als JavaScriptsinnvolles Gebiet nennen? (naja, flash müste man noch gegenrechnen....)

Es kann also "alles" sein, was mit einer anderen Technik nicht "sicherer" den Client und den Besucher erreicht.

Da kann man doch jetzt keine Liste erstellen. Die endet doch immer nur an der Phanatsiegrenze des Listenerstellers. Oder habe ich die Fragestellung falsch verstanden?

Chräcker

[molily]

Hallo,

*hüstel* - könnte man nicht pauschal sämtliche Interaktionsfelder, die über die Browsertechniken (da kann man ja auch drauf rumklicken und zum Beispiel einfach wegsurfen) und html-Möglichkeiten (ich interagiere ja auch, wenn ich etwas in ein formular einsetze und das dann abschicke) als JavaScriptsinnvolles Gebiet nennen? (naja, flash müste man noch gegenrechnen....)

Es kann also "alles" sein, was mit einer anderen Technik nicht "sicherer" den Client und den Besucher erreicht.

Nunja, das finde ich ziemlich vage - ich dachte daran, wie man einem Anfänger die Möglichkeiten und unzweifelhaft »positiven« Anwendungsgebiete von JavaScript erklären könnte.

Es gibt natürlich unzählige Arten der Interaktion, die prinzipiell nur mit JavaScript, nicht mit klassischen HTML/CSS-Seiten und serverseitiger Dynamik umsetzbar sind.  Nur sagt dies alleine wenig darüber aus, ob eine solche JavaScript-Anwendung einen wie auch immer gearteten Mehrwert bringt oder ob sie letztlich die Besucher nur belästigt und einengt. Die Erfahrung zeigt, dass der JavaScript-Einsatz, der erst einmal blind alle Möglichkeiten ausschöpfen will, fragwürdig und problematisch wird.

Da kann man doch jetzt keine Liste erstellen. Die endet doch immer nur an der Phanatsiegrenze des Listenerstellers. Oder habe ich die Fragestellung falsch verstanden?

Die Frage war, mit welchen Beispiele man in SELFHTML 9 die Aufgabengebiete von JavaScript illustrieren kann. »JavaScript, was ist das eigentlich? Was kann JavaScript für mich tun, was kann es nicht? Wo sollte ich es einsetzen, in welchen Fällen und wie kann ich Zugänglichkeit gewährleisten?« Dazu finde ich es hilfreich, eine Liste mit Bereichen zu erstellen. Zu jedem Bereich könnte SELFHTML 9 dann ein Beispiel enthalten. Und die Erklärung der Sprache wäre auf diese Anwendungsgebiete ausgerichtet.

Momentan werden unzählige Objekte dokumentiert, nur weil sie existieren. Aber Scripte, die sie verwenden und gleichzeitig die Webseite bereichern, werden zu den wenigsten Objekten vorgestellt. In SELFHTML 9 würde ich daher von der Anwendung ausgehen: Was sollen wir mit JavaScript tun? Natürlich bedingen sich die Ziele und das nötige Handwerkszeug gegenseitig, aber didaktisch gesehen stiftet ein vorgestelltes Feature, für das keine praktische Anwendung dargestellt wird, zunächst einmal nur Verwirrung. Die Leser experimentieren damit, setzen es an den unmöglichsten Stellen ein, bis sie irgendwann merken, dass keiner der Besucher begeistert über einen solchen JavaScript-Gebrauch ohne Essenz und Hintergedanken ist.

Natürlich kann und soll nicht die gesamte JavaScript-Verwendung kategorisiert werden - schließlich bräuchte SELFHTML 9 niemandem JavaScript beizubringen, wenn alle sinnvollen Scripte schon geschrieben worden wären. Es sollen lediglich beispielhaft genannte Bereiche sein, um Javascript-Anfängern dabei zu unterstützen, JavaScript kompetent einsetzen zu können. Und eben konkrete Scripte, die über sich hinaus auf solche Bereiche hinweisen. An dieser Stelle geben Theorien wie »Unobtrusive JavaScript« und die genannten Ergänzungen dem Lernenden zunächst einen sicheren Bereich der bewussten und kompetenten Betätigung.

Mathias

[Ingo Turski]

Hi,

Momentan werden unzählige Objekte dokumentiert, nur weil sie existieren. Aber Scripte, die sie verwenden und gleichzeitig die Webseite bereichern, werden zu den wenigsten Objekten vorgestellt. [...] didaktisch gesehen stiftet ein vorgestelltes Feature, für das keine praktische Anwendung dargestellt wird, zunächst einmal nur Verwirrung. Die Leser experimentieren damit, setzen es an den unmöglichsten Stellen ein, bis sie irgendwann merken, dass keiner der Besucher begeistert über einen solchen JavaScript-Gebrauch ohne Essenz und Hintergedanken ist.

Dabei frage ich mich, ob tatsächlich alle Features vorgestellt werden sollten und wenn ja, mit einem Beispiel oder lieber doch im Fall des Falles ohne. Oder wären dann negative Beispiele sogar sinnvoller, wie "window.status = 'Dieser Text wird *vielleicht* in der Statusleiste angezeigt und verhindert die Anzeige der vom Nutzer an dieser Stelle erwarteten Information'" ?

freundliche Grüße
Ingo

[Jeena Paradies]

Hallo,

Welche konkreten Anwendungsbereiche von Javascript gibt es?

Mir fällt da sofort die JavaScript SELFHTML Suche ein, die ist für mich der Inbegriff von sinnvollem JavaScript einsatz, da sie da eingreift wo es anders gar nicht möglich ist, da sonst ein Server mit einer Scriptsprache gebraucht werden würde welchen nicht jeder bei sich zu Hause auf dem Rechner installiert hat.

Kategorie: Unobtrusive, voll zugänglich und abwärtskompatibel

Live Suche. Also beim Eintippen des Suchbegriffes wird eine Liste der gefundenen Übereinstimmungen angezeigt ohne dass man das Forumular abschicken muss. Wenn jemand kein JS an hat dann muss er einfach das Formular doch abschicken.

BBCode ersetzung, eine sehr feine Sache wie ich finde. Eingabevereinfachungsscript von mir Wobei mir gerade auffällt, dass ich da noch an diesem window.onload = function () { ... } arbeiten sollte, damit das Script sich nicht mit anderen beist. Das kam als ich an dem Script mit Hilfe von SELFHTML gearbeitet habe auch nie richtig zum Vorschein, dass es dabei Probleme geben könnte.

• Bildergalerien, Slideshows, Präsentationen

Ja hier hat Christian Kruse in seinem Galleriescript zum Beispiel auf <link rel="next"> zugegriffen um eine Slideshow automatisch zu gestalten, ohne dass man auf einen "Nächstes Bild" Link klicken muss. So etwas finde ich sehr sinnvoll.

• »Presentational JavaScript«: JavaScript als CSS-Unterstützung.

Hier fällt mir vor allem der IE 7 von Dean Edwards ein, der uns beim Umstieg auf den richtigen IE 7 in Zukunft sehr viele Sorgen abnehmen könnte.

Grüße
Jeena Paradies

[Jeena Paradies]

Hallo,

Wobei mir gerade auffällt, dass ich da noch an diesem window.onload = function () { ... } arbeiten sollte, damit das Script sich nicht mit anderen beist. Das kam als ich an dem Script mit Hilfe von SELFHTML gearbeitet habe auch nie richtig zum Vorschein, dass es dabei Probleme geben könnte.

So, gepuscht von Molilys Artikel über Unobtrusive JavaScript Layer habe ich mein BBCode Eingabevereinfachungsscript überarbeitet. Jetzt sollte es sich nicht mehr mit anderen Scripten beisen und es sollten auch keine Fehler entstehen, wenn Browser da irgendetwas nicht unterstützen, was ja bei der Beschreibung von Unobtrusive JavaScript hervorgehoben wurde.

Die Funktionalität ist die gleiche geblieben, ich habe aber das ganze in eine Klasse gepackt, damit man mit den Funktionsnamen keine Probleme mehr hat. Außerdem habe ich - wie mir molily mal emphohlen hat - addLoadEvent() von dieser Seite benutzt um nicht onLoad Scripte von anderen JavaScript Dateien zu überschreiben. Dabei konnte ich wieder mal sehr viel lernen, was das objekt orientierte Programmieren in JavaScript angeht.

Jetzt würde mich doch mal interessieren, habe ich damit genau so gearbeitet, wie es im Unobtrusive JavaScript Model vorgesehen ist, oder habe ich immer noch etwas übersehen?

Grüße
Jeena Paradies

[Felix Riesterer]

Lieber Mathias,

bei der ganzen Diskussion wo JS sinnvoll ist und wo nicht, fände ich es doch gerade erst interessant, in SelfHTML 9 eben Fälle zu zeigen, in denen der (mittlerweile) sinnlose/unsinnige Einsatz von JS anhand empfehlenswerterer Alternativen vorgestellt wird.

Beispiel Dropdown-Menü: Das geht ja wunderbar mit CSS. Doch gerade um dem veralteten IE das Hovern auch für nicht-<a>-Elemente beizubringen, benötigt man eben Javascript (oder eben JScript). Aber falls ein Browser das mit CSS alleine hinbekommt, dann ist doch die JS-lose Version auf alle Fälle vorzuziehen! Auch wegen Barrierefreiheit ist hier der Verzicht auf JS ein für JS-Anfänger sicherlich hilfreicher Denkanstoß.

Dieses und weitere Beispiele, die das Benutzen der Seite mit JS angeblich (oder scheinbar) verbessern, es unter der Lupe betrachtet aber doch nicht so so wirklich tun, gehören meiner Meinung nach in ein eigenes Unterkapitel zu JS und seiner sinnvollen Verwendung.

Sicherlich sollte man zunächst die Möglichkeiten von JS sehr umfangreich vorstellen, damit ein Scriptautor sich informieren kann, falls er etwas Spezielles plant. Ergänzend kommt dann das Unterkapitel über Sinn und Unsinn beim Einsatz von Scripten. Das sollte dann manchen nicht-Profi nochmals zum Nachdenken anregen (besonders die Verwendung von window.open()!)...

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Heinzelhund]

Hallo Allesamt,

mal 'nen 'kezerischer' Beitrag.

Was ist ein sinnvoller Einsatz für JS?
1 + 1 = x

Als erklärende Beispielscripte bieten sich kurze Teile an, die die zu erklärende Funktionalität demonstrieren und nicht riesige Anwendungen. Im obigen Beispiel würde eine einfache Alertbox mit der Zahl 2 ausreichen.

Erklärt mir selfHTML eigentlich, dass man mit CSS sehr viel Unsinn machen kann, z.B. geringe Kontraste, unleserliche Spaltenbreite bei Fließtexten, überflüssige Hover-Effekte, chaoshafte Seiteneinteilungen und unübersichtlich Anordnungen oder einfach nur eine geschmacklose Gestaltung?

Eine einfache, unpolemische Darstellung standardkonformer Techniken wäre angebracht. Beispielweise eine bessere Erläuterung des Eventobjektes nach DOM usw.

Ciao
Heinzelhund

[Ingo Turski]

Hi,

Erklärt mir selfHTML eigentlich, dass man mit CSS sehr viel Unsinn machen kann, z.B. geringe Kontraste, unleserliche Spaltenbreite bei Fließtexten, überflüssige Hover-Effekte, chaoshafte Seiteneinteilungen und unübersichtlich Anordnungen oder einfach nur eine geschmacklose Gestaltung?

Ja - zugegeben allerdings nur sehr knapp angerissen.
Ich sehe hier allerdings auch einen großen Unterschied zu Javascript: ungünstige CSS-Darstellungen sieht man sofort (ob man sie bemerkt, ist eine andere Sache), aber eine fehlende Alternative zu Javascript sieht man erst, wenn man Javascript deaktiviert - und einige wissen offenbar noch nichtmal, daß und wie das in ihrem Browser geht. ;-)

freundliche Grüße
Ingo

[molily]

Hallo,

Als erklärende Beispielscripte bieten sich kurze Teile an, die die zu erklärende Funktionalität demonstrieren und nicht riesige Anwendungen.

Wie löst das die angesprochenen Probleme? Auch wenn ich schrieb »SELFHTML enthält zahlreiche gestellte, zum Teil irreführende, in der Praxis nur bedingt nützliche Beispielscripte«: Ich habe nichts gegen didaktisch zugespitzte, fingierte Beispiele, die eben einfach nur das zu erklärende Feature demonstrieren. Das ist an sich nicht problematisch.

Problematisch wird es, wenn man sechshundertunddreißig Objekte/Methoden/Eigenschaften mit fingierten und praktisch unsinnigen Beispielen hat, die jeweils ohne jegliche Wertung nur das Feature an sich nüchtern technisch vorstellen, *und* wenn man gleichzeitig keinen Teil der Dokumentation hat, der diese Fragmente zu sinnvollen Anwendungsbeispielen zusammenfügt und den ganzen in sich »dummen« Feature-Beschreibungen einen übergreifenden Sinn gibt.

Erklärt mir selfHTML eigentlich, dass man mit CSS sehr viel Unsinn machen kann, z.B. geringe Kontraste, unleserliche Spaltenbreite bei Fließtexten, überflüssige Hover-Effekte, chaoshafte Seiteneinteilungen und unübersichtlich Anordnungen oder einfach nur eine geschmacklose Gestaltung?

Nein, momentan hat SELFHTML in dem Punkt Lücken.

Was aber nicht heißt, dass SELFHTML nicht auf diese Problematiken hinweisen sollte. Wenn wir Gestaltung mit CSS vorstellen, ist es nur sinnvoll, dass wir auch ansprechen, was eine gute Gestaltung ausmacht und wie man die Teiltechniken geschickt kombinieren kann. Usability und Accessibility werden in SELFHTML 9 großen Raum einnehmen. Die Farbwahl, der Aufbau von Spaltenlayouts, der Einsatz von Effekten und die aufgeräumte, übersichtliche Seitenstruktur werden dabei sicher angesprochen werden.

Eine einfache, unpolemische Darstellung standardkonformer Techniken wäre angebracht.

Die wertfreie Darstellung von netten Zeitgenossen wie window.status und window.open hat wunderbaren JavaScript-Missbrauch in die Welt hinausgetragen, der uns auch noch übermorgen auf Webseiten nerven wird.

Wir wollen nicht positivistisch und wertfrei Techniken vorstellen. Das wollte SELFHTML noch nie, und das macht SELFHTML auch momentan nicht. Wieso sollte sich SELFHTML darauf begrenzen, Techniken vorzustellen, ohne die Sinnfrage zu stellen? Ich finde, das widerspricht unseren grundsätzlichen Auffassungen. SELFHTML will für einen kritischen und selbstbewussten Umgang mit Technik (»Energie des Verstehens«) stehen. Wieso sollte eine Didaktik sich darauf beschränken, einfach technische Möglichkeiten und der Technik innewohnende Regeln zu beschreiben? Wie kann man das Anleitung und Hilfe nennen? Soll es dem Leser eine augenscheinliche Freiheit geben, die Technik so zu nutzen, wie er es für richtig hält?

Es gibt nun einmal eine (Pseudo-)Wissenschaft, die sich über die nutzbringende und effiziente Technikverwendung Gedanken macht. Ein Lehrbuch, das die Erkenntnisse dieser Wissenschaft nicht der nüchternen Technik, für die es weder sinnhaft noch sinnwidrig gibt, entgegenstellt, bildet meiner Meinung nach keine kompetenten Anwender aus. Selbstbestimmt handelt höchstens derjenige, der sich wissentlich, aber nicht naiv, über Bedenken und Empfehlungen hinwegsetzt.

Was nun den Zusatz »standardkonforme Techniken« angeht, so verstehe ich ihn nicht. Standardisierung heißt noch längst nicht, dass man diese Techniken unreflektiert benutzen kann. Die Frage, wie und wozu man sie benutzen, stellt sich ebenso. Was die Darstellung von DOM Events angeht, so stimme ich dir zu, möchte aber einwenden, dass gerade in diesem Bereich Standardisierung ein Witz ist. Das letzte, was SELFHTML sein will, ist eine Kopie der W3C-DOM-Spezifikationen - die Sinnfrage beantworten diese sowieso nicht. Schau dir mal die wahrscheinlich beste Ressource weltweit dazu an, quirksmode.org, dort ist der Browser-Quirks das leitende Paradigma. Die Dokumentation der Event-Eigenschaften halte ich auch ohne Bezugnahme auf DOM Events für eine der besten - weil wir eben den Browser-Quirks detailliert untersucht haben. Es fehlen natürlich gewisse Methoden und Eigenschaften, die du wahrscheinlich meintest.

Mathias

[Heinzelhund]

Hallo,

Problematisch wird es, wenn man sechshundertunddreißig Objekte/Methoden/Eigenschaften mit fingierten und praktisch unsinnigen Beispielen hat, die jeweils ohne jegliche Wertung nur das Feature an sich nüchtern technisch vorstellen, *und* wenn man gleichzeitig keinen Teil der Dokumentation hat, der diese Fragmente zu sinnvollen Anwendungsbeispielen zusammenfügt und den ganzen in sich »dummen« Feature-Beschreibungen einen übergreifenden Sinn gibt.

Das ist sicherlich unwidersprochen richtig. Ich wollte damit auch nur ansprechen, dass das Verständnis eines Funktionsprinzips - zumindest mir persönlich - oftmals leichter fällt, wenn man ein möglichst eingegrenztes Beispiel hat, auch wenn dessen Gebrauch im täglichen Leben eher unwahrscheinlich ist.

Erklärt mir selfHTML eigentlich, dass man mit CSS sehr viel Unsinn machen kann, [...]

Nein, momentan hat SELFHTML in dem Punkt Lücken.

Was aber nicht heißt, dass SELFHTML nicht auf diese Problematiken hinweisen sollte. Wenn wir Gestaltung mit CSS vorstellen, ist es nur sinnvoll, dass wir auch ansprechen, was eine gute Gestaltung ausmacht  [...]

Auch hier gebe ich dir recht. Was aber im Zusammenhang mit JS auffällt, dass hier immer direkt auf dessen unsinnigen Gebrauch hingewiesen wird, andere Bereiche wie CSS diesen Reflex aber nicht auslösen. Ich kann mich noch sehr wohl an ein Blink-Tag erinnern (HTML!), das einfach nur als furchterregend zu bezeichnen war. Was heißen soll, dass man natürlich mit JS viel Unsinn machen kann, dies aber mehr an dem Script-Autoren liegt, als an der Sprache selbst. So wie ich dich verstanden habe, würdest du mir da aber wohl auch zustimmen.

Eine einfache, unpolemische Darstellung standardkonformer Techniken wäre angebracht.

Die wertfreie Darstellung von netten Zeitgenossen wie window.status und window.open hat wunderbaren JavaScript-Missbrauch in die Welt hinausgetragen, der uns auch noch übermorgen auf Webseiten nerven wird.

'window.status' war definitiv ein bereits in der Sprache angelegter Fehler; 'window.open' wurde missbraucht. Aber da haben sich moderne Browser ja gegen zu wehren gewusst. Möchte ich heute ein PopUp-Fenster öffnen, muss dies schon einen gehörigen Nutzen haben, damit ich dem Anwender erklären kann, dass er dies zulässt. Firefox unterbindet hier auf Wunsch auch das Ausblenden der Statusleiste. IE7 soll wohl demnächst auch die Adressleiste stets eingeblendet lassen. Dass JS für Werbung genutzt wird, kann nicht generell als negativ für aktive Inhalte ausgelegt werden. Zum einen finanziert sich ein Großteil des Netzes durch Werbung (auch wenn sie nervt) und zum anderen kann man auch bei einer MarkUp-Sprache serverseitig sagen, dass beispielsweise bei jedem dritten Anklicken eines Links einer Seite statt dem eigentliche Ziel zunächst eine HTML-Seite mit Werbung übertragen wird. Eine solche zwischengeschaltete HTML-Seite wäre nicht weniger nervig als ein PopUp-Fenster.

Wir wollen nicht positivistisch und wertfrei Techniken vorstellen. Das wollte SELFHTML noch nie, und das macht SELFHTML auch momentan nicht. Wieso sollte sich SELFHTML darauf begrenzen, Techniken vorzustellen, ohne die Sinnfrage zu stellen? Ich finde, das widerspricht unseren grundsätzlichen Auffassungen. SELFHTML will für einen kritischen und selbstbewussten Umgang mit Technik (»Energie des Verstehens«) stehen. [...]

Hier stimme ich dir durchaus zu, würde aber analog zum journalistischen Grundsatz Meldung und Kommentar voneinander trennen. Also zunächst wie gehabt die Funktionalität erklären und im folgenden Text, genauso wie hier auch auf unterschiedliche Browserfähigkeiten eingegangen wird, bei bekannten 'problematischen' Aspekten einer Funktionalität darauf hinweisen. Wenn der Leser die Technik verstanden hat, dann kann er sie und ihren Einsatz auch besser beurteilen.

Es gibt nun einmal eine (Pseudo-)Wissenschaft, die sich über die nutzbringende und effiziente Technikverwendung Gedanken macht. Ein Lehrbuch, das die Erkenntnisse dieser Wissenschaft nicht der nüchternen Technik, für die es weder sinnhaft noch sinnwidrig gibt, entgegenstellt, bildet meiner Meinung nach keine kompetenten Anwender aus. Selbstbestimmt handelt höchstens derjenige, der sich wissentlich, aber nicht naiv, über Bedenken und Empfehlungen hinwegsetzt.

Dies sind jedoch eher Überlegungen grundsätzlicher Natur und gehören m.E. an den Anfang oder das Ende eines technischen Textes. Hier müsste man sicherlich auf die Problematik von Textreadern und Suchmaschinenlesbarkeit eingehen. Auch der sinnhafte Einsatz aktiver Seiteninhalte gehört m.E. hier besprochen.

Die meisten der Punkte zum 'Unobtrusive JavaScript' halte ich übrigens für ein Script für selbstverständlich. Andernfalls funktioniert es nicht fehlerfrei.

zu Punkt 1: Man darf sich im Web für elementare Dinge nicht ausschließlich auf JS verlassen. Insbesondere nicht bei der Erreichbarkeit von Seiteninhalten. (Hier sind aus wirtschaftlichen Überlegungen die Suchmaschinen sicherlich noch das wichtigste Argument.)

zu Punkt 2: Scripte, die fortwährend Fehlermeldungen erzeugen, funktionieren nicht, auch wenn diese nicht mehr defaultmäßig angezeigt werden. Ein Testen auf die Verfügbarkeit eines Objektes sollte auf die 'Unsicheren' begrenzt sein.

zu Punkt 3 (auch zu deiner Bemerkung zu Standards): Da man sich nach dem Schreiben nicht tottesten kann, sind Standards die einzige Möglichkeit, 'robuste' Scripte zu schreiben. Es ist schier nicht möglich, auf allen Browsern, Rendering-Engines oder allen Betriebssystemen mit all ihren jeweiligen Updates zu testen.

zu Punkt 4: Aus wirtschaftlichen Erwägungen bei vielen Anwendungen oftmals nicht möglich. Man sollte sich bewusst sein, dass (zumindest bei gewerblichen Einsatz) dies auch immer irgend ein Auftraggeber bezahlen muss. Und der durchschnittliche Privatanwender (natürlich mit Ausnahmen) fürchte ich, wird sich über solche 'philosophische' Aspekte leider überhaupt keine Gedanken machen.

zu Punkt 5: Technisch sehr aufwendig und für die Meisten wahrscheinlich gar nicht umsetzbar.

Was nun den Zusatz »standardkonforme Techniken« angeht, so verstehe ich ihn nicht. Standardisierung heißt noch längst nicht, dass man diese Techniken unreflektiert benutzen kann. Die Frage, wie und wozu man sie benutzen, stellt sich ebenso.

s.oben.

Was die Darstellung von DOM Events angeht, so stimme ich dir zu, möchte aber einwenden, dass gerade in diesem Bereich Standardisierung ein Witz ist.

Ja, man wird das Gefühl nicht ganz los, die wüssten selbst nicht genau, was die da wollen ...

[...] Die Dokumentation der Event-Eigenschaften halte ich auch ohne Bezugnahme auf DOM Events für eine der besten - weil wir eben den Browser-Quirks detailliert untersucht haben. Es fehlen natürlich gewisse Methoden und Eigenschaften, die du wahrscheinlich meintest.

Das an diesem Kapitel mittlerweile der Zahn der Zeit genagt hat, liegt aber auch an der 'standardlosen' Zeit. Auch dies ist ein Vorteil von Standards (auch wenn sie für sich unsinnig sein sollten), dass technische Beschreibungen nicht andauernd umgeschrieben werden müssen.

Ciao
Heinzelhund

P.S.: Mir ist übrigens klar, dass du nichts generell gegen Standards gesagt hast ;-)

[wahsaga]

hi,

wenn wir schon "ketzerisch" sein wollen, dann üben wir uns doch auch gleich noch ein wenig in Pedanterie bzw. im Korinthenkacken:

Was ist ein sinnvoller Einsatz für JS?
1 + 1 = x

Das kann gar kein "sinnvoller Einsatz für JS" sein, weil das in JS nicht funktioniert™.

Im obigen Beispiel würde eine einfache Alertbox mit der Zahl 2 ausreichen.

Einen Screenshot einer zugehörigen Fehlermeldung fände ich passender.

gruß,
wahsaga

[Heinzelhund]

Hallo,

Was ist ein sinnvoller Einsatz für JS?
1 + 1 = x

Das kann gar kein "sinnvoller Einsatz für JS" sein, weil das in JS nicht funktioniert™.

Ok, das war natürlich kein JS-Code sondern eine sinnvolle (mathematische) Aufgabenstellung für ein Script. Es wird mir niemand erklären können, wie ich so eine Aufgabenstellung ohne ein Script clientseitig lösen kann. Was heißen soll: JS ist mehr, als lediglich ausgewechselte Grafiken für Button.

Ciao
Heinzelhund

[peterS.]

Gruss Mathias,

ich habe von Dir sowohl im Weblog als auch im Forumsthread gestellte Fragen
einfach wild zusammengeklaubt und versuche nun schreibenderweis mal meine
Gedanken zu ordnen.

Eine der offenen Fragen ist die grundsätzliche Aufgabe und Rolle, die
JavaScript in der Webgestaltung spielen soll, und wie SELFHTML 9 dies
vermitteln soll.

Was ist sinnvoller JavaScript-Einsatz und welche Auffassung
vertritt SELFHTML?

Im Eröffnungs-Posting des Forumsthreads hast Du schon alle die Oberfläche
betreffenden Anwendungsbereiche genannt. Im Sinne eines defensiven
Programmieransatzes hast Du auch gleich noch das Stichwort "unobtrusive"
mit ins Spiel gebracht und die Kandidaten diesen Kriterien entsprechend
schon mal grob vorsortiert.

Für die neuen JavaScript-Kapitel wünsche ich mir, daß sowohl defensiver
Programmieransatz, als auch assistive/unterstützende, bereichernde/
"aufhübschende" Oberflächentechniken der "unobtrusive"-Schule als guter
Stil vor allem in den Beispielen vorgelebt werden.
Ein paar einführende kurze nicht polemisierende Sätze reichen meiner
Meinung nach vollkommen aus, um in jedermans Kopf zwei Gedankenpflöcke
zu schlagen und dazwischen diese Richtschnur zu spannen. Wer um die Regeln
weiß und diese nicht als Dogma, sondern als Anregung zum Selberdenken
begreift, wird sie gegebenenfalls auch ohne Bauchschmerzen zurechtbiegen
oder brechen können.

Wenn man sich das jetzige JavaScript-Kapitel ansieht, so fehlt ein klarer
theoretischer Unterbau, der dem Leser sinnvolle Anwendungsgebiete nennt
und entsprechende konkrete Beispiele vorstellt.

Welche konkreten Anwendungsbereiche von Javascript gibt es?
Wie kann sich dies im Aufbau des JavaScript-Kapitels niederschlagen?

Das Thema JavaScript sollte breit aufgefächert werden, um den vielen
möglichen Ansätzen, sich in diese Materie einzuarbeiten, möglichst gerecht
zu werden.

Ich plädiere daher für folgende Struktur:

• Der Sprachkern

Dort sollte man sich unbedingt am Sprachkern nach "Standard ECMA-262
    3rd Edition - December 1999" abarbeiten. Auch die wenigen guten
    deutschsprachigen Bücher, deren jeweiliger Aufbau sich tatsächlich
    an den in diesem Dokument beschriebenen Sprachkern anlehnt, schaffen
    es meiner Ansicht nach nicht ganz, die Stärken dieser Sprache aus dem
    Verborgenen zu holen und angemessen zu beleuchten.
    Also ist es wichtig, genau an dieser Stelle über die Sonderstellung
    von "Object" und "Function" und deren Zusammenspiel im OO-Konzept von
    JavaScript/ECMAScript aufzuklären. Dort angelangt darf man sich auch
    gleich den unorthodoxen Vererbungsmöglichkeiten und dem dieser Vielzahl
    zugrundeliegenden Prototypenkonzept widmen, wobei man dann auch gleich
    etwas zur speziellen Art der Kapselung und zu "Closure"s im Allgemeinen
    sagen muss.

• Der "Scripting Host" und seine Objekte

- Objekte, die von allen gängigen Browsern unterstützt werden
      (window, document, location, history, navigator, screen)...
    - ...und deren Inkonsistenzen.

An dieser Stelle darf dann auch darauf hingewiesen werden, daß sich in
    der Praxis sinnvolle Anwendungen meist auf "location" und "document"
    beschränken, womit zum nächsten Kapitel übergeleitet werden kann.

• JavaScript und DOM-Zugriff

Ich bin mir nicht sicher, wo, wie und in welchem Umfang das Kapitel "DOM"
    abgehandelt werden soll. Zumindest DOM-spezifisches Scripting sollte hier
    mit reingepackt werden, damit man dann gleich übergehen kann zu:

• JavaScript im Kontext von "DHTML"

also: JavaScript + DOM + CSS.

• JavaScript im Kontext von "AJAX"

also: XMLHttpRequest + DHTML,
    oder eben auch nur: JavaScript + XMLHttpRequest + DOM.

andere Namensgebungsversuche:
      - RIAs/Rich Internet Applications(Macromedia),
      - DHTTP(David Flanagan)

• Die Schulen des Scriptings

An dieser Stelle würde ich zuerst einmal nur auf Arbeitsgrundlagen wie
    - "Type Detection" (Sprachkern),
    - "Object Detection vs. Browser Sniffing" (Scripting Host) sowie
    - Weakleys Schichten-/Ansichten-Modell eingehen.
    Verständnis und Anwendung dieser Grundlagen führen fast schon automatisch
    zu ähnlichen, wenn nicht gar gleichen Arbeits- und Sichtweisen, wie sie in
    den Konzepten von "Graceful Degradation", "Unobtrusive JavaScript" und
    "Progressive Enhancement" beschrieben werden.

Mit einem Blick auf die vorgeschlagene Gliederung, läßt sich feststellen, daß
diese dem Entwicklungsprozess der in heutigen Browsern verfügbaren Technologien
folgt und aus ebendiesem Grund auch die 4. (JavaScript und DOM) und 3. (DHTML)
"Ansicht" nach Weakley abdeckt.

Ajax – ein Sonderfall der JavaScript-Anwendung?

Aus JavaScript-Perspektive sind "AJAX"-Anwendungen keineswegs Sonderfälle.
Alle in der Zeit vor "XMLHttpRequest" und "XML Save And Load" eingesetzten
Techniken für "hidden request"s bestätigen im nachhinein ja nur das schon
seit Jahren existierende Bedürfnis nach einer mächtigeren Schnittstelle für
Webapplikationen.
Zum Sonderfall wird "AJAX" aus dokumentenzentrierter Sicht, da es den
Weakleyschen Behavior-Layer der dritten und vierten Ansicht um die Möglichkeit
von außen nachladbarer Daten und Prozesslogik erweitert.
Ein voll ausgereiztes "request/response"-Objekte benutzt sein ansonsten
vollkommen leeres Dokument nur noch als Container für den Startprozess einer
durchaus komplexen Internet Anwendung.
Vom Konzept "Hypertext als Bindeglied zwischen Dokumenten" bleibt dann nichts
mehr übrig. Und doch sind solche Anwendungen völlig legitim.

Kennt ihr weitere (Anwendungs)Bereiche (von JavaScript) oder lassen sich
die Scripte, die ihr für besonders nützlich und beispielhaft erachtet,
bereits in diese Bereiche einordnen?

Du hast, glaube ich, alle Bereiche genannt. Den von Dir gewünschten
Beispielzoo sinnvoller Anwendungen möchte ich nur um das
"S5"-Präsentationsframework vom Team hinter Eric Meyer bereichern.
"Simple Standards-Based Slide Show System" fällt dann unter die Kategorien
"Outcome 3" und "Unobtrusive".

Gute Nacht - peterS. - [e-mail]

[Stephan Klofat]

Hallo,

ich würde das Thema Javascript anders angehen.
Genauso wie niemand weiß wie in 2(zwei) Jahren die meisten Browser und Clients HTML-XHTML-XML unterstützen werden, noch wie es mit css2 gerade im Bereich Sprachausgabe und den anderen @media weitergeht, kann man auch nur schwer sagen wie der Einsatz von JavaScript/JScipt in Zukunft laufen wird.
Bei Selfhtml war ich mit dem bisherigen Kapitel über JavaScript zufrieden, weil es eben eine (sehr) gut strukturierte Referenz in deutsch war, mit simplen Beispielen.

Folgende Einteilung würde mir am besten gefallen.
1. Einleitung, die auf alle Glaubensfragen eingeht und die schwere Stellung von JavaScript in der Web-Designer-Welt vorstellt.
2. Die theoretische Grundlage mit dem ISO-Standart ECMAScript kurz anreissen.
3. Eine wohl überlegte komplette wertfreie (ohne meinungsgedösel) Referenz aller Objekte, Funktionen und Kontrollfunktionen. Hier auch die Unterschiede der verschiedenen Browser beleuchten.
4. Eine Referenz in Kurzform die als Einstieg gedacht ist querverlinkt zu 3. ist und mit sinnvollen Erläuterungen und Beispielen.

So findet der "poweruser" wie ich schnell und neutral seine Parameterliste zu window.open, während ein Neuling eben eine ausführliche Erklärung zu diesem Thema, mit dem Hinweis auf Popupblocker usw findet.

Das ganze mit den verschiedenen Bereichen des Einsatzes ist für mich schlicht populistisch in welcher Form auch immer.
Hier muss auf ganz anderer Stelle sensibilisiert werden: Zielgruppe!
Wenn eine Seite eben für normale Leute mit XP/IE gemacht wird, dann reicht es aus wenn sie den relevanten Seiteninhalt im HTML hat für Suchmaschinen und Links zugänglich sind. Hier noch zwischen "bösen" und "guten" scripts zu unterscheiden ist eher Religion.
Bei großen Seiten die alle Arten von Nutzern haben, weiß niemand ob in 3 Jahren auf jeden neuem Handy vielleicht eine neue Scriptsprache von Adobe(Macromedia) plötzlich ganz hip und trendy ist.

Und bei einer Einteilung in Unobtrusive/Obtrusive gibt jemand der sich nicht mit dem Glaubenskrieg der Accessibility/Usability-Jünger auskennt nur Rätsel auf. Daher auf diese Einteilung bitte verzichten und dies geschickt verpacken bei den Beipielen.

[molily]

Hallo,

Genauso wie niemand weiß wie in 2(zwei) Jahren die meisten Browser und Clients HTML-XHTML-XML unterstützen werden, noch wie es mit css2 gerade im Bereich Sprachausgabe und den anderen @media weitergeht, kann man auch nur schwer sagen wie der Einsatz von JavaScript/JScipt in Zukunft laufen wird.

Wenn wir uns auf die gegenwärtige Anwendung spezialisieren, bleiben mögliche zukünftige Bereiche außen vor. Zukunftsprognosen sind allerdings auch problematisch. Wenn man willkürlich gewisse Techniken auf Verdacht dokumentiert, nur weil sie irgendwann zu irgendeinem Zweck gebraucht werden könnten, filtert man genauso.

SELFHTML ist immer Ausdruck seiner Zeit. Genauso wie SELFHTML 8.1.1 nicht durchgängig die Gegenwart und nahe Zukunft abdeckt, kann SELFHTML 9 nicht bis 2010 gültig sein.

Experimentelle Neuerungen im Bereich JavaScript sollen dennoch angesprochen werden, allerdings ohne die Bodenhaftung zu verlieren. So etwas war ein Schuss in den Ofen. Datenanbindung mit XMLHttpRequest hingegen wurde zum Star. Wer konnte es ahnen?

Folgende Einteilung würde mir am besten gefallen.

1. Einleitung, die auf alle Glaubensfragen eingeht und die schwere Stellung von JavaScript in der Web-Designer-Welt vorstellt.
2. Die theoretische Grundlage mit dem ISO-Standart ECMAScript kurz anreissen.
3. Eine wohl überlegte komplette wertfreie (ohne meinungsgedösel) Referenz aller Objekte, Funktionen und Kontrollfunktionen. Hier auch die Unterschiede der verschiedenen Browser beleuchten.
4. Eine Referenz in Kurzform die als Einstieg gedacht ist querverlinkt zu 3. ist und mit sinnvollen Erläuterungen und Beispielen.

Nunja, diese Einteilung weicht wenig von der bisherigen ab, wir sind im Grunde bereits soweit. Bis auf die Beschreibung der Stellung von Javascript und die Kurzreferenz.

So findet der "poweruser" wie ich schnell und neutral seine Parameterliste zu window.open

Solange wir window.open dokumentieren, wird das auch der Fall sein, Parameterlisten können weder neutral noch nicht neutral sein.

während ein Neuling eben eine ausführliche Erklärung zu diesem Thema, mit dem Hinweis auf Popupblocker usw findet.

Naja, was ist Meinungsgedösel und was nicht? Ist der Hinweis auf Popupblocker eindeutig neutral, der Hinweis auf die Einschränkungen von window.open() im Tabbed-Browsing-Zeitalter hingegen Meinungsgedösel?

Wenn ich window.open() dokumentieren müsste, kann ich das nicht einfach nur die Theorie ansprechen. window.open() hat in verschiedenen Browsern unterschiedliche Auswirkungen, ich habe dazu letztens ein längeres Posting geschrieben. Ist eine Schilderung dieser Fallstricke schon Meinungsgedösel? Es sind erst einmal nüchterne Feststellungen, die daraus erwachsen, dass Webautoren window.open() verwenden und sich wundern/ärgern, dass es nicht wie beabsichtigt (d.h. wie momentan dokumentiert) funktioniert. Diese Probleme sind Fakten, sie werden uns von SELFHTML-Nutzern berichtet. Selbst wenn SELFHTML nicht als Ort dafür benutzt wird, auf Basis dieser Fakten Meinungen zu vertreten, so fürchte ich, dass manche eine lückenlose Dokumentation der Browser- und Einstellungsunterschiede schon als Meinungsgedösel ansehen.

Das ganze mit den verschiedenen Bereichen des Einsatzes ist für mich schlicht populistisch in welcher Form auch immer.

Was bedeutet hier »populistisch«? Wir wollen niemanden für uns gewinnen.

Hier muss auf ganz anderer Stelle sensibilisiert werden: Zielgruppe!
Wenn eine Seite eben für normale Leute mit XP/IE gemacht wird, dann reicht es aus wenn sie den relevanten Seiteninhalt im HTML hat für Suchmaschinen und Links zugänglich sind.

Was bedeuten das? Wenn man »normale Leute mit XP/IE« zum Maßstab erhebt, braucht man in keiner Hinsicht über Technik zu reflektieren, sondern »optimiert« einfach und fertig.

Hier noch zwischen "bösen" und "guten" scripts zu unterscheiden ist eher Religion.

Das ist, mit Verlaub, blöde Polemik und wischt jeden Fortschritt im Bereich JavaScript seit dem Webstandards-Umbruch vom Tisch.
Wer moralisiert hier? Es sind nüchtern streitbare Fragen, die sich um technische Effizienz drehen, um benutzerfreundliche Websites, um zugängliche Inhalte.

Und bei einer Einteilung in Unobtrusive/Obtrusive gibt jemand der sich nicht mit dem Glaubenskrieg der Accessibility/Usability-Jünger auskennt nur Rätsel auf. Daher auf diese Einteilung bitte verzichten und dies geschickt verpacken bei den Beipielen.

Du magst die Themen Accessibility und Usability für nichtig und praktisch irrelevant halten - selbst wenn das verbreitete Ansicht ist, wieso soll SELFHTML diese Position auch noch verbreiten, die sich ziemlich desinteressiert an einem umfassenden Verständnis zeigt? Ist das wirklich alles nur heiße Luft, was in solchen Diskussionen produziert wird? Ich denke nicht.

Bei den Beispielen sollte es schon eine thematische Trennung geben, zumindest in deren Beschreibungen. Ob ein Script wie immer geartet abwärtskompatibel ist oder als reine JavaScript-Anwendung für sich steht, ist durchaus relevant. Was natürlich nicht heißt, dass man abstrakte Theorien zur Beschreibung heranziehen sollte, da stimme ich dir zu. Ich denke, das hatte auch niemand im Sinn - diese Einteilungen sollen einem lediglich technische Möglichkeiten und Probleme vor Augen führen. Und zumindest dazu taugen sie m.E. auf jeden Fall.

Mathias

[at]

Hallo.

Solange wir window.open dokumentieren, wird das auch der Fall sein, Parameterlisten können weder neutral noch nicht neutral sein.

Sondern?
MfG, at

[molily]

Solange wir window.open dokumentieren, wird das auch der Fall sein, Parameterlisten können weder neutral noch nicht neutral sein.

Sondern?

Das ist unglücklich formuliert. Ich meinte damit, dass es nichts sagt, eine »neutrale Parameterliste« zu fordern. Wir werden in Parameterlisten, die für sich genommen immer neutral sind, nichts hineinmischen, sonst wären sie keine bloßen Parameterlisten mehr.

Mathias

[at]

Hallo.

Ich meinte damit, dass es nichts sagt, eine »neutrale Parameterliste« zu fordern. Wir werden in Parameterlisten, die für sich genommen immer neutral sind, nichts hineinmischen, sonst wären sie keine bloßen Parameterlisten mehr.

Ah, danke, ich verstehe.
MfG, at

[Alex alias trixta]

hi,

fand den artikel sehr gut. ich bin nicht der meinung, dass selfhtml javascript nur mit sinnvollen beispielen erklären sollte (besser gesagt muss). als referenz und zum lernen taugen die beispiele sehr gut. es reicht letztendlich ein entsprechender hinweis am anfang zum js-kapitel.

zum sinnvolle einsatz von js:
kein js oder js mit fallback
grundsätzlich sollte auf javascript dann verzichtet werden, wenn inhalte bereitgestellt werden (bsp.: (popup-)link zur nächsten seite). soll dagegen unbedingt ein popup geöffnet werden (manchmal ist das ja sinnvoll), kann man den entsprechenden link einfach mit ner css-klasse auszeichnen und dann mit javascript alle links mit dieser klasse modifizieren. (ähnlich aber das js steckt bereits im link: http://www.barrierefreies-webdesign.de/knowhow/pop-up-fenster/index.php)

js ohne alternative
javascript ist dann sinnvoll, wenn keine inhalte, sondern zusätzliche features bereitgestellt werden (zum beispiel: merkliste für artikel mit hilfe von js und cookies).

einbindung von js:
zu dem im artikel vorkommenden hinweis zum "barrierefreien js".
ich bin nicht der meinung, dass js nur so eingebunden werden darf (also kein einziger javascript befehl im html-body). grundsätzlich ist diese vorgehensweise zwar sehr schön (ich meine der html code sieht schön aus) und manchmal auch effizienter. man kann aber auch mit ganzen js-bereichen im body und erst recht mit onclick in links und so arbeiten, ohne dass das wirklich i.S.d. barrierefreiheit stört (siehe nur den link oben zu den links im neuen fenster). wichtig ist hierbei jedoch, dass der user ohne javascript nichts davon merkt (man siehe nur die vielen webseiten mit normalen links zum zurückspringen und zum drucken, welche zwar ohne js angezeigt werden, aber nicht funktionieren). kurz gesagt: der coder und skripter sollte immer erst nachdenken wie er was macht und seine seiten komplett mit ausgeschaltetem js testen.

[Jeena Paradies]

Hallo,

Woran ich zur Zeit wirklich ganz hart knacken muss ist objektorientierte Programmierung in JavaScript. Ich finde irgendwie keie sinnvollen Texte, die einem den Einstieg da irgendwie erleichtern. Zum Beispiel finde ich keine Erklärung zur Vererbung und auch nicht zum Unterschied zwischen Objekteigenschaft und einer Variable die innerhalb des Objektes definiert wird. Auch suche ich nach informationen was mit funktionen passiert, die innerhalb einer methote definiert werden und wie die auf andere methoden, eigenschaften und variablen zugreifen können.

Hier noch drei Beispiele die ich von Daniel aus dem #selfhtml Chat bekommen habe, die sich um das mit den Objekteigenschaften und variablen drehen und die ich (noch) nicht verstehe:

function obj1() {  
    this.abc = "123";  
    this.bla = function() {  
        alert(this.abc)  
    }  
};  
  
var a = new obj1();  
var b = a.bla;  
b();

function obj1() {  
    this.abc = "123";  
    this.bla = function() {  
        alert(this.abc)  
    }  
};  
  
var a = new obj1();  
a.bla();

function obj1() {  
    var abc = "123";  
    this.bla = function() {  
        alert(abc)  
    }  
};  
  
var b = a.bla;  
b();  
var a = new obj1();

Dieses Themengebiet fehlt in SELFHTML < 9 völlig und sollte auf jeden Fall behandelt werden, da es vor allem auf Deutsch anscheinend zumindest online keine entsprechenden Texte gibt und auf englisch habe ich sie auch noch nciht gefunden.

Grüße
Jeena Paradies

[Christian Seiler]

Hallo Jeena,

Dieses Themengebiet fehlt in SELFHTML < 9 völlig und sollte auf jeden Fall behandelt werden, da es vor allem auf Deutsch anscheinend zumindest online keine entsprechenden Texte gibt und auf englisch habe ich sie auch noch nciht gefunden.

Christians JavaScript-Artikel kennst Du aber?

Viele Grüße,
Christian

[Jeena Paradies]

Hallo,

Christians JavaScript-Artikel kennst Du aber?

Ähm jain, also ich habe den ganz am Anfang durchgelesen, war meine erste anlaufstelle als ich angefangen habe mich mit OOP un JS zu beschäftigen. Allerdings habe ich da kein einziges Wort verstanden was der CK da geschrieben hat, es hat mir also gar nichts genützt.

Mittlerweile habe ich durch ewiges nachfragen im Chat und hier und Lesen in verschiedenen anderen Artikeln ein wenig Wissen darüber gesammelt, so dass ich -- nachdem ich den Artikel jetzt noch einmal gelesen habe -- ihn zumindest zu 50% verstehe (glaube ich). Aber so richtig alle Fragen beantwortet er mir nicht.

Grüße
Jeena Paradies

[Struppi]

Woran ich zur Zeit wirklich ganz hart knacken muss ist objektorientierte Programmierung in JavaScript. Ich finde irgendwie keie sinnvollen Texte, die einem den Einstieg da irgendwie erleichtern. Zum Beispiel finde ich keine Erklärung zur Vererbung und auch nicht zum Unterschied zwischen Objekteigenschaft und einer Variable die innerhalb des Objektes definiert wird.

Vererbung ist in JS ein kritisches Thema, weil es teilweise anders funktioniert als in anderen Sprachen (s. auch den Artikel von Douglas Crockford).

Auch suche ich nach informationen was mit funktionen passiert, die innerhalb einer methote definiert werden und wie die auf andere methoden, eigenschaften und variablen zugreifen können.

Das ist IMHO zu fortgeschritten für selfHTML. Da sich in erster Linie darum dreht, wie man in JS private, public und privilegierte Objektmitgliedern nachbaut.

Hier noch drei Beispiele die ich von Daniel aus dem #selfhtml Chat bekommen habe, die sich um das mit den Objekteigenschaften und variablen drehen und die ich (noch) nicht verstehe:

function obj1() {

this.abc = "123";
    this.bla = function() {
        alert(this.abc)
    }
};

var a = new obj1();
var b = a.bla;
b();

  
Du erzeugst ein Objekt und weist die Funktionsreferenz einer Memberfunktion b zu, durch anhängen der Klammer wird diese aufgerufen. Bei mir kommt undefined.  
  
Das hat aber mit OO nichts zu tun. Das ist das Gleiche wie:  
var b = alert;  
b('test');  
  
  

>   
> ~~~javascript

function obj1() {  

>     this.abc = "123";  
>     this.bla = function() {  
>         alert(this.abc)  
>     }  
> };  
>   
> var a = new obj1();  
> a.bla();

Was ist hier unklar?

function obj1() {

var abc = "123";
    this.bla = function() {
        alert(abc)
    }
};

var b = a.bla;
b();
var a = new obj1();

  
Das geht nicht.  
Wenn es darum geht, warum abc undefined ist, da du kein this davor stehen hast, ist die Variabel jetzt im Geltungsbereich window also window.abc  
  

>   
> Dieses Themengebiet fehlt in SELFHTML < 9 völlig und sollte auf jeden Fall behandelt werden, da es vor allem auf Deutsch anscheinend zumindest online keine entsprechenden Texte gibt und auf englisch habe ich sie auch noch nciht gefunden.  
  
Ich halte das für z.T. fortgeschrittene Programmierung. Dann müßte auch in Perl dieses Thema wesentlich weiter erläutert werden. Aber ich denke selfHTML will und kann das nicht bieten.  
  
Struppi.

-- 
[Javascript ist toll](http://javascript.jstruebig.de/)

[Jeena Paradies]

Hallo,

Vererbung ist in JS ein kritisches Thema, weil es teilweise anders funktioniert als in anderen Sprachen (s. auch den Artikel von Douglas Crockford).

Ja, den werde ich mir jetzt mal näher betrachten, finde aber dass zumindest die Grundzüge unbedingt in SELFHTML beschrieben werden sollten. Wenn man es jetzt liest bekommt man den Eindruck JS wäre keine OO Sprache, zumindest bekam ich den Eindruck am Anfang.

Auch suche ich nach informationen was mit funktionen passiert, die innerhalb einer methote definiert werden ...
Das ist IMHO zu fortgeschritten für selfHTML. Da sich in erster Linie darum dreht, wie man in JS private, public und privilegierte Objektmitgliedern nachbaut.

Hm ja da könntest du recht haben.

function obj1() {

this.abc = "123";
    this.bla = function() {
        alert(this.abc)
    }
};
var a = new obj1();
a.bla();

> Was ist hier unklar?  

Es war gestern wohl einfach nur zu spät am Abend, so dass mein Gehirn blokiert hatte.  
  

> > ~~~javascript

function obj1() {  

> >     var abc = "123";  
> >     this.bla = function() {  
> >         alert(abc)  
> >     }  
> > };  
> > var b = a.bla;  
> > b();  
> > var a = new obj1();

Das geht nicht.
Wenn es darum geht, warum abc undefined ist, da du kein this davor stehen hast, ist die Variabel jetzt im Geltungsbereich window also window.abc

Sie wird doch aber als lokale Variabel in der funktion obj1() definiert, irgendwie ist es manchmal so dass man auf sie zugreifen kann und manchmal nicht. Wann welcher Fall Auftritt konnte ich noch nicht nachvollziehen.

Ich halte das für z.T. fortgeschrittene Programmierung. Dann müßte auch in Perl dieses Thema wesentlich weiter erläutert werden. Aber ich denke selfHTML will und kann das nicht bieten.

Sicher, einige Sachen davon bestimmt, aber grundsätzliches über oo in JS könnte man doch in einem eigenen Kapitel aufnehmen. Ich denke für viele ist SELFHTML die erste Anlaufstelle bei so etwas und dann wird es in der Dokumentation nicht einmal erwähnt. Vielleicht würde es ja auch schon ausreichen Christians Artikel etwas Einsteigerfreundlicher zu gestalten und dort auch die Verwendeten Begriffe erklären.

Grüße
Jeena Paradies

[Struppi]

Wenn es darum geht, warum abc undefined ist, da du kein this davor stehen hast, ist die Variabel jetzt im Geltungsbereich window also window.abc
Sie wird doch aber als lokale Variabel in der funktion obj1() definiert, irgendwie ist es manchmal so dass man auf sie zugreifen kann und manchmal nicht. Wann welcher Fall Auftritt konnte ich noch nicht nachvollziehen.

Oh, das hatte ich übersehen.

Also:
function obj1() {
     var abc = "123";
     this.bla = function() {
         alert(abc)
     }
};

obj.bla() ist hier eine privilegierte Funktion, die auf das private Attribut abc zugreifen kann. Warum das manchmal nicht der Fall ist kann ich dir nicht sagen, es sollte immer klappen.

.... Ich denke für viele ist SELFHTML die erste Anlaufstelle bei so etwas und dann wird es in der Dokumentation nicht einmal erwähnt. Vielleicht würde es ja auch schon ausreichen Christians Artikel etwas Einsteigerfreundlicher zu gestalten und dort auch die Verwendeten Begriffe erklären.

Vielleicht.
Aber wie gesagt dann muss man sich auch überlegen ob man Perl nicht intensiver bespricht. Das ganze ist ja letztlich nur ein Möglichkeit um mit JS anspruchsvoller zu programmieren, für 99% der Fälle reicht es aus zu Wissen das es Objekte gibt und wie man sie benutzt (falls man mal ein externes nutzen will). Zumal man ja für OOP auch eine gewisse "Ideologie" benötigt. Und da sind die entsprechenden Tuts für Java oder C++ wesentlich präziser. Ich würde niemand empfehlen JS als Einstieg für OOP zu nehmen (genauso wenig wie Perl).

Struppi.

[Daniel Thoma]

Hallo Struppi,

Ich halte das für z.T. fortgeschrittene Programmierung. Dann müßte auch in Perl dieses Thema wesentlich weiter erläutert werden. Aber ich denke selfHTML will und kann das nicht bieten.

SELFHTML hat ja auch den anspruch HTML oder CSS vollständig zu dokumentieren, warum nicht JS?
Ich halte das durchaus für sinnvoll. Bei PHP, Perl usw. ist es sicher ausreichend, einen kurzen Überblick anzubieten. Es gibt ja auch viele andere Technologien für den Server und die Serverseite ist auch kein Schwerpunkt von SELFHTML.
JS ist aber die einzige, praktisch einsetzbare Programmiersprache für die Client-Seite und es wird da ja auch schon sehr viel davon dokumentiert.
Es geht hier auch nicht um die Dokumentation irgendwelcher Zusatzfunktionen von Gecko oder IE, sondern um ganz grundlegende Spracheigenschaften. Die sollten schon dokumentiert sein.
Ich persönlich hasse Dokumentationen, die mir so einen schwammigen Überblick geben, aber nicht wirklich verraten, wie die Dinge funktionieren. Man hat dauernd das Gefühl, da wird versucht, etwas zu verheimlichen, damit man nicht auch so gut wird, wie die, die das geschrieben haben ;-)

Zu diesem Beispiel:

  
function obj1() {  
    this.abc = "123";  
    this.bla = function() {  
        alert(this.abc)  
    }  
};  
  
var a = new obj1();  
var b = a.bla;  
b();  

Damit wollte ich Jeena veranschaulichen, wie eigentlich die Bindung von Methoden an Objekte funktioniert.
Dass der Funkionsaufruf b() nicht mehr im Kontext des in a gespeicherten Objektes arbeitet, ist nicht unbedingt natürlich.
Die Bindung passiert eben nicht bei der Deklaration der Methode, sondern erst beim Aufruf. Es kommt darauf an, über eine Referenz auf welches Objekt die Methode aufgerufen wurde.

Grüße

Daniel

[Struppi]

Ich halte das für z.T. fortgeschrittene Programmierung. Dann müßte auch in Perl dieses Thema wesentlich weiter erläutert werden. Aber ich denke selfHTML will und kann das nicht bieten.
SELFHTML hat ja auch den anspruch HTML oder CSS vollständig zu dokumentieren, warum nicht JS?

Keine Ahnung, aber ich würde es so sehen, dass es hier um spezielle Programmiertechniken geht, die man ohne eine gewissen Erfahrung gar nicht verstehen kann.

Es geht hier auch nicht um die Dokumentation irgendwelcher Zusatzfunktionen von Gecko oder IE, sondern um ganz grundlegende Spracheigenschaften. Die sollten schon dokumentiert sein.

Naja, teilweise stimme ich dir zu. Aber teilweise sind diese speziellen Konstrukte unter JS nur nötig um bestimmte OO Ansätze zu realisieren (z.b. private Variabeln), d.h. man muss erst Wissen wie man OO programmiert um verstehen zu können warum man private Variabeln und Funktionen überhaupt haben möchte. es geht also viel weiter. Ich seh das so, in der Fahrschule bringt dir ja auch keiner Rennauto fahren bei.

Ich persönlich hasse Dokumentationen, die mir so einen schwammigen Überblick geben, aber nicht wirklich verraten, wie die Dinge funktionieren. Man hat dauernd das Gefühl, da wird versucht, etwas zu verheimlichen, damit man nicht auch so gut wird, wie die, die das geschrieben haben ;-)

Es dürfte eher so sein, dass es schwierig ist allen gerecht zu werden. (auch ein Grund warum ich noch nie was für selfhtml geschaftt habe zu schreiben, entweder ich verlier mich im Detail oder mein Wissen ist nicht fundiert genug)

Zu diesem Beispiel:

function obj1() {
    this.abc = "123";
    this.bla = function() {
        alert(this.abc)
    }
};

var a = new obj1();
var b = a.bla;
b();

>   
> Damit wollte ich Jeena veranschaulichen, wie eigentlich die Bindung von Methoden an Objekte funktioniert.  
> Dass der Funkionsaufruf b() nicht mehr im Kontext des in a gespeicherten Objektes arbeitet, ist nicht unbedingt natürlich.  
  
Doch, du weist b hier lediglich die Referenz auf die Funktion zu, diese ist in JS nie an ein Objekt gebunden, sondern erst durch die Art wie du sie aufrufst kannst du erkennen zu welchem Objekt sie gehört.  
  
Letzlich ist es das gleiche wie das:  
~~~javascript
  
function obj1() {  
     this.abc = "123";  
     this.bla = bla_func;  
};  
function bla_func()  
{  
    alert(this.abc)  
}  
  
var a = new obj1();  
var b = a.bla;  
b();  

Die bla_func ist hier wie auch in deinem Fall völlig lösgelöst vom Objekt.

Struppi.

[Daniel Thoma]

Hallo Struppi,

d.h. man muss erst Wissen wie man OO programmiert um verstehen zu können warum man private Variabeln und Funktionen überhaupt haben möchte. es geht also viel weiter.

Ok, große Abhandlungen über OO gehen sicher zu weit, aber wenn man irgendwo ein Script findet oder von jemandem ein Beispiel bekommt, sollte man schon zumindest die Semantik der einzelnen Konstrukte nachschlagen können, um sich durchzuwursteln.

Es dürfte eher so sein, dass es schwierig ist allen gerecht zu werden.

Ja, das ist es sicher.

Doch, du weist b hier lediglich die Referenz auf die Funktion zu, diese ist in JS nie an ein Objekt gebunden, sondern erst durch die Art wie du sie aufrufst kannst du erkennen zu welchem Objekt sie gehört.

Ja, das ist mir klar, dein Beispiel ist da vielleicht besser.

Grüße

Daniel