Ein CMS und Frames? Meistens sinnlos - aber eben nicht immer.

Frames haben – neben ein paar Nachteilen – einen gewichtigen Vorteil: Ein Video, eine Flash-Präsentation, ein Spiel oder schlichtweg nur Musik läuft ungestört und durchgehend weiter, auch wenn im Hauptbereich die Seite geblättert wird. Das geht NUR mit Frames.
Eine Anleitung mitsamt Template.

Siehe auch:

Angela Berann Schlagzeugerin und Künstlerin in Wien

Musik auf der Website Durchgehende Musik ohne Ruckler - wie geht das?

Hoverster.net Durchgeknalltes 3D Online-Game

Demo: Ein Template mit Frames

Frames sind eigentlich nahtlos aneinander gelegte, einzelne Fenster, die voneinander unabhängig sind. Wird in einem der Frames die Seite gewechselt, spielt zB. eine Flash-Animation im anderen Frame rucklos weiter. Es gibt keine Möglichkeit, das anders zu erreichen als mit Frames.
Natürlich können sich – auf Wunsch – die Frames gegenseitig beeinflussen; etwa kann Frame A seinen Inhalt ändern, wenn Frame B auf eine bestimmte Seite geblättert wurde.

Die Nachteile von Frames

Gleich soviel: Was in den Foren herumgequatscht wird, ist oft haarsträubender Unsinn, nachgeplappert von Leuten, die keine Ahnung haben. Frames sind eine Besonderheit und müssen richtig gemacht sein, sonst bekommt man die Nachteile natürlich voll zu spüren.

Der wirklich wesentliche Nachteil von Frames ist, dass eine Seite keine eindeutige, direkte URL hat. Das ist bei kleineren Seiten (<100 Unterseiten) oder je nach Inhalt der Seite nicht so schlimm. Kurz gefragt: Wie wichtig ist es, dass einzelne Unterseiten direkt von anderen Seiten aus verlinkt werden können? Oder sollen/können Besucher von der Hauptseite aus schnell das Wesentliche finden?
So verwendete zb orf.at – die Seite des Österreichischen Staatsfernsehens – lange Frames, weil sich Besucher im wesentlichen für die News auf der Startseite interessieren. Außerdem bleibt die Werbung ununterbrochen, wenn Besucher diese News aufrufen.

Ein weiterer Nachteil ist, dass einige  Scripte für Lightbox usw ihre "Grenzen nicht kennen" und sich weiter ausdehnen als erlaubt. Dazu muss man wissen: Ein Element einer Seite = eines Frames kann nicht in eine andere hineinragen, es sind eben verschiedene Fenster. Die maximale Bildgröße ist immer auf die Größe des jeweiligen Frames beschränkt. Manche Lightbox-Scripte messen falsch und fallen dann aus dem Rahmen. Aber: Viele messen richtig und verhalten sich entsprechend.

Einige weitere der Nachteile sind nicht so schwer oder überhaupt "relativ". Was Suchmaschinen betrifft galten Frames lange als Googles Lieblinge, mittlerweile werden sie neutral behandelt.

Das Template "2frames"

Template mit Frames

Websitebaker und Frames:

Der Sinn der Sache: Im linken Frame kann etwas (im Demo ein Musik-Video) durchgehend laufen, während im Hauptbereich die Site durchstöbert werden kann.

Demoansicht: 2frames

 

Ein typischer Fall: Musik auf der Website. Diese läuft weiter, während man sich durch die Seiten klickt.

Onlinegame Hoverster

Auch das geht nur mit Frames: Im oberen Frame ist der Shockwave-Detector, der Preloader und dann natürlich das Spiel selbst untergebracht. Darunter eine "normale" WebsiteBaker Site. Sobald einer der Levels gestartet wird, schaltet das Spiel auf die zugehörige Seite.

 

Zwecks Narrensicherheit habe ich es als "Template im Template" gemacht. Es wird abgefragt, ob die aufgerufene Seite die Startseite ist oder nicht. Je nachdem ist die Ausgabe völlig verschieden.
Bei der Startseite (!$page_id) wird das Frameset ausgegeben. Vorher wird abgefragt, welche Seite eigentlich die ursprüngliche Startseite ist, und diese wird dann in den Hauptbereich der Startseite geladen. Es folgt also sofort ein 2. Aufruf, eben diese.
Alle weiteren Seiten verhalten sich genauso. Die Seite im 2. Frame hingegen ist eine banale statische Seite, in die gesteckt wird was da eben sein soll.

Menü und Targets

Gleich vorweg: Das Menü befindet sich auf der Hauptseite im Hauptframe – aus guten Grund. Eine Trennung von Menü und Inhalt macht in einem CMS keinerlei Sinn, im Gegenteil: Es macht Ärger, Ärger, Ärger. Außerdem muss man bei Frames immer darauf achten, dass die Site auch funktioniert, wenn – warum auch immer – das Frameset nicht vorhanden ist. Dann sieht ein Besucher eben nur den Hauptinhalt. Wenn da auch das Menü ist, kann er trotzdem normal navigieren und es wird ihm oft gar nicht auffallen, dass etwas fehlt.
Und zum dritten kommen alle kolportierten Probleme mit Suchmaschinen daher, dass Seiten im "Leeren hängen", also keine Links zu anderen haben. Der "noframes"-Bereich ist nur ein mäßiger Ersatz.

