Hellihello Mathias,
"Mit HTML 4.0 wurde wieder mehr Wert auf die Trennung von Inhalt und Präsentation eines HTML-formatierten Textes gelegt. Im HTML-Code sollten nur Elemente verwendet werden, die etwas über die Bedeutung und die Struktur des Textes aussagen."
Das ist keinesfalls komplett korrekt, da sowohl <img> wie auch <script>, <style> und <object> genauso informationsgebende Elemente sind. Information beschränkt sich bei HTML keinsfalls auf Text.
Du musst schon berücksichtigen, was der Autor damit sagen will. Natürlich grenzt sich HTML 4 nicht von object usw. ab, aber doch von denjenigen HTML-Elementen, die als HTML-Elemente die Präsentation beeinflussen.
Naja, mit dieser Aussage hätte ich jetzt, um genau zu sein, zwei "Probleme" - ich habe gelesen, dass die Diskussion für Dich 5-6 Jahre alt, Du Deine Seite dazu gelöscht hast und im Grunde das Thema als abgeschlossen ansiehst. Meine "Probleme" dennoch:
1. Es geht mir ja eigentlich darum, nicht zu berücksichtigen, was der Autor sagen will, sondern zuzusehen, dass das, was "der Autor" sagen will, auch so gesagt wird, wies gemeint ist. Das die Idee hinter dem Pro und Contra. Das auch meine Kritik im Ganzen an dem Artikel: zu weltanschaulich, zu wenig präzise im Detail.
2. Ein img/src ist zwar oft (bei Links) Layout relativ pur. Aber grafische Information (ein Bild von einer Person, eine grafische Darstellung von Verläufen o.ä.) sind ja kein Layout. Das ist Information, wie sie u.U. in Worten nur schwer zu beschreiben ist. "Layout" (s. u.a. auch UML) kann auch Informationsträger sein.
style tut dies nicht direkt, genausowenig wie script es direkt tut, genausowenig wie object andere Inhalte mit dem HTML verschweißt - all diese binden fremde Medientypen ein.
Ja, und Information ist ein Bündel aus Schrift, Audio, Bilder (bewegt und unbewegt).
Das Ideal von HTML 4 ist tatsächlich die Trennung der Sprachen bzw. Logiken. Grafiken, JavaScript und CSS sind nunmal nicht HTML - aber frameset, frames, target usw. sind HTML. Das ist der Punkt.
Mh, irgendwie krieg ich diesen Punkt nicht. 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 w3c schreibt auch bei den Problemen nur von der "usability" (also den Browserschwächen sag ich mal ein wenig pointiert, die mit History und Links nicht zurechtkommen). Es rät sogar zur Alternative Nutzung von <object>.
"Eine FRAMESET-Datei hat dagegen überhaupt keinen Inhalt (der NOFRAMES-Bereich wird von einem FRAMEs-fähigen Browser völlig ignoriert)!"
Es hat genausoviel Inhalt wie o.g. Elemente. Es hat zudem den Inhalt: ich bin zwei oder mehrer Inhalte.
Ja und?
Mh, vielleicht ist dies zurückzuführen auf einen eingeschränkteren oder erweiterten Informationsbegriff. Eine logische Strukturbeziehung zwischen Elementen zB. eines Buches (Umschlag, Klappentext, Titel, sonstige Infos, Inhaltsangabe, Inhalt einzelner Kapitel) ist auch Teil der gesamten Information, würde ich sagen. Die Inhaltsangabe (Menü) hilft zB. ein einzelnes Kapitel (einzelne html-Seiten i.d.Regel) in einen übergeordneten Zusammenhang zu bringen.
Es ist doch egal, dass style und script keinen menschenlesbaren Inhalt im Sinne von natürlichsprachigem Text, Ton oder Bild haben. Sie sind ja auch selbst keine HTML-Dokumente! Das aber sind Framesets, und überhaupt deshalb ist die Inhaltslosigkeit von Relevanz.
Eine HTML-Seite kann ja auch nur ein Bild enthalten. Vergiss bitte auch nicht den Noframes-Bereich. Die Trennung von überwiegend informationsfreiem Layout und Text bezieht sich doch eben auf Text. Aber HTML bleibt HTML, wenn es überwiegend oder nur fremde Quellen einbindet.
Der Text will sagen: Ein »Frameset« bricht mit der klassischen Dokumentvorstellung. Das hat verschiedene Auswirkungen.
Definiere bitte "klassische Dokumentenvorstellung". Beim W3C kann ich das nicht finden. Ich bleibe auch dabei, dass ein Frameset zwischen veschiedenen Elementen auf einer logischen Ebene eine Relation herstellt (Titel, Inhaltsangabe, Kapitel).
Das Einbinden von CSS oder JavaScript *in* ein klassisches Dokument konterkariert nicht dessen Konzept.
"Sie macht ausschliesslich Angaben über die grafische Präsentation anderer Dokumente. Für andere Ausgabemedien als für die hochauflösende Bildschirmdarstellung hat das Frameset keine Bedeutung."
Das ist schlicht unfug. Wie Eric Myer u.a. zeigt, macht es insbesondere dann Sinn, ein Frameset einzusetzten, wenn das Menü sehr viele Einträge hat (ein Übersicht zB. s.a. die Sidebar von Selfhtml u.a.). Ein Frameset lässt sich zudem in der Größe verändern und macht im korrekten Falle genau eine inhaltliche Aussage: zwei Inhalte, die sich in einer 1:n Relation befinden.
Du widersprichst dem Text damit überhaupt nicht, der macht trotzdem seinen Punkt.
Verstehe ich nicht. Ich versuche doch klar zu machen, dass es um einen logischen Zusammenhang geht. Zwei Dinge nebeneinander zu stellen, die sich aufeinander beziehen ist etwas andere als "ausschließlich Angaben über die grafische Präsentation" zu machen. Auch der zweite Satz zum Viewport passt doch irgendwie nicht zum Myer-Beispiel. Die Bedeutung hat doch nichts mit einem großen Viewport zu tun.
Es ist eigentlich egal, was für eine Beziehung zwischen den Inhalten besteht.
Das hätte ich gerne erläutert. Das scheint mir so gesagt eher in Richtung sinnfrei.
Natürlich besteht oft eine inhaltliche Relation, dazu setzt man Frames schließlich ein.
Naja, das meine ich ja, als einen Punkt unter einigen.
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. Genau dafür ist HTML da. Eine Ebene über dem Verhältnis <h1> zu <h2> zu <p>. Abgesehen davon, dass ohne jegliches Layout, wenn ich den Quelltext nicht lesen würde (s.a. titles der Frames), auch h1, h2 und p keinen Sinn machen würden. Layout ist einfach auch informationsgebend.
Sie können prinzipiell keine inhaltlich-semantische Relation ausdrücken.
Naja, wie gesagt, das wäre genau aus meiner Sicht der interssante Punkt.
DESHALB gilt eben, dass Framesets für andere Ausgabemedien, die der Darstellung nicht fähig sind, nichts sagen (und eine Navigation deshalb schwierig ist, weil der Benutzer erstmal die Relation selbst herausfinden muss, was je nach Zugangstechnik ziemlich schwierig ist).
Verstehe ich nicht, was Du meinst. Mit Vorlesegeräten kommst Du bei korrekter semantischer Zuordnung sehr gut damit zurecht, so meine Info. Zudem ist das "Layout" noch für den User (also an den Viewport) anpassbar. Was denn zB mit einer Tabelle, die Bilder (vorher - nachher) gegenüberstellt. Auch so eine logische Relation.
Denn mehr als die bloße Darstellung drücken sie nicht aus.
Naja, jetzt kreist es.
"Das FRAMESET ist ein toter Container, der nichts von seinen Inhalten weiß."
Genau wie ein <img> oder <objekt>. Es gibt eben auch nichtschriftliche Inforamtion.
Du widersprichst wieder einer Aussage, die gar nicht gemacht wurde.
Das kapier ich nicht. 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. Komisch, dass manche Menschen Dinge nichtssagend finden, die mir erstmal was sagen. Vielleicht hör ich ja Stimmen?
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? Das klingt für mich so, als wenn die Elemente eines Hashes keine Hashes selbst ein dürften.
Ein Frameset ist aber ein eigenständiges HTML-Dokument. (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 und sich nicht "versteckt" (ich weiß, das klingt gemein, soll pointiert gemeint sein) hinter einer vorgeblich ewig veralteten Dokumentation. Ich fände, es wäre für diese Neverending Story ein Ending, wenn es hier einen aktuellen Artikel dazu gäbe.
Diese Aussage findet sich auch nirgends beim W3C.
Was für ein Argument... ;)
Nun, über den Tellerrand zu schaun, oder was? (;-). 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.
Ich kann doch gerade und nur beim Frameset das selbst sofort anpassen, sogar das Menü wegschieben um mehr Platz für den Inhalt zu haben bzw. es aufziehen, wenn ich zu einem weiteren Thema den Menüpunkt suche.
Bei integrierten Navigationen kann man auch durch Scrollen das Menü wegschieben bzw. in den Fokus holen... Ist nix spezifisches.
Naja, ich muss den Inhalt scrollen, um das Menü zu sehen. 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. Vor dem <h1>? Wohl kaum, denn vor dem <h1> kann nichts stehen, sonst wäre es ja nicht die <h1>. Dannach? Auch nicht, denn die Inhaltsübersicht ist ja kein inhaltlicher Teil von <h1>Nahrung<h1> auf meiner Unter(!)- Seite in meinem HTML-Seite über "Meerschweinchen".
Dank und Gruß,
frankx
Gunnar Bittersmann
Struppi
molily
