Eine Lanze brechen für Frames

[molily]

Hallo,

Ich habe sehr viel Verständnis für Menschen, die mit ihren körperlichen Gebrechen in ihrem Leben zurechtkommen müssen.
Doch niemand würde allen Ernstes behaupten wollen, es sollte i.e. für Blinde die Barriere zum Autofahren demontiert werden

Unpassender Vergleich. Das WWW ist im Gegensatz zum Straßenverkehr prinzipiell für Blinde zugänglich und es bedarf keiner entsprechenden Hochtechnologie (»technischer Ersatz für die menschliche Sehfähigkeit«) wie beim Straßenverkehr.

Bei allen Statements zu diesem Thema fällt mir auf, daß Webpages angeblich ausschließlich nur zu einem Zweck gemacht wären. Ich für meinen Teil empfinde das als eine sehr eingeschränkte Sichtweise. So empfinde ich den Tadel, daß Webpages nicht nur für eine Zielgruppe gemacht werden sollten, als nicht gerechtfertigt.

Der Begriff der »Zielgruppe« ist ein Konstrukt von Seiten des Autors zur Analyse der Bedürfnisse der Besucher und somit der Anforderungen an die Seite. Sofern sich die Seite nicht mit Technik selbst beschäftigt (z.B. Seiten zur Flashentwicklung können das Flash-Plugin beim Besucher mit hoher Wahrscheinlichkeit voraussetzen), ist der Schluss von der Zielgruppe (idealer Benutzer) auf eine ideale technische Zugangsweise höchstgradig spekulativ.

Ich habe für meine Bedürfnisse die Technik der Webpages als Ersatz für Dokumentation auf Papier entdeckt, somit richtet sich das sehr wohl an bestimmte Zielgruppen.

Das hat niemand der Kritiker des Zielgruppenwahns bezweifelt.

Der Ausschluß anderer, die nicht zu diesen Zielgruppen gehören, liegt oft in der Natur der Sache und bedeutet dabei keineswegs eine Diskriminerung.

Ja. Aber nur selten liegt es in der Natur der Sache. Leider meinen viele, die Zusammenhänge zwischen Thema der Seite, Zielgruppe und deren technischen Zugangsweisen sei mehr als ein Erklärungsmodell, um die Seite den Bedürfnissen anzupassen, sondern sei natürlich und faktisch vorhanden, genauso, wie man es im Kopf hat. Das ist gefährlich, weil man den Sinn für reale Bedürfnisse verliert.

Technische Dokumentationen sind IMHO zum Teil aufwendiger als manche Webpages, die als freies Angebot für jedermann errichtet werden. Der oft von den Frame-Gegnern angeführte Hinweis, Navigation wäre zur Vermeidung von Frames ohne weitere Probleme über CSS in die Seite einzubauen, ist IMHO zu kurz gesehen. Ich habe in meinen Projekt derzeit an die 300 Seiten eingebaut, die Navigation enthält z.Zt. etwas mehr als 1300 Einträge, diese Navigation mit jeder Seite laden zu wollen, würde jedes mal etwa zusätzliche 60 KB erfordern.

1. Technische Dokumentation ist, wie du eben sagst, in dieser Hinsicht ein Sonderfall. Der Frame-Gegner, der bei einem solchen Ausmaß zu Includes von ellenlangen Navigationen rät, legt noch ganz andere Defizite an den Tag, als nur Frames plump abzulehnen.
2. Eine Navigation mit 1.300 Einträgen in einen Frame zu laden, ist allgemein gesehen wenig benutzerfreundlich (glaube auch nicht, dass du das genau meinst). Der Aufbau einer hierarchischen Navigation oder einer anderweitig Metadaten-basierten Navigation (etwa Stichwörtern) ist in so einem Fall allgemein gesprochen sinnvoller. Hinzu kommen andere Mechanismen, um in diese Einträge Ordnung hineinzubringen (Suchfunktionen).
3. Wenn man erst einmal die Inhaltsstruktur rekonstruiert hat, kann man sich Gedanken über eine sinnvolle Ordnung machen, das heißt, wie diese Struktur dem Leser präsentiert wird. Wenn man guten Hypertext schreibt, greifen die genannten Mechanismen auch und erlauben eine schnelle und klare Navigation durch die Fülle an Inhalt. Dazu können Frames punktuell ein brauchbares Mittel sein, um ein übersichtliche Schnittstelle zum Inhalt zu schaffen. Nichtsdestoweniger müssen nach wie vor die gängigen Nachteile von Frames beachtet werden. Es muss also auch eine Navigation möglich sein, die ohne dieses Hilfsmittel weiterhin funktioniert.