Das Problem mit den Targets wurde schlichtweg dadurch behoben, dass im Menü alle target="_top" gelöscht werden. Eine Seite bleibt also immer in den Frame, in den sie geladen wurde. Wenn nicht anders angegeben.

Ausgenommen und  optional anders ist der Link zur Startseite selbst. Hier muss man entscheiden (und jetzt wird’s ein bissel kompliziert ;-)
Wenn der Link zur Startseite mit target="_top" gesetzt wird, passiert genau das gleiche, wie bei einer "normalen" Site: Alles wird zurückgesetzt. Die Musik beginnt bei 0, die Präsentation ebenfalls. Alles. Aber auch etwaige kleine Unschönheiten, die vielleicht der Reloader hinterlassen hat, werden bereinigt. Es hängt eben davon ab, was im 2. Frame ist. Damit sind wir beim Reloader.

Der Frame-Reloader

Eine Frame-Seite besteht in ihrer Gesamtansicht aus mehreren Seiten. Eine Suchmaschine gibt in den Ergebnislisten aber immer nur eine Seite aus. Klickt man auf so ein Ergebnis, wird nur diese einzelne Seite, ohne umgebendes Frameset und andere Frames geladen.
Man könnte das verschmerzen, schließlich ist diese Seite voll funktionstüchtig, nur eben nicht vollständig.
Ein Stückchen Javascript bringt in so einem Fall trotzdem die vollständige Seite auf den Schirm:
Im Frameset wird eine Variable gesetzt, diese wird von den Unterseiten abgefragt. Ist sie gesetzt? Ja: Alles OK, nichts weiter. Ansonsten: Die Seite weiß, sie steht "nackt" da. Das Frameset wird geladen und dabei wird ihm auch gleich mitgeteilt, von welcher Seite der Aufruf kam. Diese Seite wird dann wieder anstelle der "normalen" Startseite geladen und es wird exakt der gewünschte Zustand hergestellt.
Naja – Licht und Schatten: In der Adresszeile des Browsers steht jetzt etwas wie
www.domain.tld/?verzeichnis/seite.php
Und das bleibt auch stehen, wenn die Seite gewechselt wird (einer der oben nicht erwähnten kleineren Besonderheiten von Frames)

Es gäbe Möglichkeiten, den Reloader über Cookies zu realisieren. Das verkompliziert die Sache aber ziemlich und bringt nicht wirklich viel

Licht: Diese URL kann man mailen, posten, sonst was: Sie gibt die richtige Seite an, mit allem drum und dran.
Schatten: Hat man inzwischen weitergeblättert, ist die Seite nicht mehr richtig, die URL ist ja unverändert.
Fragen wie: Kann ich mit Javascript oder sonst wie die richtige URL in die Adresse einsetzen? Wehe! Phisher hätten ein leichtes Spiel wenn das ginge. Es geht nicht und es wird nie gehen.
Jetzt wird auch klar, warum der Link auf die Startseite – optional – zum Frameset selbst führt: Es wird auch eine eventuell vom Reloader hinterlassene URL zurückgesetzt. Nachteil: Alle Frames werden zurückgesetzt.

Feinheiten

Ein Besucher sieht in der Adressleiste nicht, wo er ist. Diese zeigt ja immer die Domain selbst oder – falls der Reloader gestartet wurde, die Einstiegsseite. Das lässt sich eben nicht verhindern, aber der unbedarfte Besucher kann unterstützt werden: Im Footer der Seite wird die richtige URL angezeigt, gleich auch mit Bookmark-Möglichkeit. Diese ist zwar nicht nötig, aber trägt auch nicht auf.

Der <noframes> Bereich ist zwar mittlerweile nicht mehr nötig, aber es schadet nicht, ihn zu nutzen. Im Template wird hier automatisch eine Sitemap eingesetzt.

Was man sonst noch machen könnte

bei www.berann.at habe ich auf den Frame-Reloader verzichtet. Wird eine Seite direkt aus einer Suchmaschine aufgerufen, spielt eben keine Musik. Diese könnte dann erst starten, wenn man auf "home" klickt. Weil der Musik-Frame sehr schmal ist, geht er optisch nicht ab und Besucher die nichts ahnend über Suchmaschinen kommen, könnten von der Musik unangenehm berührt sein.

Bei größeren Frames wie im Demo-Template geht das so nicht, es fehlt einfach zu viel. Will man trotzdem keinen Reloader, kann man mit Javascript - statt dem Reloader - die fehlenden Teile "rekonstruieren", zumindest auf Sparflamme. Klickt jemand auf "Home", wird dann das Frameset geladen und die rekonstruierten Teile erübrigen sich.

Druck: Der Hauptframe ist eigentlich schon die ideale Druckversion. Man könnte ihn einfach - ohne Frameset - für den Druck aufrufen. Da klemmt aber der Reloader. Eine Lösung: Einen Parameter mitgeben, zb ?print=1, mit dem der Reloader deaktiviert, das CSS umgeschaltet und der Ausdruck gestartet wird.

Neuere Themen:

Direkter Sprachwechsel Direkt von "Impressum" zu "Imprint" - Möglichkeiten und Sinnfrage

Ältere Themen:

Böse Schöne URLs Manchmal sind die WB-URLs nicht optimal.

Zurück