nicht angemeldet
Hallo,
»Zudem bestehen Schwierigkeiten Framesets barrierefrei zu verwenden.« - Undifferenziertes Gerede, ohne Willen, den Sachverhalt irgendwie näher zu erläutern bzw. auszuführen. Wie gesagt, Buzzwordeinstreuung. (Hallo, Johannes!)
Ich gebe zu, dass diese Formulierung etwas unglücklich gewählt war. Deshalb habe ich diesen Abschnitt des Artikels noch einmal überarbeitet.
Ein paar generelle Anmerkungen, es stammt ja nicht alles vor dir:
CSS kann in bestimmter Hinsicht nie ein »Ersatz« für Frames sein. Von »frameersetzenden CSS-Techniken« zu sprechen, begrenzt Frames auf einen bestimmten Aspekt. Es stimmt zwar, dass viele Autoren nur auf diesen Effekt schielen, in der Regel geht es aber um viel mehr, zumindest wenn man die Vorteile von Frames auch ausnutzen will. Und wenn Frames wirklich sinnvoll und vorteilhaft eingesetzt werden, stehen diese unnachahmlichen Eigenheiten im Vordergrund. Die »Aufteilung des Anzeigebereichs in Teilbereiche« ist nicht nur ein optischer Effekt, sondern die Aufteilung in Bereiche, in welchen eigenständige Dokumente angezeigt werden, welche auch einzeln verfasst/angesehen/ausgewertet/... werden könnten. Das war immer der Knackpunkt von Frames und dem lässt sich auch nicht mit serverseitig dynamischer bzw. autorenseitiger Zusammenstellung von Dokumentteilen (Navigation-Include plus variabler Hautpinhalt usw.) und CSS (position:fixed, eventuell overflow:scroll usw.) begegnen. Echte Paralleldarstellung eigenständiger Dokumente bzw. Knoten ist nach wie vor nur mit Frames/Iframes möglich und in gewisser Weise auch nur mit Frames sinnvoll, wenn man die sinnvollen Einsatzmöglichkeiten denkt (siehe u.a. mein Artikelfragment). Alle denkbaren integrativen Lösungen können per definitionem nicht grundlegende Merkmale von Frames aufgreifen. Von der praktischen Untauglichkeit von position:fixed usw. und der damit in sich ignoranten, weil alle Umstände leugnenden Zuspitzung auf CSS als Framesersatz ganz abgesehen.
Im Artikel wird überhaupt nicht herausgearbeitet, was die Aufteilung des Anzeigebereichs in Teilbereiche ausmacht - unabhängige Scrollbarkeit, sodass die anderen Bereiche ihre Position und ihr Guckloch auf den Dokumentteil behalten, ist es jedenfalls nicht ausschließlich. Spaltendarstellung usw. war auch schon vor sechs oder sieben Jahren möglich, dazu muss man nicht auf die »moderne Webgestaltung« hinweisen.
Wenn sich der Sinn eines Einzeldokuments erst aus dem Zusammenhang eines Framesets und somit dem Kontext anderer Dokumente erschließt, sollte, so glaubt man, in jedem Fall das exakt zugehörige Frameset automatisch oder manuell nachgeladen werden (und es sollte exakt ein zugehöriges Frameset existieren). Das ist an sich auch relativ zuverlässig möglich. Dagegen steht, dass das Dokument auch aus sich selbst heraus ohne das Frameset, beispielsweise durch direkte Links (das heißt nicht nur »nach oben« zum Frameset), den Kontext zugänglich machen sollte, sonst wäre es nicht ohne Frames nutzbar. Diese Selbstständigkeit und gleichzeitige Einbindung in den Kontext ist zunächst einmal eine Grundvoraussetzung. Nun sind zahlreiche Situationen denkbar, in denen es notwendig ist, dass das Dokument einzeln angezeigt wird und auch diese Selbstständigkeit genutzt wird. Wahllos ein über ein JavaScript das Frameset nachzuladen, verhindert diese Art, die Seite zu lesen. Hier existiert ein Grundwiderspruch, ein Aspekt, welcher gleichzeitig Vorteil und Nachteil von Frames ist, siehe auch mein verlinkter Artikel.
»Oft wird angeführt, dass Frames dem Grundgedanken der Trennung von Struktur und Präsentation widersprechen, da Frames ein Mittel zur visuellen Gestaltung sind.«
Da hat wieder jemand Buzzwords eingestreut. Ich verstehe nicht, was dieser Satz meint, und wenn er das meint, was ich glaube, halte ich es für Unsinn. Das ist auch kein gängiges Argument gegen Frames, das kann prinzipiell kein Argument gegen Frames sein. Frames waren und sind absichtlich eine Präsentationstechnik und werden es auch bleiben. Unter den besagten Vorzeichen wurden Frames als eigener, sich fundamental absetzender Dokumenttyp in HTML eingeführt und exakt aus diesem Grund werden sie aus der zukünftig die rein logische Textauszeichnung betreffenden Sprache HTML ausgegliedert und zu einer eigenen, bewusst die Präsentation betreffenden XML-Sprache umgeformt (wobei man darüber streiten kann - Frames stellen auch implizit einen semantischen Bezug her, den man bspw. über andere eingebundene XML-Sprachen herausarbeiten könnte; und sie werden zur generellen Mehrfenstertechnik ausgebaut, womit immer mehr Abstraktion Einzug hält). Wenn man daran den Maßstab »Trennung von Struktur und Präsentation« anlegt, waren Frames als Präsentationstechnik immer als eigenständiger Dokumenttyp von klassischen HTML-Dokumenten, welche darauf spezialisiert sind, formal die Struktur zu beschreiben, getrennt (abgesehen von HTML-Inseln wie noframes, welche jedoch in sich homogen sind). So könnte man argumentieren, dass Frames und HTML nicht zusammengehören, was sicherlich stimmt, allerdings hatte das auch niemand bezweifelt, formal wurden Frames immer als eigenständig und über die Verantwortung HTMLs hinausgehend bezeichnet. So fragt man sich: Wo ist der Konflikt, wo ist die Vermischung von Präsentationsbeschreibung und logischer Beschreibung angesichts der Tatsache, dass Frames und ferner noch stringenter XFrames immer abseits von der wirklichen logischen Textauszeichnung gehalten werden? CSS ist auch ein zusätzliches »Mittel zur [mitunter] visuellen Gestaltung«, das macht es nicht kritikwürdig.
»Obwohl mit dem Noframes-Element die Möglichkeit existiert, Alternativen für Webbrowser, die keine Frames anzeigen, bereit zu stellen, werden Frames dennoch von vielen Webgestaltern abgelehnt.«
...worauf aber nicht näher eingegangen wird. Die Aussage ließe sich auch auf »Es existieren Möglichkeiten, Frames auch für Browser ohne Frames-Unterstützung oder alternativer Ausgabeweise zugänglich zu machen« oder ähnliches kürzen, würde dann sogar ohne den gezwungenden Impuls in Richtung Überwindung von Frames auskommen und es könnten sich sogar brauchbare Informationen anschließen, eben in die Richtung, wie man denn die Probleme von Frames möglichst minimieren kann; in einer vegangenen Version des Artikels ja von unsachgemäßer Implementierung die Rede.
Mathias