nicht angemeldet
Hallo, Michael,
Würdest du sagen, dass Screenreader Frames »unterstützen«?
Nicht auf eine Art und Weise, wie ein Webdesigner sich das vorstellt.
Natürlich nicht, darum ging es mir nicht, sondern um die Art und Weise der alternativen Interpretation sowie deren Benutzbarkeit. Und bei Screenreadern existiert meiner Meinung nach eine solche alternative, das Framekonzept annähernd wiedergebende Umsetzung, sofern man Vergleiche ziehen kann.
(Hier besteht ein Bezug zu XFrames, dort werden solche Alternativumsetzungen explizit genannt, siehe weiter unten.)
Frames sind für grafische Benutzerargenten gedacht, vielmehr noch, für Benutzeragenten, die über eine ausreichend dimensionierte Anzeigefläche verfügen, um die Layoutvorstellungen des Designers entsprechend umzusetzen. Die Darstellung in Textbrowsern gleich welcher Art ist nicht viel mehr als ein Kompromiss, um die Zugänglichkeit der einzelnen Dokumente zu gewährleisten.
»Große« Browser mit angeschlossener Sprach- oder Brailleausgabe setzen Frames letztlich vollkommen anders um als Textbrowser und somit ist die Qualität der »Unterstützung« eine grundsätzlich andere, insofern ist »gleich welcher Art« eine extrem vereinfachende Aussage.
Die gängigen Screenreader linearisieren ein Frameset nicht im Sinne von Textbrowsern, welche das Parallelkonzept von Frames gänzlich ignorieren, daher mein Beispiel. Etwas wie das angesprochene Durchschalten der Frames und das Interpretieren von target und Cross-Frame-Scripten können existierende Textbrowser wie Lynx und w3m nicht. Das wäre prinzipiell durchaus denkbar, wenn auch schwer umsetzbar bzw. letztlich schwer benutzbar. (Der Textbrowser Links setzt Frames zwar genauso wie grafische Browser um, erlaubt auch das Durchschalten, ist aber vermutlich extrem schlecht im Zusammenhang mit einem Screenreader nutzbar, für einen Sehenden mit Maus aber durchaus.)
(...) Wenn jemand unbedingt Seiten mit Frames schreiben will, sollte er diese Grundregeln bei der Umsetzung unbedingt berücksichtigen, um zumindest die Symptome einzudämmen.
Die Erfahrung zeigt, dass das nicht getan wird. Offensichtlich ist das zu arbeitsaufwändig.
Ja, und das Problem der Faulheit und Unwissenheit der Autoren wird sich bei XFrames nur verschlimmern, schließlich muss dort zwangsläufig noch aufwändiger (content negotiation, serverseitige Intelligenz) eine Extraversion für nicht XFrames-fähige Browser geschrieben bzw. generiert werden.
Was du ansprichst, lässt sich tatsächlich nicht bzw. nie lösen. (...) 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.
Solange es keine Möglichkeit gibt, Dokumenten die Angabe ihres Framekontexts zu ermöglichen, wird dieses Problem bestehen bleiben, ganz gleich, welche Konzepte und Möglichkeiten das Frameset an sich bietet.
So etwas erwarte ich beispielsweise von XFrames, und wenn es auch vorläufig nur etwas wie <link rel="frameset" href="frameset.xfm#frameset(navigation=navigation.html,inhalt=diesesdokument.html)" /> ist. Wenn die XFrames-Spezifikation eine solche Empfehlung beinhaltete, wäre viel gewonnen, da die Browser daraus ein Dialogfeld wie »Dieses Dokument ist Teil einer Zusammenstellung von Dokumenten in einem Frameset. Soll es im Gesamtkontext angezeigt werden?« machen könnten. Wieso kommt niemand auf diese triviale Idee? Die Zusatznavigation auf Unterseiten spart man dadurch natürlich nicht ein (solange link-Elemente nicht zuverlässig sind).
Jenseits von HTML-Frames und XFrames finde ich die generelle Kennzeichnung solcher Beziehungen viel spannender: Die Angabe des Kontexts (logisch, nicht nur physisch) eines Dokuments ist prinzipiell schon heute über link-Elemente möglich und Verweise lassen sich ebenfalls mit rel/rev auszeichnen. Konsequent angewendet stehen Browsern und verarbeitenden Programmen wertvolle Zusatzdaten und dem Benutzer theoretisch brauchbare Navigationshilfen zur Verfügung. Bei solchen extrem verwobenenen Dokumentstrukturen könnten Browser spezielle, den jeweiligen Knotentypen und der jeweiligen Linksemantik angemessene Darstellungstechniken zurückgreifen beziehungsweise sie als Alternativen anbieten.
Dies ist heute bei den eher zurückhaltenden Navigationsleisten, welche die link-Elemente umsetzen, nicht der Fall, aber durchaus mit (X)HTML umsetzbar. Angenommen, der Autor erstellt Dokumente hinreichend flexibel, so könnte beispielsweise ein Glossar-Dokument oder ähnliches durchaus eigenständig durch eine Browserfunktion in einem nebenstehenden Bereich angezeigt werden, sofern es der Benutzer möchte (ohne dass man von Hand Fenster/Tabs nebeneinander positioniert). Ein anderes konkretes Beispiel würde auf die heutige Verwendung von target="_blank" abzielen: Auch wenn es ein reines die Präsentation steuerndes Attribut ist, liegt meist durchaus eine gewisse logische Bedeutung zugrunde, welche sich durch Linktypen in den rel- und rev-Attributen ausdrücken ließe. Etwas wie rel="external" ist oft im Gespräch, und wenn solche Linktypen standardisiert beziehungsweise konsensuell erarbeitet und implementiert werden, liegt es nahe, entsprechende Einstellungen in die Browser einzubauen, durch welche der Benutzer wählen kann, ob externe Links immer, nie oder nur auf Wunsch in neuen Fenstern/Tabs oder auf welche Weise auch immer angewählt werden (oder wie auch immer gekennzeichnet werden). Für andere Linktypen ist ähnliches denkbar.
Momentan werden rel-Attribute in der Regel nicht visualisiert bzw. der Beziehungstyp hat keine wie auch immer gearteten Auswirkungen, ich sehe da durchaus viel Entwicklungspotenzial und auch Notwendigkeit. Die nötige Technik steht seit HTML 2 zur Verfügung und bisher hat sich nichts innovatives getan auf Seiten der Browser. Das Ignorieren der link-Elemente nach Mosaic war sogar ein Rückschritt.
XFrames geht mir sowieso nicht weit genug, abstrahiert nicht, bleibt wieder nur auf der Präsentationsebene,
Die Beschreibung einer Anordnung separater Dokumente in geordneten Fensterrahmen ist per se eine Beschreibung der Präsentation. Was erwartest du von XFrames?
Ich erwarte Umdenken. Ich denke nicht, dass die Welt einen so gearteten XFrames-Standard braucht. XFrames löst die grundlegenden Probleme im Konzept und in den Implementationen von HTML-Frames nicht, was momentan versucht wird, ist Flickschusterei. Ich sehe immer noch kein ganzheitliches, ausgeklügelte Konzept. Da wären mir Praxisuntersuchungen und -empfehlungen, Best-Practice-Beispiele und Referenzimplementationen von HTML-Frames lieber (ja, ist nicht die Aufgabe vom W3C, das W3C hat aber den Anspruch, pratikable Techniken für das Web zu erarbeitet).
Da heißt es in im XFrames-Entwurf (in der HTML4-Spec steht etwas ähnliches) beim einzigen Ansatz der Abstraktion nur heuchlerisch: »The individual sub-documents ('frames') may be composed together [in der gewohnten Spalten/Zeilen-Anordnung] or they may be displayed as separate movable window-like panes, or as tabbed panes, or in any other suitable manner.« - Als ob die Welt je ein XFrames-Frameset ohne column- und row-Elementen erleben wird! Als ob die »other suitable manner« die Tür öffnet für zig unterschiedliche Umsetzungen, als wären XFrames gar ausgabeunabhängig, als wäre ein Frameset gar nur eine Präsentationsempfehlung, welche individuell von von Ausgabesystem zu Ausgabesystem, von Benutzer zu Benutzer anders interpretiert wird. Das suggeriert fast schon Anpassungsfähigkeit und Anspruchslosigkeit, als ob die Erfahrung mit HTML4-Frames nicht das Gegenteil bewiesen hätte. Als ob es je solche Implementationen geben wird, wo doch sowieso eine Zwangstrennung und gesonderte Behandlung von Browsern, welche XFrames nach den üblichen HTML-Frames-Kriterien (ausreichend Platz für die direkte Paralleldarstellung usw., wie du sagst) und Browsern, die diese Anforderungen nicht exakt erfüllen, vorgesehen ist.
Eine mögliche Abstraktionsebene wäre, anstatt einer Präsentationssprache wie XFrames eine Metadaten-Sprache im Sinne des semantischen Webs zu entwickeln, welche die Beziehungen der Knoten untereinander logisch beschreibt. Ein Browser *könnte* daraus dann eine Parallelpräsentation mehrerer Dokumente machen, sofern es die Umstände zulassen und der Benutzer es frei wählt (!) und somit die volle Kontrolle behält (und der Browser durch eingebaute Methoden eben erlaubt, die Dokumente einzeln anzuzeigen, die Adresse in Erfahrung zu bringen, zwischen den Ansichten zu wechseln und beliebig anzupassen usw.). Die Metadaten ließen sich vielfältig verwenden, beispielsweise um eine dem Ausgabemedium und dem Benutzer angemessene Repräsentation der Knotenbeziehungen zu erstellen, welche als flexible Sitemap dienen könnte und perfekt navigierbar wäre (verschachtelte Listen, welche Sitestrukturen abbilden, lassen sich beispielsweise in Screenreadern schlecht aufnehmen und verstehen, aber vielleicht bin ich als Sehender auch ungeübt...).
Ist nicht RDF gedacht, eine solche Sitearchitektur wiederzugeben? Wäre das geeignet? Ich habe mich nur oberflächlich damit befasst. XML Topic Maps scheinen mir auch interessant.
Grüße,
Mathias