Auch der Hinweis darauf, Javascript zu vermeiden, weil es gute Gründe gegen die Verwendung von Javascript geben würde, wobei die Kritiker jedes mal die Begründung der angeblich gute Gründe schuldig bleiben, ist für mich sehr weit hergeholt.

Du bleibst wunderbar allgemein. So kannst du darauf verzichten, irgendetwas spezielles, argumentativ untermauertes zu sagen. Du stellst ganz allgemein fest, dass alle diejenigen, die nicht deiner Meinung sind, keine Belege anführen. Selbst bringst du ebensowenig welche, denn du steigst gar nicht in die sachliche Diskussion ein.
Polemik, Polemik.

So kann denn die Absicht, eine Navigation mit einem Frame bei Verwendung von Javascript aufzubauen, nicht immer mit dem Hinweis auf fehlende Barrierefreiheit mißbilligt werden.

Natürlich. Wenn ich eine Technik ihrer Vorteile wegen einsetze, muss ich ebenso die Nachteile in Betracht ziehen. Mangelnde Barrierefreiheit von Frames wird immer ein Thema sein.

Die Gestaltung einer technischen Dokumentation mit der Webtechnik ist ein ernst zunehmendes Thema und es wäre schade, wenn wegen einseitiger Sichtweisen die Elemente, die bisher ihre guten Dienste tun, aus dem Standard verschwinden würden.

Wieso sollten sie auch?

Das Framesets bisher nur als transitional eingestuft sind, halte ich für bedenklich.

Frames sind nicht Transitional. Frames sind Frames. Frames sind Markup, um eine Mehrdokumenten-Präsentation festzulegen. In diesem Sinne sind sie nicht »Strict«, weil sie eben die Ausgabe beeinflussen. Daher ist etwa das target-Attribut nicht in Strict.

Die angeblichen Probleme mit Frames beruhen IMHO auf nicht ausgereifter Umsetzung bei den Browsern.

Nicht die grundlegenden Probleme. Diese beruhen vor allem darauf, dass die Frametechnik konzeptionelle Schwächen hat.

Das Kind mit dem Bade ausschütten zu wollen, so wie es auf verschiedenen Sites zu lesen ist, mit der Maßgabe Frames ganz abschaffen zu wollen

Du hast dich nicht wirklich in die Frames-Diskussion eingelesen, oder?
Mit XFrames werden Frames weiterentwickelt.

Die angeblichen Probleme mit Frames lassen sich heute alle mit Bordmitteln lösen, da bedarf es keines Hacks

Das ist wirklich falsch, weil XFrames gerade die Probleme aus der Welt schaffen will, die bei HTML-Frames eben nur durch umständliche Hacks gelöst werden konnten.

Es wird IMHO aber nie möglich sein, eine Webpages im Sinne eine eierlegenden Wollmilchsau für alle Plattformen erstellen zu können.

»Man kann nicht alle unterstützen, ein bisschen Schwund ist immer« - toller Spruch, den man immer wieder von Leuten zu hören bekommt, die im Grunde genommen keine Lust haben, sich mit Accessibility zu beschäftigen. Nichts gegen eine Scheißegal-Haltung, meinetwegen, aber diese Binsenweisheit taugt nicht zu einer Rechtfertigung der unbekümmerten Technikverwendung.

Man wird sich Gedanken machen müssen, wie man Minderheiten besser versorgt und technische Möglichkeiten errichtet, die diesen speziellen Zwecken dienen.

Nichts anderes ist die Beschäftigung mit der Frage, wie man eine Seite alternativ auch für diejenigen zugänglich macht, die mit der Frames-Technik weniger effzient arbeiten können (aufgrund welcher Voraussetzungen auch immer, nicht nur technischer).

Das ist IMHO besser, als den kleinsten gemeinsamen Nenner zu suchen, wobei andere sinnvolle Techniken aufgegeben werden.

Wieso kramst du diesen Mythos vom kleinsten gemeinsamen Nenner heraus? Abwärtskompatibilität (»graceful degradation«) ist das Stichwort. Das bedeutet jedem das Seine, nicht allen dasselbe.

Im Großen und Ganzen scheinst du dich nicht besonders tief mit der Debatte rund um den Frameeinsatz beschäftigt zu haben, besteht dein Beitrag doch weitesgehend aus alten Phrasen und keinen handfesten Argumenten oder Widerlegungen. Im Forumsarchiv gab es dazu einige aufschlussreiche Diskussionen. Vielleicht beschäftigst du dich erst einmal damit, was Frame-Kritiker und JavaScript-Kritiker überhaupt für Positionen vertreten, bevor du sie mal eben im vorbeigehen mit den üblichen Klischeevorwürfen niederbügelst.

Mathias