Ausgewählter Vortrag:
Böses Javascript – Gutes Javascript?
-
16.10.2009, 11:40–12:10 Uhr, Raum 1
Wie setzt man JavaScript richtig ein, und was ist beim Einsatz von JavaScript zu bedenken und zu berücksichtigen.
Kann und soll man denn nun JavaScript auf barrierefreien Seiten bedenkenlos einsetzen?
- Ist JavaScript böse?
- JavaScript ist „unreif“ für Screen Reader.
- JavaScript - no problem?
- „Gutes“ JavaScript?
- 3 Schichten Modell
- Graceful Degradation
- Progressive Enhancement
- Best Practice (JavaScript wird erwachsen.)
- Testen, testen, testen!
- Beispiele
Unterlagen
Transkription:
Moderation Eric Eggert: Der nächste Vortragende ist Fritz Weisshart. Seit 2000 führt er seine Ein-Mann-Werbeagentur und als gelernter Maschinenbauer Bauingenieur ist ihm wichtig, dass die Harmonie, dass die Einzelteile miteinander harmonieren, und in diesem Sinne fragt er jetzt: Gibt es gutes JavaScript, böses JavaScript? Und mal schauen, welche Erkenntnisse wir davon mitnehmen können. Bitte.
Fritz Weisshart: Okay Eric, vielen Dank für die Vorstellung, und Sie, meine Damen und Herren, grüß Gott, womit auch klar ist, woher ich komme (Pause)
Publikum: (lacht)
Fritz Weisshart: Irgend so wo. (lacht) Noch eine Vorbemerkung, weil das Thema doch sehr sehr spröde ist, ich musste, nein ich musste viele Zitate und Verweise unterbringen und mir blieb irgendwie nichts anderes übrig, als das Ganze in Form einer Html-Seite online zu stellen. Die, der Artikel ist online, das hat zwei Vorteile, die Online-Version ist absolut akzent- und dialektfrei. Ich hab das selbst getestet mit dem Screen-Reader (...) (Lachen im Publikum) und der zweite Vorteil ist, wem das Thema also jetzt zu spröde ist, der kann die nächste halbe Stunde für ein kleines Nickerchen nutzen, weil es alles nachzulesen ist. (...)
Okay, die Fragestellung: Ist JavaScript böse oder ist JavaScript gut? (...) Ich hab versucht, das in folgende Kapitel einzuteilen: Erstens die Frage: Ist JavaScript böse? Dann als Sonderformat, JavaScript ist angeblich unreif für Screen-Reader, vielleicht ist es auch andersherum? JavaScript ist grundsätzlich kein Problem? Dann werd ich versuchen, bisschen vorzustellen, wie man gutes JavaScript erzeugt. Das Thema JavaScript – Best Practice hab ich bei Chris Heilmann angeliehen. Einen Artikel testen, und wenn noch Zeit bleibt, vielleicht einige Beispiele.
JavaScript ist grundsätzlich böse, dazu hat auch W3C mit der WCAG eins beigetragen. Dort gibt es den bekannten Passus: „Sorgen Sie dafür, dass Seiten verwendbar sind, wenn Scripts und so weiter abgeschaltet sind oder nicht unterstützt werden.“ Dieser Passus in der WCAG 1.0 wurde sehr oft fehlinterpretiert und daraus die Schlussfolgerung gezogen, JavaScript ist nicht barrierefrei oder für barrierefreie Seiten nicht verwendbar. Mit JavaScript wird aber auch wirklich viel Unfug getrieben. Jeder kennt die Fenster, die sich ungefragt öffnen, Fenster, die ungefragt in die Vollbildanzeige gezwungen werden, Kontextmenü desaktiviert , das heißt die rechte Maustaste, die Statusleiste für allerlei Unfug missbraucht. Das läuft alles noch unter dem Thema Spielerei. Schlimmer wird’s, wenn Navigationsmenüs zum Beispiel entweder vollkommen unsichtbar sind oder unbenutzbar, also Fly-Out-Menüs oder Drop-Down-Menüs, die für Tastaturnutzer und Screen-Reader schlichtweg unsichtbar sind. (...) Es geht noch schlimmer: JavaScript kann wirklich Schaden anrichten. Ich muss jetzt hier den ersten Verweis auf eine fremde Quelle bringen: Matthias Schäfer, der im Web mit dem Pseudonym Molily unterwegs ist, hat eine schöne Abhandlung erstellt, die ist im Web erreichbar – ich zitiere nur das Fazit aus dieser Abhandlung: „Wenn Sicherheitslücken in Browsern entdeckt werden, ist in den meisten Fällen JavaScript im Spiel.“ (Pause) Die Schlussfolgerung daraus könnte natürlich jetzt lauten: Bitte Finger weg von JavaScript, in diesem Fall ist die richtige Schlussfolgerung allerdings: bitte Browser updaten. (...)
Es geht noch schlimmer: Unter dem Titel Cross-Site-Scripting kann man nun wirklich Unfug anstellen, auch hierzu muss ich zur Vertiefung wieder auf eine Quelle verweisen: bei Heise gibt es einen schönen allgemein verständlichen oder leicht verständlichen Artikel, wie Cross-Site-Scripting funktioniert und dort gibt es sogar eine funktionierende Demo, die ist mal ganz interessant, um einfach zu wissen, was da passiert. (...) Ein bekanntes Sicherheitsrisiko von JavaScript ist die Verwendung von nicht initiierten, also implizierten globalen Variablen. Auch dazu später bisschen mehr.(..) Fazit unter diesem Kapitel, JavaScript selbst ist zwar nicht böse, aber es kann von bösen Buben als Werkzeug verwendet werden, um Böses anzustellen. Wer sich mit JavaScript beschäftigt und JavaScript auf seinen Seiten einsetzt, sollte also mögliche Fehlerquellen kennen, um diese Fehlerquellen durch richtiges Scripting zu vermeiden. (Pause)
Fritz Weisshart vor seinem Vortrag
Jetzt zu dem Sonderkapitel: JavaScript ist unreif für Screen-Reader. In fast allen Screen-Readern ist eines der am häufigsten vorkommenden, in Gänsefüßchen Fehlverhalten, dass ein Screen-Reader-Nutzer einen Link anklickt und erwartet, dass irgendetwas passiert. Passieren sollte beim Anklicken eines Links üblicherweise Sprung auf eine neue Seite oder eventuell Sprung auf der gleichen Seite. In vielen Fällen – und meistens ist dann JavaScript im Spiel – wird für den Screen-Reader-Benutzer nichts passieren. Dazu ein bisschen Hintergrundwissen, zusammengefasst, wie Screen-Reader ticken. Das Wichtigste, was man im Hinterkopf haben sollte: Screen-Reader lesen entgegen landläufiger Meinung eben nicht das vor, was auf dem Bildschirm sichtbar ist, sondern Screen-Reader legen eine sogenannte virtuelle Bildschirmkopie in den, in einen virtuellen Speich-, in einen Speicher und arbeiten dann mit dieser Kopie. Das kann im Fall von JavaScript und wird häufig dazu führen, dass sich zwar auf dem Bildschirm durch eine JavaScript-Operation am DOM irgend etwas ändert, die virtuelle Kopie, mit der der Screen-Reader arbeitet, davon nichts weiß und folglich der Screen-Reader-Nutzer der Meinung ist – und für ihn tatsächlich nichts passiert, wo etwas passieren sollte. Es gibt da noch einige Details, die zu berücksichtigen sind: Screen-Reader arbeiten mit – ich weiß gar nicht wie viel – drei oder vier verschiedenen Fokusverfolgungen, ich hab das nie richtig verstanden, auf dem Bildschirm ist halt in der Regel der Fokus dort, wo die Maus ist oder im günstigsten Fall die Tastatur.
Der Screen-Reader hat noch ein paar Möglichkeiten, wenn dann noch Sprachausgabe und Braille-Zeile parallel laufen, dann wird’s aber für mich zumindest vollkommen undurchsichtig. Aber auch daran sollte man denken, wenn man mit JavaScript an der laufenden Seite irgendwelche Aktionen durchführt. Dann kommt noch erschwerend hinzu, dazu, dass Screen-Reader, Screen-Reader noch mehr Kofigurationsmöglichkeiten bieten, als es bei Browsern ohnehin schon gibt. Jeder Webworker kennt das Problem, dass er sich eigentlich auf keine Standardkonfiguration beim Client, beim Userinterface einlassen kann und bei Screen-Readern ist das noch viel weniger der Fall. (...) Das ganze Thema sollte eigentlich in kürzerer oder fernerer Zukunft mit WAI ARIA in den Griff zu bekommen sein. Dort gibt’s diese Aria-live-Regionen, die unter Umständen wunderbar funktionieren. Ich hab ein Praxisbeispiel, ein Ajax-basierter Chat bringt Barrierefreiheit insofern mit, als er die einkommenden Nachrichten mit einem Signalton meldet. Wenn auf dem Screen-Reader Aria verfügbar ist, dann wird zusätzlich zu diesem Signalton auch noch die komplette einkommende Nachricht vorgelesen. Das Ganze wird in einigen Minuten unter dem Thema Progressive Enhancement noch näher zu erläutern sein. Leider ist heute so, dass nur sehr wenige Konfigurationen Aria-live überhaupt unterstützen. Meines Wissens sind dies die aktuelle Version von Jaws, die 10.0, und auch dort nur vernünftig in Kombination mit dem Firefox-Browser. Bei Verwendung des Internet Explorers ist das mehr oder weniger Zufall und erstaunlicherweise oder vielleicht auch nicht erstaunlicherweise der Open Source Screen-Reader NVDA. (Pause) JavaScript ist eigentlich kein Problem. In der Zwischenzeit hat auch die Neufassung der WCAG 2.0 null das indirekt verdeutlicht. Dort wird JavaScript überhaupt nicht mehr als kritisch bezeichnet. Voraussetzung natürlich, dass man die in der WCAG selbst aufgestellten Forderungen erfüllt.
Publikum: (husten)
Fritz Weisshart: Aber das ganze Web 2.0, von dem ja heute schon viel die Rede war, und vielleicht auch weiterhin noch die Rede sein wird, funktioniert ohnehin nur mit JavaScript. Ich hab zu dem Thema JavaScript noch mal auf die Schnelle an deutschen Top-Seiten eine nicht repräsentative Untersuchung gemacht. Wie, wo jeder erwarten wird: Alle großen Seiten setzen mehr oder weniger massiv JavaScript ein. Dabei gibt es, ja, ein Satz in mehr oder weniger Umfang auf allen Seiten, allerdings nur ein geringer Teil, vielleicht 20/25 Prozent dieser Seiten weisen, oder warnen, vor nicht verfügbaren JavaScript beim Anwender. Die berühmte Warnmeldung: „Sie haben JavaScript in ihrem Browser deaktiviert, bitte kaufen Sie sich ein XY.“ Eine schöne Lösung hab ich dort gefunden: Diesen Hinweis, diesen Warnhinweis nicht pauschal anzubringen, sondern wirklich erst dann, wenn es auf einer Site nicht mehr weitergeht. Beispiel ein Online-Reservierungs-Shop setzt folgenden Warnhinweis ein: „Nicht zur Betrachtung unserer Seiten benötigen Sie JavaScript bla-bla-bla“, sondern dort heißt es: „Sehr geehrter Kunde, für den Erwerb von JavaScript – von Karten muss ab hier JavaScript aktiviert sein“. Meines Erachtens eine ganz elegante Lösung. (...) Interessant ist auch, dass diese Top Seiten, die zwar massiv JavaScript einsetzen, überwiegend auch ohne JavaScript zugänglich und sogar bedienbar sind. Blogger.com zum Beispiel ermöglicht sogar eine Registrierung ohne JavaScript. Als man kann JavaScript so einsetzen, ...
Publikum: (unklarer Zwischenruf 14:48)
Fritz Weisshart: Ja (lacht), wie es sein soll. Generell nicht ohne JavaScript sind Multimediainhalte, sag ich mal, obwohl es da auch schon erste Fortschritte gibt und verständlicherweise Bank- und Finanzseiten. Dort ist es vermutlich aus Sicherheitsgründen eben nicht anders lösbar. (...) Okay, nachdem die Großen es anscheinend alle tun, wollen wir sehen, was ist Voraussetzung, um aus diesem potentiell bösen JavaScript gutes JavaScript zu machen?. Dazu sind grundsätzlich – ich mein, ich seh mal ab von, von grundsätzlichen Programmierkenntnissen, von Kenntnissen der Sprache. – es gibt grundsätzlich zwei oder drei Herangehensweisen, um eben die Probleme, die ich geschildert habe mit dem bösen JavaScript zu umschiffen und daraus gutes JavaScript zu machen. (...) Das gute JavaScript läuft international unter dem Ausdruck „Unobtrusive JavaScript“. Deutsche Übersetzungen klingen dermaßen holperig, dass ich mir die lieber spare. Anständiges oder unanständiges JavaScript, ich bleib bei dem Terminus Technicus „Unobtrusive JavaScript“. Dazu gehört meines Erachtens die Trennung auch der Verhaltensebene vom Inhalt und vom Design. Jeder hier im Saal ist in der Zwischenzeit sicher vertraut mit dem Ansatz Inhalt, Struktur und Design zu trennen in Form von Html und CSS. Der Ansatz, oder einer der Ansätze von unobtrusive JavaScript ist auch die Verhaltensebene zu separieren, das heißt eben komplett auszulagern aus dem Inhalt. (...) Noch mal die drei Ebenen: Inhalt und Struktur werden repräsentiert durch Html, das Design, die Präsentation durch CSS, und das Verhalten einer Webseite, die Funktionalität wird durch eine dritte Schicht, nämlich JavaScript dargestellt. (Pause) Ich hatte ursprünglich vor, keinen Source-Code hier zu zeigen. Ein Beispiel erlaube ich mir. Ein absolut gängiges und übliches Verfahren ist es, Textfelder in Formularen vor dem Abschicken mit JavaScript zu überprüfen, zum Beispiel auf gültiges Datum. (trinkt) Der Code dazu wird in der Regel direkt ins Html geschrieben in Form eines On-Change-Event-Handlers. Diesen On-Change-Event-Handler kann man recht elegant mit der geeigneter Technik ausgliedern, so dass hinterher in dem entsprechenden Input-Tag wirklich nur noch „input“, „type“, „text“, „name“ drinsteht und im Anschluss dran wird mit etwas JavaScript, das ich mir nun wirklich ersparen kann, weil es nachzulesen ist auf dem Artikel. Aus diesem Name-Attribut, das der entsprechende On-Change-Event-Handler kreiert. Klingt im ersten Moment kompliziert, wenn man es gemacht hat, eine wunderschöne und elegante Technik, die also genau dieses Trennen der dritten Ebene, der Verhaltensebene von Struktur und von Präsentation bewirkt. (Pause) Zu unobtrusive JavaScript gehört seit jeher der Ausdruck “Graceful Degradation”, schon wieder so ein Terminus Technicus, der meines Erachtens nicht vernünftig ins Deutsche zu übersetzen ist. Anmutige Verschlechterung klingt so fürchterlich, dass ich mir das in Zukunft spare. Graceful – aber das Prinzip von Graceful Degradation ist es wert, erwähnt zu werden. Grundsätzlich bedeutet es die Fähigkeit eines Systems, kontrolliert auf Fehler zu reagieren. (...) Mit Graceful Degradation wird die Eigenschaft eines Systems bezeichnet, auf Fehler und unerwartet eintreffende Ereignisse sicher und angemessen zu reagieren. Ein Fehler im Einzelsystem, in dem Fall ist das Einzelsystem die Verhaltensebene, die JavaScript-Ebene, reduziert die Funktionalität des Gesamtsystems nur schrittweise, zum Beispiel durch verminderte Qualität oder einem reduzierten Funktionsumfang. (...) Meines Erachtens viel schöner und für den, für die praktische Verwendung ein besseres Denkmodell ist die gedankliche Umkehrung des Prinzips Graceful Degradation zu – sorry, schon wieder englisch – Progressive Enhancement. Das lässt sich nun mit progressiver Verbesserung wenigstens noch einigermaßen verständlich übersetzen. (...) Ich erlaube mir mal einfach zu zitieren: Progressive Verbesserung beschreibt eine Methode im Webdesign, die Barrierefreiheit, semantische Auszeichnung und Trennung von Informationen und Präsentation beinhaltet, um eine Website auch für Endgeräte benutzbar zu machen, die nur über eingeschränkte Funktionen verfügen. Die Philosophie dahinter ist, dass Webseiten grundsätzlich mit jedem Webbrowser und jeder Art Internetverbindung in ihrer grundlegendsten Form – nämlich der Bereitstellung von Informationen – zugänglich sein sollten und Benutzern mit besserer Bandbreite und fortgeschrittenen Browsern oder Screen-Readern oder was auch immer eine verbesserte Version der Seite dargestellt wird. (...) Bei der Entwicklung einer Webseite mit JavaScript – Unterstützung heißt Progressive Enhancement: Ich gehe genau in dieser Reihenfolge dieses Drei-Schichten-Modelles vor, in dem ich erst die Struktur entwickle, und erst dann, egal in welcher Reihenfolge, die Präsentation, dass heißt das CSS, und die Verhaltensebene in Form von beispielsweise JavaScript. (Pause) Unobtrusive JavaScript hat Chris Heilmann, dort habe ich Anleihe genommen, unter dem Thema „JavaScript Best Practice“ so schön beschrieben, dass ich mir das wirklich ersparen kann und einfach auf die, auf den Online-Vortrag von, von Chris verweise. Ich habe mir auch hier erlaubt, ein Fazit zu zitieren: JavaScript wird erwachsen. Aus einem Werkzeug für Spielereien wird ein Werkzeug zur Erstellung ernsthafter Anwendungen. JavaScript Best Practices gleichen häufig denen in anderen Programmiersprachen: Kapselung und Trennung der Ebenen, hatten wir, Vermeidung von globalen Variablen, ein Sonderfall, sinnvolle Namenskonventionen, kann nie schaden, Verwendung von geeigneten Entwurfsvorlagen und von systematischen Tests. Der letzte Punkt wird im Folgenden vertieft: Ich hab ein schönes, einen schönen Spruch gefunden, den man sich ruhig an die Wand kleben kann: Testen Sie Ihre Scripts, bevor es Ihre Kunden tun. (...) Beim Testen von JavaScript ist zu unterscheiden zwischen dem Test des Scripts selbst auf Fehlerfreiheit, also das klassische debuggen.. Um JavaScript zu debuggen, zähle ich mal auf eine Reihe von Werkzeugen, mit denen ich auch arbeite. Als erstes die sehr brauchbare JavaScript-Konsole von Firefox, als nächstes eine geniale Firefox-Erweiterung, Firebug, dürfte auch bekannt sein. Der Internet Explorer braucht natürlich mal wieder eine Sonderbehandlung. In der Zwischenzeit gibt’s in der Version acht des Internet Explorers erstmals eine eigene brauchbare, einen eigenen brauchbaren Debugger.
Publikum: (husten)
Moderator Eric Eggert stellt Fritz Weisshart vor seinem Vortrag vor.
Fritz Weisshart: Was macht der IE, welche Sonderstellung hat er? Der IE verwendet anstelle von JavaScript eine proprietäre Microsoft-eigene Entwicklung, nämlich J-Script. Das ist der Grund, warum grundsätzlich JavaScripts eben auch im IE getestet werden müssen und gegebenenfalls debuggt werden müssen. Und als letztes noch ein echtes Zuckerl: JSLint, eine Art Validator für JavaScript. JSLint deckt als einziger der mir bekannten Debugger das, eines der größten Sicherheitsrisiken von JavaScript auf, nämlich nicht initialisierte globale Variablen. J – JSLint würde ich wirklich jedem empfehlen, der sich mit JavaScript beschäftigt, sich das mal anzuschauen. Ist im ersten Moment erschreckend, macht aber unter Umständen recht schnell süchtig. Es gibt Leute, die sind süchtig nach Validatoren aller Art und da reiht sich JSLint schön ein. (...) Selbstverständlich muss ein einmal erstelltes JavaScript auch auf Barrierefreiheit separat getestet werden. Barrierefreiheit im weitesten Sinn heißt, alle möglichen Betriebssysteme und Browser, weil natürlich kein Mensch in der Lage ist, sich alle denkbaren Kombinationen von Betriebssystemen und Browsern vorzuhalten nur zu Testzwecken, gibt es hierfür eine elegante Lösung, die ich fast uneingeschränkt empfehlen kann: Browserpool.de. Ein Service, der auf einem Uni-Server in Stuttgart läuft und der das Fernsteuern irgendwo um die 15 oder 20 unterschiedlichen Konfigurationen einschließlich Linux mit fünf Browserversionen, Mac mit einer Handvoll Browsern ermöglicht und dort eben im Gegensatz den bekannten Browsershot-Tools, die eben nur statische Bilder erzeugen, wirklich auch das Testen von interaktiven Funktionalitäten ermöglicht, dass heißt das Ablaufenlassen von Scripten ist dort möglich. Ich kann oder die zur Verfügung gestellten Browser echt fernsteuern. (...) Nicht zu vergessen der Test in Handys und PDAs, also mobile Browser, ein einfacher Test, wir haben es gerade eben gehört, einfach mal die Maus weglegen und wirklich Seiten ohne Maus bedienen, unheimlich hilfreich, und ein Test ohne Maus nimmt viele denkbare Probleme, die ein Screen-Reader-Nutzer haben könnte, schon mal vorweg. Screen-Reader-Nutzer sind eben Tastaturnutzer. (...) Last but not least auch mal JavaScript deaktivieren und mal sehen, was macht die Seite ohne JavaScript. (Pause)
Ich hab nur zwei Beispiele herausgesucht, zuerst, weil das immer einfacher ist, ein schlechtes Beispiel, und das findet sich ausgerechnet bei Google, und zwar bei den bekannten Webmastertools von Google. Dort gibt es eine Art Dropdown-Menü oder Aufklapp-Navigation mit einem Pluszeichen vorangestellt, das bei Anklicken eine Unter- ein Untermenü öffnet. So weit so gut, der Versuch, dieses Menü mit der Navigation zu bedienen, scheitert. Weil schlicht und einfach die Hauptnavigationspunkte zwar aussehen wie Links, wie klassische Links in blauer Schrift, unterstrichen, aber mit der Tastatur diese Pseudo-Links nicht erreichbar sind. Ich komme einfach an diese, an diese Links nicht ran. Interessant wird’s erst, wenn man JavaScript deaktiviert, und dann zeigt sich plötzlich die ganze Struktur. Diese scheinbaren Links werden zu einfachen Text und die Navigationspunkte der zweiten Ebene, laute echte Links, sind erreichbar. Also eine, eine Perversion, ich weiß nicht wie ich es beschreiben soll – ein Menü, das nur funktioniert für einen Menübenutzer, einen Tastaturbenutzer oder Screen-Reader-Nutzer, in dem ich JavaScript deaktiviere. Ich hab mir einfach einen Spaß daraus gemacht und das gleiche Beispiel, das ich bei Google gefunden habe, auf meine eigenen Seite – ich will Sie aber jetzt mit der Demonstration wirklich nicht langweilen. Wer will, kann sich das selbst anschauen mit einer ausführlichen Beschreibung des Scripts, was dahintersteht selbst. Ich hab genau das gleiche Aufklappmenü in JavaScript gestaltet, aber so, wie es eben sein soll, und versucht, die ganzen Grundsätze, die ich geschildert hab für gutes JavaScript, unobtrusive JavaScript dort umzusetzen. Dieses Aufklappmenü sieht wie gesagt äußerlich fast genauso aus wie das Google-Beispiel, nur es sollte hoffentlich funktionieren. Damit bin ich am Ende. Ich bedanke mich für die Aufmerksamkeit. Wer abgeschaltet hat, kann wieder aufwachen und ich bin offen für Fragen.
Publikum: (Applaus)
Moderation Eric Eggert: Vielen Dank, wir haben jetzt noch ein bisschen technische Dinge, die hier gemacht werden müssen, deswegen haben wir noch ein bisschen mehr Zeit für Fragen. Gibt es welche? Nicht? Anmerkungen, Hinweise?
(Pause)
Person aus dem Publikum 1: Mein Name ist Andreas Hafenscher, Html ist mir ein Begriff, JavaScript weniger, was den Code selbst anbelangt und es würde mich interessieren, mehr in das Thema hineinzukommen. Wo gibt’s eine Ressource, die mir hilft, ein Verständnis für JavaScript zu bekommen, aber gleich richtig. Kann mir da vielleicht jemand ein Tipp geben bitte?
Fritz Weisshart: Ich muss leider passen. Ich muss leider passen. Ich kenne keine empfehlenswerte-, Chris, es tut mir leid, bitte, übernimm du, ja, ich kenne keine Ressource im Web, die ich empfehlen könnte. Danke.
Christian Heilmann: Also das barrierefreie JavaScript, das unobtrusive JavaScript ist auch auf Deutsch von mir übersetzt, und ist bei „Ichwill.net“, also-
Fritz Weisshart: Du steckst hinter vor: „ichwill.net“?
Christian Heilmann: Ja.
Fritz Weisshart: Alles klar (lacht). „Ichwill.net“ ist auf dem Online-Artikel verlinkt, und damit findbar.
Christian Heilmann: Generell ist es, wenn jemand kein JavaScript verstehen will, dann soll er es auch nicht anfassen.
Fritz Weisshart: Ja! (lacht)
(Pause)
Moderation Eric Eggert: Okay, ich hab da hinten noch eine Meldung gesehen, da war was, irgendwo
Person aus dem Publikum 2: (unklar 34:58)
Moderation Eric Eggert: Willst du den Namen vorher sagen und das Mikrofon benutzen.
Person aus dem Publikum 2: Werner Leiner. Es gibt eine recht gute, gute Beispiele und Einführung in JavaScript auf selfhtml.de, also „de.selfhtml.de“, da gibt’s alles über Html, JavaScript und PHP.
Fritz Weisshart: Ich hab’s akustisch leider nicht verstanden.
Person aus dem Publikum 2: Selfhtml.de ist
Fritz Weisshart: Ja! Ja!
Person aus dem Publikum 2: eigentlich die Adresse …
Fritz Weisshart: Immer! Aber jetzt speziell für JavaScript meines Erachtens – überarbeitungsbedürftig. Seit mehreren Jahren wird an der Selfhtml-Version 9 gearbeitet, ich weiß es nicht, wo das Projekt steckengeblieben ist und dort wird auch ganz intensiv gerade die JavaScript-Sektion diskutiert und wenn die Version 9 wirklich mal rauskommt und entsprechend verbessert. Und wenn das der Fall ist, spätestens dann, ist es sicher eine sehr empfehlenswerte Ressource, ja.
Person aus dem Publikum 2: also ist eigentlich ein gutes Zeichen, dass daran gearbeitet wird.
Fritz Weisshart: Ich weiß es nicht, in welchem Stadium (lacht)
Person aus dem Publikum 2: Am besten googlen…
Fritz Weisshart: Der Stefan Münz ist glaub ich ausgestiegen aus dem Projekt. (...) Also der Gründer.
Moderation Eric Eggert: Okay, Christian hat sich noch gemeldet. Nochmal.
Christian Heilmann: Ein ganz wichtiger Tipp, wer heutzutage JavaScript verwenden will, hört auf, JavaSript von Anfang an zu schreiben. Es gibt Libraries, wie JQuery, wie YUI, wie Dojo, wie Prototype, wie MooTools – Tools, die werden alle von Firmen entwickelt, damit Browser funktionieren, weil Browser – das größte Problem mit JavaScript ist nicht JavaScript selbst, sondern dass Browser es falsch verstehen, es schlecht anwenden, es falsch anzeigen. Und deswegen bauen wir diese ganzen Libraries YUI ist von Yahoo, Dojo ist von IBM unterstützt und von Google. Und diese Sachen sollte man verwenden, bevor man überhaupt mit JavaScript anfängt, weil, dann muss man nicht durch die ganzen selben Probleme und Fehler durchgehen, die wir seit 1997 alle schon einmal gemacht haben.
Fritz Weisshart: Ja, hundertprozentig einverstanden mit einer Einschränkung, und damit nehme ich eigentlich meine Zustimmung gleichzeitig wieder zurück. Ich bin grundsätzlich der Meinung, man darf keine Scripte einsetzen, die man nicht selbst zumindest lesen, besser noch verstehen kann. Und das ist natürlich eine gewisse Einschränkung, die dann für diese Libraries gilt.
Christian Heilmann: Wenn eine Library keine gute Dokumentation hat, ist es keine gute Library.
Fritz Weisshart: Ja, aber wie gesagt, anfangen mit JavaScript in Form von – ich sag jetzt mal irgendwas mit Drag and Drop aus der Library heraus – es ist eigentlich nicht der richtige Einstieg. Ich sollte vorher wissen, was ich tue. Christian Heilmann: Also ich habe drei Bücher geschrieben, mit Leuten, zu erklären, was man mit Tools tut, und ich sehe Leute es immer wieder falsch verwenden. Man kann es gerne lernen so, und es ist auch wichtig, dass man die JavaScript selbst versteht und es gibt super Videos von Douglas Crockford beispielsweise darüber auch auf dem Yahoo Developer Network Videoseite und Vorträge gibt’s ohne Ende auf Youtube auch. Das Problem ist, dass wenn Live-Seiten gebaut werden, sollte das niemand heutzutage mehr machen ohne Library und es ist einfach ein Sicherheitsproblem, es ist ein Performance-Problem und es ist einfach ein Problem des Internet Explorers 6, dass immer noch nicht tot ist.
Fritz Weisshart: Ja…
Christian Heilmann: Und Libraries machen Internet Explorer 6 fast zum Browser.
Fritz Weisshart: (lacht)
Publikum: (lachen, Applaus)
Moderation Eric Eggert: Das ist jetzt aber auch billiger Applaus, also…(lacht)
Christian Heilmann: ...für billige Produkte…
Moderation Eric Eggert: (lacht) Gut. Weiter Anmerkungen? Fragen (...). Wenn nicht, dann bedanke ich mich noch einmal herzlich für den Vortrag und für die sehr ausführlichen Folien auch.
Bilder von Karola Riegler. Intro von Derek K. Miller.
Tags:
Fritz Weisshart