nicht angemeldet
Hellihello Mathias,
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.
Nun schon das Wort "Meta" ließe ja zumindest den Gedanken nach inhaltlicher Aussage mal kurz aufkeimen. Ich male ein Haus, nur den "body". Ich male ein Dach, darüber. Das ist keine Frage des Layouts, sondern des logischen Bezuges. Eine Tabelle setzt Dinge in einen logischen Bezug, weil es sie übereinander und nebeneinander stehen. Das ist ein Teil der Information, meiner bescheidenen Meinung nach. Ein Frameset, mal so angerissen, dann etwas wie eine "Meta"-Tabelle.
Definiere bitte "klassische Dokumentenvorstellung". Beim W3C kann ich das nicht finden.
Es ist all das, was du beim W3C findest (Strict, Transitional), ausgenommen Frameset.
Ums jetzt mal genau zu nehmen: definiert das W3C das so oder ist das Deine "willkürliche" (;-) Definition?
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.)
Mh, haben nur die Menschen oder die Browser die Probleme. Die Relationen innerhalb einer Tabelle stelle auch ich als Autor her. Der Browser weiß nur, dass er <th> mal dick schreiben soll, thats all, wenns <th> überhaupt gibt.
Die Aussage des Textes ist aber, dass diese Relation nicht im Frameset ausgedrückt ist. Darin stehen nur Elemente, die eine grafische Anordnung definieren.
s.o. Grafische Anordnung (mbMn) = Information
<table>
<tr>
<td>
<img title="Auto vor dem Unfall" src="auto_vor_unfall.jpg">
</td>
<td>
<img title="Auto nach dem Unfall" src="auto_nach_unfall.jpg">
</td>
</tr>
</table>
Der Browser (Maschinenlesbarkeit) weiß nur, ob er irgendwo Linien malen darf und was rechts, links, oben, unten hinkommt. Browser können auch xml anzeigen, und verstehen ohne Stylessheet nur, dass es xml ist.
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.
Nee, aber alle anderen, zb http://www.w3c.de/Trans/WAI/webinhalt.html#tech-frame-longdesc: "Beschreiben Sie den Zweck von Frames und ihre Beziehung untereinander" . Ein HTML-Client weiß nicht, was ein <h1> bedeutet. Er weiß auch nicht, was <autor> bedeutet.
Er kann letzteres dem Benutzer kommunizieren
Das halte ich für gewagt. Der Client kommuniziert (s.o.) garnicht, er kann "nur" Layouten.
und der muss sehen, was er damit anfängt.
Hups, da steht ja was nebeneinander, und was darüber, das bedeutet: oben der Titel, links die Navi (;-).
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.
Die kann er auch sonst nicht anbieten. Er verfügt über eine internes Default-Stylesheet bezogen auf HTML-Syntax, das wars.
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.
Und nur der User zählt, oder?
"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.
"Hypertext bedeutet nicht nur, dem Anwender per Mausklick weitere Informationen zur Verfügung zu stellen, sondern auch, dem Anwender die Möglichkeit zu bieten, sich selbst Informationen so zusammenzustellen, dass er sie optimal miteinander vergleichen und daraus Schlüsse oder Entscheidungen ableiten kann. Zu diesem Zweck eignet sich die Frame-Technik hervorragend, da sie es erlaubt, verschiedene, getrennt voneinander gespeicherte Informationen auf Anwenderwunsch gleichzeitig anzuzeigen."
http://de.selfhtml.org/html/frames/layouts.htm ???
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«.
Nun, in der Regel weiß die Navi, was im Content steht, oder?
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.
Das hab ich jetzt nicht ganz kapiert.
(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.)
Na, es wird natürlihc etwas haarspalterisch, aber ich meine, das ist der oder ein "Kern" der Diskussion.
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.
Nicht normativ. Informativ wie immer. Bisher konnte ich immer noch SELFHTML zitieren mit "Durch den Einsatz von Frames wachsen die Gestaltungsmöglichkeiten außerordentlich. Frames stellen an das Design von HTML-Seiten aber auch besonders hohe Ansprüche." Aber das finde ich grad nicht mehr. Da hieß es immer, das sei "uralt".
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.
Deshalb ja mein Vorschlag, das irgendwie so mal mit "Pro" und "Contra" zu notieren. http://vergessichnicht.de/Frames_Pro_und_Contra als Ideen- und Linksammlung ist mitgewachsen ein bisschen.
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.
Jenau.
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.
Dazu führe bitte die entsprechende Richtlinie des WAI an. Ich kann das meiner bisherigen Recherche nach nicht bestätigen.
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.
Genau. Bei meinem nächsten Roman - würde ich je einen schreiben - lass ich dann die Inhaltsangabe auf jede Seite mitdrucken anstelle einer praktischen ausklappbaren Inhaltsangabe (;-).
Dank und Gruß,
frankx
Gunnar Bittersmann
Struppi