Grundaufbau der Seiten - Frameset

Hi Leute...
Ich habe mir in letzter Zeit schon öfters Gedanken gemacht, wie man eine Seite (für ein Browsergame) möglichst sinnvoll aufbaut. Dabei werde ich wohl einen relativ verbreiteten Aufbau wählen: Banner (oben), Menue (links), Hauptteil (rest).
Nun stellt sich die Frage, wie man das sinnvoll aufbaut. Dabei gäbe es folgende Möglichkeiten:

• die Verwendung eines Framesets
• durchstrukturierung der Seiten ohne Frameset

Ich gehe ersteinmal auf das Frameset ein:
Die Vorteile des Framesets liegen klar auf der Hand: Man hat eine Indexseite, die das Frameset enthält, worin man Menübreite, Bannerhöhe, etc definiert und man legt jeweils eine neue Seite für die einzelnen Teile an. Die Strukturierung ist kein Problem, das übernimmt der Browser. Da es das Frameset an sich auch schon relativ lange gibt, unterstützen es die meisten Browser. Weiterhin bleibt das Menü immer an der gleichen Stelle, sodass man nicht immer wieder zum Seitenanfang scrollen muss um einen anderen Menüpunkt auszuwählen.
Eines der größten Nachteile am Frameset ist (natürlich) folgendes: Das Frameset liegt, wie wohl üblich, in einer index.php, die direkt aufgerufen wird, wenn jemand im Browserfenster meine-tolle-domain.de eingibt. Wunderbar: Das Frameset wird geladen und man ist glücklich.
Nun ruft aber jemand meine-tolle-domain.de/irgendeine.php auf, weil ihn ein Suchbot oder irgendwer anders dorthin gelinkt hat. Bei ihm wird nun irgendeine.php aufgerufen, jedoch ohne Frameset und ohne Menü. Garnicht so toll.
Wenn man Sich nun den Seitenaufbau ohne Frameset anguckt, dreht sich das ganze eigentlich nur um.
Vorteil ist ganz klar, dass auch wenn meine-tolle-domain.de/irgendeine.php aufgerufen wird, das Menü nicht unentdeckt bleibt.
Nachteil ist aber, dass man relativ lange braucht, um sein Menü in allen Browsern an der richtigen Stelle zu haben und dass dieses bei längeren Texten auch noch - weil es ja so viel Spass macht nach am Mausrad zu drehen - irgendwann oben verschwindet. Weiterhin wird der ganze Quark auch (unnötig) oft geladen.
Es gibt mit Sicherheit noch mehr Vor- und Nachteile, aber ich möchte nicht tagelang an einem Post schreiben, noch möchtet ihr so viel lesen. Außerdem verdeutlichen meine genannten Vor- und Nachteile denke ich ganz gut mein Problem und ich möchte euch bitten einmal dazu Stellung zu nehmen, eure Erfahrungen mit einem oder beidem zu Posten und ein paar Tipps zu geben.
So das wars ersteinmal.
mfg

Fragen wir nun erst einmal nach den Vorteilen von Framesets:
Mit einem Frameset kann man zwei Dinge erreichen: Erstens wird z.B. das Menü nur einmal geladen und danach nie wieder, zweitens bleibt das Menü immer an der gleichen Stelle, es verschiebt sich nicht, wenn man ein wenig rumscrollt (kann man mit ein wenig Rumgespiele mit DIV-Containern und "position: absolute;" aber auch hinbekommen).
Meine Meinung: In Zeiten von GZip-Compress kann man sich das Frameset schenken, die Bilder werden im Cache gehalten und die paar KB des Menüs werden mit GZip auf ein paar hundert Bytes reduziert, das sind selbst bei 100K Seitenaufrufen pro Monat 100 MB Traffic mehr oder weniger, also nichts.
Framesets sind laut (X)HTML auch nicht mehr Standard (zumindest im Scrict-Mode).
Fazit: Lass Frames sein...

Zusätzlich wird CSS ausgelagert und deshalb auch geached (und gerade CSS ). Da man mit der Bereitstellung des IE7 bald mit einer breiteren CSS2.Unterstützung der Nutzer rechnen kann, sind Top-Menus ohne Frameset, ohne JS und nur mit CSS auch möglich. Ja, bereits heute, aber für den IE6 braucht's dann immer eine Kompromiss.
Es gibt eigentlich keine wirklichen Vorteile mehr für Framesets; der Geschwindigkeitsvorteil ist nur bedingt da: Benutzer schmaler Bandbreiten, wobei diese von echt getrennten Dateien im Endeffekt auf lange Sicht auch nur profitieren (kein CSS, kein JS im HTML).

Mir haben das am Anfang auch alle Leute gesagt:
Frames sind nicht mehr zeitgemäß und ich sollte die rauslassen.
Jetzt wo alles fertig ist, sind sie begeistert, über den Komfort. Ich hätte unser Projekt ohne Frames nicht so umsetzen können, oder nur mit viel mehr Abfragen/Ladezeiten.
Ich bin von Frames begeistert.

