nicht angemeldet
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.
- Einleitung, die auf alle Glaubensfragen eingeht und die schwere Stellung von JavaScript in der Web-Designer-Welt vorstellt.
- Die theoretische Grundlage mit dem ISO-Standart ECMAScript kurz anreissen.
- Eine wohl überlegte komplette wertfreie (ohne meinungsgedösel) Referenz aller Objekte, Funktionen und Kontrollfunktionen. Hier auch die Unterschiede der verschiedenen Browser beleuchten.
- 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
MudGuard
Struppi