RSS Feed
abonnieren.
Suche
Wunschzettel
Weblogeinträge
ReferenzenThesen zum Gebrauch von JavaScript 05. September 2008 um 09:57 Uhr / Webdesign
Mathias Schäfer (molily) hat den interessanten Beitrag Sieben Thesen zum gegenwärtigen JavaScript-Gebrauch im SELFHTML-Weblog veröffentlicht. Ich möchte ihn hier etwas aufgreifen und diskutieren. Ziemlich am Anfang schreibt er:
und vor allem für Normalsterbliche dokumentiert werden
Wer bitte würde das wollen? Warum sollte es menschen wie meiner Oma, die damit sowieso nie was anfangen wird, unbedingt möglich gemacht werden jetzt auch JSON zu verstehen? Oder was meinst du mit "Normalsterblichen"? Ich finde jeder Interessierte kann sogar schon heute mit ein wenig Fleißarbeit durchaus gute Dokumentationen zum jeweiligen Gebiet finden, deshalb würde ich an dieser Stelle nicht so schwarz malen.
Zur Ajax-Navigation hat sich meines wissens einzig und allein das IE-Team gedanken gemacht und erlaubt anscheindend die History mit zusätzlichen Informationen zu versehen, so dass die Zrück- und Weiter-Buttons wieder zu funktionieren anfangen. Keine perfekte Lösung, denn man kann die URL nirgendwo hinschicken aber das konnte man mit Session-URLs bisher ja auch noch nicht machen. Siehe auch IEBlog: IE8 AJAX Navigation
»Unobtrusive JavaScript« bleibt eine Nische
Leider muss ich das Zustimmen und vor allem auch mir an die Nase fassen. Es ist aber auch manchmal wirklich verdammt schwierig das richtig umzusetzen. Ich mache zum Beispiel sehr oft solche HTML/CSS/JavaScript Mockups (Funktionierende Templates) für andere Firmen, die dann das ganze nehmen und mit .NET oder irgend einem CMS implementieren. Ich versuche da zwar zu schauen dass das ganze zumindest auch bedienbar bleibt was ich mache, aber dennoch gibt es da massenweise inline-JavaScript um irgendwelche klick-Funktionalität anzubieten oder Daten die das JavaScript dann nutzen soll irgendwo unterzubringen, obwohl das in externen XML- oder JSON-Dateien wohl viel besser aufgehoben wäre, die wären dann auch nachladbar usw.
Instesammt ein sehr lesenswerter Artikel der zum Nachdenken über Dokumentation und anderes anregt.
Kommentare
Die Kommentare sind für diesen Eintrag geschlossen.
Johannes Emerich aus Osnabrück schrieb am 05.09.2008
Ich habe Mathias’ Artikel noch nicht gelesen, aber was ist denn mit internen Verweisen (#anker) zum »Fixen« von Verlauf und URL?
Das ist sicher nicht für alle Fälle geeignet, aber ebenso sollen viele AJAX-Aktionen ohnehin nicht im Verlauf auftauchen.
Jeena Paradies aus Varberg / Schweden schrieb am 05.09.2008
So weit ich das verstanden habe wird es nur einen Zugang zu einer API geben, mit deren Hilfe man dann so zu sagen den Status einer Seite in der History abspeichern kann, wohl was ähnliches wie der komische __VIEWSTATE den man in vielen ASP.NET Anwendungen als hidden-field sehen kann. Es wäre zwar keine gute Lösung aber es wäre auf jeden fall eine Lösung, im Gegensatz zu allen anderen Browsern, um des Problems Herr zu werden.
#Anker sind doch kein Problem bisher oder? Damit hüpft man auf der Seite ja nur rauf und runter?
Johannes Emerich aus Osnabrück schrieb am 05.09.2008
Ich meinte, dass man bei gewissen AJAX-Aktionen die z.B. mittels eines Links ausgelöst werden, auf einen entsprechenden internen Anker verweisen könnte. Wenn man zudem auf das Unterbinden des URI-Wechsels (per
) verzichtet, ändert sich die URI in der Adresszeile und ist dem Nutzer zum Kopieren und Versenden z.B. in einer Mail zugänglich.
Beim Aufbau der Seite muss die URI dann natürlich auf etwaige interne Verweise untersucht und gegebenenfalls die Seite (wohl per JS) in den entsprechenden Zustand gebracht werden.
Jeena Paradies aus Varberg / Schweden schrieb am 05.09.2008
Aber das Weglassen führt dazu dass die Seite immer irgendwo hin hüpft, das ist auch nicht gerade das gelbe vom Ei.
Johannes Emerich aus Osnabrück schrieb am 05.09.2008
Nur, falls es tatsächlich eine entsprechende Referenz im Dokument gibt. Ich habe das eben unter Mac OS mit Safari und Firefox mit diesem Dokument getestet. Beide springen nicht, sofern der interne Verweis nirgends definiert ist, d.h. in diesem Fall gibt es nirgends ein Element mit der ID "nicht-definiert".
Man könnte, da Verweise auf nicht-existente Positionen auch nicht wundervoll sind, die IDs nach dem Laden der Seite mit JavaScript entfernen.
Konkretes Beispiel mit »graceful degradation«: Eine Informations-Seite mit fünf Registern, wovon jeweils nur eines angezeigt wird und mit JavaScript zwischen den Registern gewechselt werden kann. Falls ein Nutzer ohne JavaScript das Dokument lädt, werden alle fünf Register untereinander angezeigt und jedes hat eine ID über das es referenziert und direkt verlinkt werden kann. Beim Aufruf mit JavaScript wird die Seite wie zuvor beschrieben umstrukturiert (mit je nur einem angezeigten Register) und die IDs werden entfernt. Die internen Referenzen erscheinen aber nach wie vor in der Adresszeile und können wie in meinem vorigen Kommentar beschrieben genutzt werden.
Jeena Paradies aus Varberg / Schweden schrieb am 05.09.2008