nicht angemeldet
Hallo,
Das Element, ob object, img oder iframe oder frame verweist auf eine Quelle. Einmal ein Flashfilm, einmal ein Bild, einmal ein animiertes GiF, einmal ein weiterer HTML-Quelltext. Ich finde das logisch einwandfrei.
Das Problem ist weniger, Daten in ein Dokument einzubinden. (Bzw. das wird durchaus ein Problem, wenn HTML-Dokumente in HTML-Dokumente eingebunden werden - weil diese schwer adressierbar sind usw.) Das ist wie gesagt das klassische Modell. Ein Frameset hingegen ist nur ein Meta-Dokument, das bloß auf Inhalte verweist - und zwar nicht, um diese inhaltlich, sondern hinsichtlich der Präsentation aufeinander zu beziehen.
Definiere bitte "klassische Dokumentenvorstellung". Beim W3C kann ich das nicht finden.
Es ist all das, was du beim W3C findest (Strict, Transitional), ausgenommen Frameset.
Ich bleibe auch dabei, dass ein Frameset zwischen veschiedenen Elementen auf einer logischen Ebene eine Relation herstellt (Titel, Inhaltsangabe, Kapitel).
Um mich zu wiederholen: Die Relation stellst du als Autor *mit* dem Frameset her. Sie steht aber nicht im Frameset drin - damit meine ich: nicht maschinenlesbar. HTML kann solche Beziehungen nicht ausdrücken. Wenn das angelegt wäre (nunja, es gibt link-Relations, sagen wir einmal: von Browsern sinnvoll implementiert), gäbe es viele Probleme von Frames nicht. (XFrames hatte den Anspruch, einiges davon umzusetzen.)
Die Aussage des Textes ist aber, dass diese Relation nicht im Frameset ausgedrückt ist. Darin stehen nur Elemente, die eine grafische Anordnung definieren.
Da sage ich mal, das ist schlicht falsch. Wenn ich title="Logo", title="Menue" title="Content" angebe, ist das ein logischer Zusammenhang.
Nochmal: Ein HTML-Client kann sich nicht dafür interessieren, was für eine Logik du dir »dabei gedacht hast« oder auch mit natürlicher Sprache in Form von title im Frameset untergebracht hast. Er kann letzteres dem Benutzer kommunizieren und der muss sehen, was er damit anfängt. Das ist ganz ok, aber schon alles. Der Client selbst *versteht* sie nicht und kann deshalb ggf. auch keine automatische sinnvolle Linearisierung der Frameset-Struktur bieten.
Mit Vorlesegeräten kommst Du bei korrekter semantischer Zuordnung sehr gut damit zurecht, so meine Info.
Genau, ich als User, der die Verbindung nachvollziehen muss.
"Das FRAMESET ist ein toter Container, der nichts von seinen Inhalten weiß."
...
Das Auslesen des Inhaltes des src-Attributes eines img bringt mir erstmal genausoviel "meta" Info wie das Auslesen des src-Attributes eines frames. title und alt Tags helfen dann schon weiter.
Was ich die ganze Zeit sagen will: Wenn ich in einem Dokument, sagen wir mal, so in textlastiges aus SELFHTML, eine Grafik einbinde, dann ist die natürlich ein eigenständiger Informationsträger. Aber das einbindende Dokument ist (i.d.R.) keine bloße Liste, die Grafiken visuell anordnet und gruppiert. Schon gar nicht ist es ein eigener Dokumenttyp, der nichts anderes als diese Anordnung leisten soll. Das ist mit »toter Container« gemeint.
Wenn ich eine Grafik einbinde, so weiß ich zudem um deren Inhalt, bei HTML-Dokumenten ist das etwas anderes, weil ich damit ein neues Universum aufmache, nämlich eine eigene Browsing-Instanz einbaue. In dem Unterfenster kann alles mögliche passieren, die einbindende Browsing-Instanz weiß davon nix. So verstehe ich »nichts von seinen Inhalten wissen«.
object ist Bestandteil eines klassischen HTML-Dokuments und das ist in diesem Kontext völlig konsistent: Ein Dokument verweist auf andere Medien in einem bestimmten inhaltlichen Kontext.
Und ein HTML-Dokument ist kein Medium?
Habe ich doch überhaupt nicht ausgeschlossen. Aber in dem speziellen Fall treten halt die Probleme von Frames auf, insbesondere wenn der »bestimmte inhaltliche Kontext« einfach nicht existiert, weil da bloß eine Art Verweis steht.
(Jetzt könnte man natürlich drüber diskutieren, ob ein Dokument nur mit ein paar objects, die mit CSS über den Bildschirm geklebt werden, noch ein klassisches Dokument ist und was den Unterschied zum »toten Container« macht.)
Jap, fände ich gut, wenn das mal ausdiskutiert wird, SELFHTML hier eine Position bezieht
Es ist ja nicht so, als würde es hier nur um Frames gehen. Tote Container, die nur einbinden und verweisen, während das Eingebundene und Verwiesene dem üblichen Zugriff entzogen wird, haben wir allerorten im Web.
Frames machen Navigation im Web schwer, weil sie das Konzept aufweichen, dass definierte Informationen als Hypertext-Knoten adressierbar sind (Subotnik: »Normalerweise zeigt ein Browserfenster ein HTML-Dokument an.«). Das wird eigentlich massiv und auf breiter Ebene immer wieder aufgeweicht, insbesondere durch clientseitig aktive Logik wie JavaScript / AJAX / Rich Internet Application / Single Page Application etc. pp. Das Web ist heutzutage eine Plattform und nicht bloß ein Netzwerk von atomaren, verknüpften Hypertext-Einheiten (Dokumenten bzw. deren adressierbaren Teilen).
Nach wie vor gilt, dass das Web - egal, was man daraus macht - immer AUCH als Hypertext-Netzwerk verarbeitet wird, wo nur einzelne, lose Dokumente und Hyperlinks dazwischen eine Rolle spielen. Damit sollte man rechnen. Trotzdem gab es und gibt es allerorten Tendenzen, die dem entgegenlaufen. Das verbessert die Usability mal, mal schmälert sie sie gleichzeitig, jedenfalls macht dies der Zugänglichkeit oft den Garaus - beziehungsweise das Feld ist einfach noch nicht erforscht.
Ich weiß wirklich nicht, wie man dazu etwas Normatives schreiben soll. Mir scheint, dass dieser Widerstreit bei allem technischen Wandel über Jahre hinweg bestehen bleibt. Er ist auch nicht einseitig aufzulösen und es gibt auch keine allgemeine Synthese. Ich denke nicht, dass diese Story in Kürze ein Ende finden wird. Ein Artikel könnte höchstens den Widerstreit beschreiben, den man schon seit Anbeginn des Webs beobachten kann, aber doch keinen Schlussstrich ziehen.
Bei einem Pro und Contra gehört für mich mindestens dazu, dass framesets weder "deprecated" sind noch "accessibility"-probleme haben. Zwei wichtige Gründe für mich zumindest.
Frames sind nicht einfach neutral in Bezug auf Accessibility.
Für mich spitzt sich das in der Frage zu, wo denn die <ul class="menu"> denn im semantisch wohlsortierten HTML-Dokument seien Platz hat.
Auf die Frage hat sich die Frames-Debatte schon früher zugespitzt...
Die klassische »Menüleiste« hat im HTML-Dokument gar keinen Platz, <http://forum.de.selfhtml.org/archiv/2003/12/t67816/@tite=sagte emu mal>.
Deshalb kommt man überhaupt auf die naheliegendere und gleichzeitig widersinnige und praktisch verhängnisvolle Idee, so etwas wie »Navigationen« in eigene Dokumente auszulagern, die dann aber wiederum durch Framesets lose an das Dokument zu koppeln oder mit object einzubinden... Dass das Ergebnis unbefriedigend ist, kommt nicht von ungefähr. Das ist so falsch bzw. inkonsistent, dass nicht einmal das Gegenteil (wiederholte »Navigationsleisten« in jedem Dokument) richtig ist.
Mathias
Gunnar Bittersmann
Struppi