Frames

[molily]

Hallo, Michael,

(...) Es kann nicht wirklich die Rede davon sein, dass Lynx Frames unterstütze. Es wird ein Link zu den einzelnen Frame-Inhalten sowie der Inhalt des 'noframe'-Elements angeboten, mehr nicht.

Das ist ausreichend für die Navigation zwischen den Einzelframes, sie sind somit auf primitive, aber hinreichende Weise zugänglich. Lynx interpretiert das Frameset und setzt die frame-Elemente in Links um - natürlich ist das kein Vergleich zur grafischen Umsetzung von Frames, aber selbst wenn im noframes-Element Quark à la »Diese Seite verwendet Frames. Frames werden von ihrem Browser nicht unterstützt« steht, ist die Seite noch rudimentär benutzbar. Ein Prä-Frames-Browser wäre aufgeschmissen.

Würdest du sagen, dass Screenreader Frames »unterstützen«? Sie erlauben meist das Durchschalten/Wechseln von Frames und dann die einzelne Wiedergabe (springen aber auch bei target automatisch). Sie setzen den Zusammenschluss von Dokumenten natürlich nicht als visuelle, parallele Präsentation um, wie auch, bei akustischer, linearisierter Ausgabe... (Manche Blinde kommen damit sogar ganz gut klar, aber eher weil auf framelosen Seiten Überspringen-Links fehlen und die Navigationen nicht als solche identifizierbar sind, mutmaße ich.)

Sind Suchmaschinen-Robots "gängige Browser"?

Für eine gut gelöste Frames-Seite ist es irrelevant, ob der Client Frames interpretiert oder nicht - sie muss so oder so zugänglich und benutzbar bleiben. Im besten Falle taucht die Kompatibilitätsfrage nicht auf.

Wie kannst du angesichts der vorhandenen Frame-Masse im Web so optimistisch eingestellt sein?

Ich habe vom Optimalfall gesprochen, welcher natürlich von der jetzigen Realität weit entfernt ist, aber durchaus möglich ist. Wenn jemand unbedingt Seiten mit Frames schreiben will, sollte er diese Grundregeln bei der Umsetzung unbedingt berücksichtigen, um zumindest die Symptome einzudämmen.

Insofern kann »manche Suchmaschinen-Robots unterstützen keine Frames« kein Argument gegen Frames sein, weil es bereits davon ausgeht, dass die Frames-Anwendung auf Fehleinschätzungen basiert, nämlich dass die Site mit Frames steht und fällt.

So ist es zumeist, schließlich macht sich kaum ein Webautor die Mühe, zusätzliche Navigationsstrukturen auf den einzelnen Dokumenten anzubieten, und sei es nur ein Link zurück zur Startseite. Als Ergebnis meiner Suche erhalte ich dann einen Link auf ein Dokument, von dem aus ich weder vor noch zurück gelange.

Das muss und sollte aber nicht sein, wie gesagt. Falls diese Verknüpfungen in ausreichendem und passendem Maß existieren (siehe [pref:t=53274&m=294930] und der von dir genannte Artikel), verliert diese Teilproblematik m.E. schnell an Brisanz. (Andere gravierende Nachteile existieren weiterhin, keine Frage.)

Auf eine Kollektion von Frames zu verweisen, also auf ein gesamtes Frameset in einem bestimmten Zustand, können Suchmaschinen ohnehin nicht leisten, auch bei XFrames nicht, von daher ist dies durchaus ein Kritikpunkt.

Das ist sicher eine wichtige Festellung in einer Diskussion, welche generell die Möglichkeiten und Fähigkeiten von HTML-Frames bzw. XFrames auslotet. Eine solche Untersuchung muss immer stattfinden, falls man darüber nachdenkt, Frames zu verwenden. Was du ansprichst, lässt sich tatsächlich nicht bzw. nie lösen, insofern ist es zwingend notwendig, sich nach den erprobten, zuverlässigen und »robusten« Anwendungsfällen zu richten. Das heißt, es ist neben konzeptionellen Nachteilen von Frames insbesondere problematisch, eine Site zu bauen/modellieren, bei welcher die Einzeldokumente nicht außerhalb eines determinierenden Kontexts der (auch logisch/inhaltlich) nebengeordneten Framedokumente stehen können.

In der Regel kommt man so zu dem Fazit, dass sich der Anspruch mit Frames nicht umsetzen lässt und sie somit von vornherein ungeeignet sind. Das stellt natürlich den letztlich auf Wunschdenken basierenden Hauptvorteil von Frames radikal in Frage - nämlich eine sich geschlossene Zusammenstellung von voneinander abhängigen Dokumenten erstellen, bei welchen sich der Sinn und die Aussage der Einzelnoten/-dokumente nur im Zusammenhang (Gewebe/Geflecht) erschließt. Somit sind Frames wenn überhaupt nur für lose, optionale Anordnungen brauchbar. Für die klassischen Primärnavigation-Hauptinhalt-Framesets trifft das unter den genannten Umständen bzw. Einschränkungen sowieso zu, also sofern die genannten Regeln beachtet werden.

(Ich philosophie immer noch über das ideale Hypertextsystem, welches solche Aufgaben der Parallelität löst und gleichzeitig flexibel und benutzbar bleibt. Das WWW eignet sich offensichtlich nicht dazu. Wohingegen ich mir Implementationen von HTML-Frames und XFrames denken könnte, welche browserseitig das Frames-Konzept in Darstellung und Bedienung von Grund auf neudefinieren - die von Netscape erfundene Umsetzung wurde bis heute nicht merklich verbessert. XFrames geht mir sowieso nicht weit genug, abstrahiert nicht, bleibt wieder nur auf der Präsentationsebene, die Kennzeichnung der logischen Struktur und möglichen Ausgabewegen/-vorschlägen fehlt; obwohl doch bspw. XHTML2 das Konzept von typisierten Links und Relationen/Einbettungen generell noch weiter verbessert. Letztlich wird sich nicht viel ändern.)

Grüße,
Mathias