nicht angemeldet
Hellihello Gunnar,
Nun, um zu sagen, was mit Frames möglich ist, was mit anderen Techniken nicht möglich ist, braucht es keine schlüssigen Argumente.
Äh, doch. Womit willst du sonst überzeugen, wenn nicht mit Argumenten?
Na Fakten, dachte ich (;-).
Frames bieten die Möglichkeit:
- verschieden Fenster zu öffnen bzw. u.U. sogar logisch voneinander unabhängige Inhalte zu präsentieren.
Richtig, genau das ist eine sinvolle Anwendung von Framesets (wenn man es dem Benutzer nicht selbst überlassen möchte, die verschiedenen Dokumente in verschiedenen Fenstern/Tabs darzustellen).
Gut, also 1 Argument. BTW: kannst Du in Deinem Browser zwei Tabs nebeneinander darstellen? Ich wünschte mir Deine Gewissenhaftigkeit auch für die Argumente der "Gegenseite".
Was ein N00bie aber mit Frames vorhat zu tun, ist die Aufsplittung _eines_ Dokuments. Dafür sind Frames denkbar schlecht.
Unterstellung 1., 2. egal, denn es geht aktuell hier darum, was Frames können was anderes nicht kann. Und vergiss bitte nicht auch, dass der Autor auch einen berechtigten Willen hat. Er ist nicht Sklave eines imaginären MonsterUsers.
- dem User die Möglichkeit zu geben, diese in der größe anzupassen
Ist das sinnvoll? Ja, durchaus.
Es ist egal, ob das sinnvoll ist. Die Frage war: was können Frames, was zB SSI nicht kann.
Wenn ein Nutzer gerade nicht navigieren will, sondern den Seiteninhalt lesen, könnte er aus Platzgründen die (seitliche) Navigation ausblenden wollen. Diese Funktionalität ist aber durchaus auch mit JavaScript zu realisieren, dafür braucht es keine Frames.
Wieder bitte die enstprechende Sorgfalt: Javascript baut auf HTML auf. Was ist, wenn JS deaktivert ist (lol)?
- sind die ursprüngliche Lösung für das "Problem" mehrere unabhängig voneinanders scrollbaren Bereiche.
Auch das geht ohne Frames mit CSS.
Nein, zumindest nicht die Aufteilung Header fixe Höhe, Footer fixe Breite, Navi-links und News-rechts fixe Breite, Content den Rest in der Mitte, Scrollbar für den Content im Content-Fenster und sonst nirgends. (Ich habe nur abgespeichert, dass nicht jede erdenkliche Framelösung 1:1 mit CSS umsetzbar ist, bitte korrigiere mich, am besten mit Link wenn möglich).
- erlauben includen von HTML mit HTML - keine weitere "serverseitige" Technik nötig. Alles was ich brauch, ist ein Texteditor und ein Browser.
Wo ist das Problem, sich Webspace mit SSI/PHP/… zu besorgen?
Ich glaube nicht, dass wir hier pauschal finanzielle und technische Überlegungen diskutieren, am besten für die zig Millionen Webseitenersteller gleich mit. Bleibe doch bitte bei Deiner Frage und weiche nicht aus, indem du sagst, dass es mit eine bisschen Geld/Technik auch anders geht. Auf den Schulrechnern ist kein PHP installiert. Es ist kein öffentlicher Webspace. Da kann ich das mit den Gegebenheiten (erstmal) nur mit Frames. Das war ja auch Deine Frage.
Wo ist das Problem, einen Editor zu benutzen, der Inhalte aus anderen Dateien dynamisch ins zu bearbeitende Dokument einfügt?
Willst Du mir oder anderen vorschreiben, welchen Editor sie benutzen sollen? Notepad ist cool.
Ein Webseitenautor sollte die richtigen Werkzeuge wählen und nutzen, nicht sich hinter seinen ungeeigneten Werkzeugen verstecken und deren Mängel auf die Nutzer abwälzen.
Diesen Punkt hatten wir beide schon öfter. Dirk Schürjohann hat auch einen schönen Artikel geschrieben dazu im Weblog. Es gibt nicht "den Webseitenautor", gar einen Stand, der sich gewissen Prämissen zu beugen hat. Alles mündige Bürger im Wesentlichen meine ich.
- Navigation und Inhalt logisch-semantisch stringent in zwei Dokumenten darzustellen. Navi ist Kapitelliste <h1>Inhalt</h1><ul class="navigation"><li>...</li></ul>, Inhalt ist wirklich nur Inhalt, ohne Kapitelliste o.ä..
Was hat denn Dein drüber Schlafen zu letztem Punkt gebracht?
(Gähn) Oh, schon so spät? |-)
Deine Bedenken, dass die Navigation nicht zum Hauptinhalt gehört und gleichberechtigt neben (im Sinne des Elementbaums) dessen Überschrift und Textabsätzen stehen sollte, kann ich nachvollziehen.
Andererseits beschreibt HTML nicht nur den Hauptinhalt, sondern eine gesamte Webseite, und da gehört die Navigation zu anderen Seiten mit dazu (sonst würde das H im HTML seinen Sinn verlieren). Und die Links zu anderen Seiten finden sich sinnvollerweise nicht nur im Fließtext, sondern auch in einem Navigationsmenü.
Eine Webseite umfasst also neben ihrem Hauptinhalt auch ein Navigationsmenü; beides gehört zusammen in _ein_ Dokument, das die gesamte Webseite beschreibt.
Du willst nun Navigation und Hauptinhalt trennen? Dazu müssen sie nicht in zwei Dokumente getrennt werden; sie können zwei Knoten im selben Dokument sein (was oft sowieso gemacht wird; es ist für die Formatierung mit CSS nützlich):
<body>
<ul id="Navigation">
<li><a href="foo">Foo</a></li>
<li><a href="bar">Bar</a></li>
</ul>
<div id="Inhalt">
<h1>Lorem ipsum</h1>
<p>Lorem ipsum dolor sit amet.</p>
</div>
</body>
Nope. Dieses div ist für den hier viel erwähnten Client so nichtssagend wie ein frameset, noch nichtssagender eigentlich. <section> gibts ja noch nicht. Das o.g. ist in meinen Augen ein Workarround für ein Frameset.
>
> Und schon steht die Navigation nicht gleichberechtigt neben Überschrift und Textabsätzen des Hauptinhalts, sondern ist fein säuberlich von diesem getrennt.
Wie gesagt, beim nächsten Roman lass ich auf jede Seite oben links das Inhaltsverzeichnis drucken (;-).
>
> See ya up the road,
Yup, seeya;
frankx
Gunnar Bittersmann
Struppi