Ich bin vor einiger Zeit von Frames auf DIVs (und smarty) umgestiegen. Vorher hatte ich auch die Frames, wegen dem unnötigen Nachladen. Dann wollte ich einfach mal ausprobieren, wie es ohne Frames aussieht, aus reiner Neugierde. Die Umstellung ging recht schnell, und ich bin dabei geblieben. Mit den frames war es ein Problem, wenn Unterpunkte auf der Navigation erscheinen sollten, und gleichzeitig eine Seite geladen werden soll. Ich weiß, das geht mit JavaScript, aber ich will meine Seite so einfach wie nötig halten, alles was ein Benutzer mit JavaScript machen kann, soll auch jemand ohne JavaScript, CSS und Bildern machen können.
Das Problem mit den Externen Links hatte ich sogut wie nicht, da man ins Game natürlich nur reinkommt, wenn man sich eingeloggt hat. Das Portal war schon von Anfang an ohne Frames. Trotzdem habe ich vor, das Spiel mehr zu integrieren, z.B. ins Forum. Dafür brauche ich dann Direkte Links zu der Seite, was natürlich auch per index.php?page=bla zu lösen wäre.
Für mich waren es viele kleinere Gründe, und ich bin sehr zufrieden mit dem Umstieg, jedoch bin ich nicht nur von Frames auf nicht-Frames, sondern gleichzeitig auch auf ein Templatesystem umgestiegen, was natürlich auch Vorteile bringt.

Ich bastle an einer Art AJAX-Frameset mit Divs. Bin bisher recht zufrieden, ich habe die Vorteile eines Frames (Menü wird nicht jedesmal mitgeladen) ohne die Nachteile. Natürlich bring ein AJAX-Einsatz seine eigenen Nachteile mit.

Ich habe mir für mein BG eine Templateklasse geschrieben, da bleibt der aufbau gleich, nur diverse teile wie navigationen und content ändern sich, dadurch hat die seite an sich nur eine größe vn ca 5 KB (ohne anderen Bildern, eh klar)
Frames finde ich absolut unangebracht, meine designs sind nach unten hin offen, und wenns zu lang wird, teile ich auf mehrere seiten auf (zB im Forum)

Ich persönlich nutze keine Frames, sondern die Masterpages die von ASP.Net zur Verfügung gestellt wird.
Die entsprechen ziemlich genau der Beschreibung wie sie phi nutzt, nur halt schon vorgegeben.
Dabei habe ich zwar immer das Problem, dass ich die Navi rumschleppe, aber damit werde ich leben müssen. Bandbreite wird auch immer billiger.
Die Idee mit einem AJAX-Austausch hatte ich auch mal, habe sie aber wegen des erforderlichen Aufwandes nicht umgesetzt.
Beim nächsten Browsergame werde ich mir allerdings überlegen, ob ich nicht wieder Frames nutze. Dadurch wird meines Erachtens die Navigation etwas intuitiver und man kann ein zentrales window-Element zur Speicherung von JavaScript-Inhalten nutzen, oder einen immer funktionierenden Nachrichtenticker anzeigen.

ich schreibs mir lieber selbst, dann weiß ich, woran ich bin, hab früher TemplateIT verwendet, ist mir aber zu beschränkt, vor allem da man elemente nicht wiederholen kann, und das brauch ich zB für die Navi...
hab mir zB mein forum auch selbst geschrieben, damit's einwandfrei ins system passt, und zB Allianzforen automatisch erstellt werden können...

Sollte keine Kritik darstellen, wollte nur meinen Weg etwas deutlicher darstellen, da der Begriff 'MasterPages' zu abstrakt ist, daher der Vergleich mit deiner Lösung.
Ich persönlich bin im Regelfall auch eher ein Fan des Selberschreibens.

Ich fand die Masterpage von ASPP 2.0 auch nicht schlecht.
Ist nur schade, dass die bei 1.1 noch nicht verfügbar war,
da ich manche Projekte mit 1.1 warten muss
Für mein BG habe ich mir auch eine art Frameset selbergemacht,
ähnlich wie phi
www.ancient-world.net/Design_phini.htm
Diese seite parse ich und füge in die Tags inhalt hinzu,
wie ich ihn gerade brauche.
Persönlich finde ich framesets auch nicht schlecht, sie
passen aber nicht in mein Design, da ich die Ressourcen nicht dynamisch
nachlade.

Failed validation, 42 errors
..
pass etwas auf die standards auf .. sonst bekommsnte nur browserprobleme ..
ps: font ist KEIN html-tag.

Hmmm...
In der Firma arbeiten wir mit Frames, haben aber da den Vorteil das der Browser incl. Config und Patchlevel fest vorgegeben ist. Wer da was anderes hat, der bekommt richtig Ärger.
Bei meinem letzten Projekt habe ich komplett ohne Frames gearbeitet.
Es hängt im Endeffekt von dem Können des Programmierers ab, ob die Lösung was taugt oder nicht.

Original von Drezil
Failed validation, 42 errors
..
pass etwas auf die standards auf .. sonst bekommsnte nur browserprobleme ..
ps: font ist KEIN html-tag.

ohh, dass habe ich noch nie geprüft *schäm*

> ohh, dass habe ich noch nie geprüft *schäm*
Für sowas habe ich den HTML Validator. Das ist ein Plugin für den Firefox, es icht bei mir rechts unten uns zeigt mir an, ob das Dokument valid ist. Somit entwikele ich von anfang an meine seiten valid, und sobald mal nicht der Haken dort ist, schaue ich nach, was nicht stimmt

Original von Fornax
> ohh, dass habe ich noch nie geprüft *schäm*
Für sowas habe ich den HTML Validator. Das ist ein Plugin für den Firefox, es icht bei mir rechts unten uns zeigt mir an, ob das Dokument valid ist. Somit entwikele ich von anfang an meine seiten valid, und sobald mal nicht der Haken dort ist, schaue ich nach, was nicht stimmt

Sollte man richtig stellen: In Wahrheit ist das ein Validator + Tidy, d.h. er zeigt einem auch valide, aber "unglückliche" Situationen an.
Beispiel:

Ein Text

Noch ein Text
Das ist korrekt, valid und in manchen Sitationen semantisch sogar korrekt; Tidy (und damit das Plugin Html Validator) meckern dies mit einer Warnung an.
Und ja, ich nutze dieses Tool auch gerne.. nix geht ohne