Dynamischer Frame

[Gunter]

Hallo Zusammen, ich habe eine Vorstandsübersicht in einer Homepage. Mein Problem ist, das diese sehr groß ist. Ich habe links einen Frame mit Namen und oben einen Frame mit Jahreszahlen eingesetzt. Wenn nun ein User nach unten scrollt, verschwinden die Jahrezahlen, scrollt er nach rechts, verschwinden die Namen. Gibt es in HTML, oder Java eine ähnliche Funktion wie in Excel der Befehl Fenster fixieren??

Danke schon mal im voraus.

Gunter

[Götz]

Hallo Gunter!

Gibt es in HTML, oder Java eine ähnliche Funktion wie in Excel der Befehl Fenster fixieren??

Ja, siehe auch http://de.selfhtml.org/css/eigenschaften/positionierung.htm#position.

MfG
Götz

[Mathias Bigge]

Hi Gunter,

Hallo Zusammen, ich habe eine Vorstandsübersicht in einer Homepage. Mein Problem ist, das diese sehr groß ist. Ich habe links einen Frame mit Namen und oben einen Frame mit Jahreszahlen eingesetzt. Wenn nun ein User nach unten scrollt, verschwinden die Jahrezahlen, scrollt er nach rechts, verschwinden die Namen. Gibt es in HTML, oder Java eine ähnliche Funktion wie in Excel der Befehl Fenster fixieren??

Die Technik nennt sich Frames und anscheinend sprichst  Du von Frames, meinst aber Tabellenzellen...

Viele Grüße
Mathias Bigge

[Gernot Back]

Hallo Gunter,

also irgendwie kann ich mir den Aufbau deiner Seite oder deines Framesets noch nicht so recht vorstellen. Also du hast oben was und links was und was hast du denn im Hauptframe (unten rechts) für Informationen? Wenn es sich tatsächlich um Frames handelt, deren Scrolling miteinander koordiniert werden soll, dann hilft dir vielleicht mein in einem anderen Thread gerade beschriebener Ansatz.

[pref:t=84560&m=495949]

Gruß Gernot

[Mathias Bigge]

Hi Gernot,

Wenn es sich tatsächlich um Frames handelt, ...

Wetten, dass er keine Frames hat? Das geht aus seiner Beschreibung klar hervor... *g*

Viele Grüße
Mathias Bigge

[Gernot Back]

Hallo Mathias,

das glaube ich auch, dass Gunter (noch) keine Frames hat, aber das wäre die Lösung seines Problems:

Gunter müsste ein Frameset mit vier Frames bauen, mit einer Aufteilung über Kreuz. Oben links der Frame würde leer bleiben oder nur das Firmenlogo einthalten. In die übrigen drei Frames würde er dreimal die gleiche Seite mit seiner Tabelle laden. Die Überschriften oben und links sollen ja stehen bleiben und würden nur in der Höhe der ersten Zeile bzw. der Breite der ersten Spalte mit scrolling=no angezeigt. Der einzige Frame der scrollen darf ist der unten links und würde entsprechend im horizontalen Scrolling mit dem Frame oben rechts und im vertikalen Scrolling mit dem links koordiniert.

Gruß Gernot

[Efchen]

Moin,

das glaube ich auch, dass Gunter (noch) keine Frames hat, aber das wäre die Lösung seines Problems:

Nein, ganz sicher nicht. Sein unmittelbares Problem schiene zwar gelöst, aber durch die unsäglichen Frames holt er sich doch die Pest ins Haus!
Dann kommt er mit den Problemen an, die die Frames mit sich bringen, und die können nicht umgangen werden.

Die einzig sinnvolle Lösung ist hier eine Tabelle (denn es handelt sich ja um tabellarische Daten!), mit einem thead, tbody und tfoot. Der tbody bekommt eine feste Größe mitgegeben und dazu ein 'scrolling="auto"', damit ein Scrollbalken erscheint. Leider hat diese Variante, die aber die beste, problemloseste und barrierefreie ist, den Nachteil, dass man auf diese Weise keine Spalten festsetzen kann. Man könnte sich aber dadurch behelfen, dass man in regelmäßigen Abständen die Spaltenbezeichnung zwischen die Spalten schiebt, oder wenn die Tabelle nicht sooo breit ist, sie lediglich in der letzten Spalte wiederholt. Dafür Frames einzusetzen halte ich für nicht sinnvoll, wenn es sich um eine öffentliche Website handelt.

Gruß,
-Efchen

[Cybaer]

Hi,

Dann kommt er mit den Problemen an, die die Frames mit sich bringen, und die können nicht umgangen werden.

Endlich einer, der sich auskennt! ;)

Ich wollte schon immer mal eine Zusammenstellung der "nicht umgehbaren Probleme von Frames" haben. Welche sind das denn?

Gruß, Cybaer

[Struppi]

Ich wollte schon immer mal eine Zusammenstellung der "nicht umgehbaren Probleme von Frames" haben. Welche sind das denn?

z.b.

* Frames lassen sich nicht skalieren
* Unterseiten lassen sich nicht bookmarken

Struppi.

[Efchen]

Ich wollte schon immer mal eine Zusammenstellung der "nicht umgehbaren Probleme von Frames" haben. Welche sind das denn?

Du scheinst Dich noch nicht intensiver mit Frames befasst zu haben, denn dann würden Dir die Probleme sofort ins Auge fallen:

1. Inkompatibilität zu manchen Browsern.
2. Inkompatibilität zu Suchmaschinen (okay, meist ist das Faulheit des Webmasters).
3. Kein Bookmarken von Unterseiten möglich.
4. Kein direktes Verlinken von Unterseiten möglich.
5. Versuch mal einem Freund mitzuteilen, wie er auf eine tolle Unterseite kommt (Geh auf www.xxx.de, klick da auf a, dann scroll zu b, klick dann auf d und um 12:00 erscheint der Link zu e. Dann bist Du bei f. Waaaahhh!)
6. Von Suchmaschinen endizierte Unterseiten erscheinen ohne das Frameset.
7. Frameset nachladen (aufgrund von 6) nur mit JavaScript möglich. Für Leute mit abgestelltem JavaScript ist die Site unbenutzbar.

Frames bieten keinerlei wirklich Vorteile, die wirkliche Vorteile sind und nicht auch anders machbar sind. Das Trennen von Seitenteilen in verschiedene Dateien zum Zwecke des Nur-Einmal-Schreiben-Müssens lässt sich besser mit einer serverseitigen Include-Technik bewerkstelligen. Diese ist barrierefrei, weil unabhängig von irgendwelcher Hardware und irgendwelchen Einstellungen des Clients.
Die Fixierung von Elementen, die so oft als weiterer Vorteil angebracht wird, ist eigentlich nicht wirklich einer. Aber auch das ist in CSS mit modernen Browsern möglich. Der MSIE wird hierbei NICHT zu modernen Browsern gezählt, da der leider kein position:fixed beherrscht. Für MSIE6 gibt es allerdings auch Workarounds. Nutzer des superalten MSIE5 müssen auf dieses Feature halt verzichten, essenziell ist das ja schließlich nicht.
Dass immer nur die Startseite in der Adresszeile stehenbleibt, ist bei genauem Überlegen offensichtlich nur ein Nachteil aber kein Vorteil.

Ich hoffe, Dir damit die Frames etwas nähergebracht zu haben.

Gruß,
-Efchen

[alfie]

Hallo Efchen!

Ich wollte schon immer mal eine Zusammenstellung der "nicht umgehbaren Probleme von Frames" haben. Welche sind das denn?

Du scheinst Dich noch nicht intensiver mit Frames befasst zu haben, denn dann würden Dir die Probleme sofort ins Auge fallen:

Faszinierende Behauptung. Ich empfehle dir http://suche.de.selfhtml.org/cgi-bin/such.pl?suchausdruck=author%3ACybaer+Frames&case=on&lang=on&feld=alle&index_5=on&index_6=on&hits=100, dann wirst du einige Statements von Cybaer finden....

1. Inkompatibilität zu manchen Browsern.

Netscape 2...

2. Inkompatibilität zu Suchmaschinen (okay, meist ist das Faulheit des Webmasters).

definiere bitte 'Inkompatibilität'

3. Kein Bookmarken von Unterseiten möglich.

doch.

4. Kein direktes Verlinken von Unterseiten möglich.
5. Versuch mal einem Freund mitzuteilen, wie er auf eine tolle Unterseite kommt (Geh auf www.xxx.de, klick da auf a, dann scroll zu b, klick dann auf d und um 12:00 erscheint der Link zu e. Dann bist Du bei f. Waaaahhh!)
6. Von Suchmaschinen endizierte Unterseiten erscheinen ohne das Frameset.
7. Frameset nachladen (aufgrund von 6) nur mit JavaScript möglich. Für Leute mit abgestelltem JavaScript ist die Site unbenutzbar.

4.,5. und 7. ist durch serverseitiges Nachladen zu lösen
http://aktuell.de.selfhtml.org/artikel/phpasp/php-frames/index.htm
Für eine ernsthafte (!) Auseinandersetzung mit Frames empfehle ich dir auch http://molily.de/frames-probleme

was stört dich an Pkt.6?

Die Fragestellung von Gunter lässt sich IMHO mit CSS *allein* nicht lösen (sein Beispiel 'ähnliche Funktion wie in Excel der Befehl Fenster fixieren' sagt doch eigentlich alles).
Du argumentierst für 'position:fixed' und dass User mit dem IE5 ('superalter Browser') halt Pech haben. Schön.
Dann finde ich aber deinen Pkt.1 etwas heuchlerisch (mit Frames werden viel weniger User ausgeschlossen als mit 'CSS position:fixed').

Kann es sein, dass du selbst 'dich noch nicht intensiver mit Frames befasst hast' und bloss reflektorisch die Anti-Frames-Keule schwingst?

mfg Alfie

[Efchen]

Faszinierende Behauptung.

Es war mir schon klar, dass er wahrscheinlich zu der Art Leute gehört, die nur alles mit Frames machen und alle meine Argumente als Schwachsinn abtun wird. Weil Frames ja die beste Erfindung seit HTML sind usw. usf. blabla.
Aber genauso wie er seine Frage ironisch gestellt hat, habe ich ironisch zurück geantwortet.

1. Inkompatibilität zu manchen Browsern.

Netscape 2...

Ja. Und? Mosaic, auch noch in der neusten Version 3.
Ist doch ein gutes Argument.

2. Inkompatibilität zu Suchmaschinen (okay, meist ist das Faulheit des Webmasters).

definiere bitte 'Inkompatibilität'

Du machst auch nicht den Eindruck, als wüsstest Du nicht, was ich meine. Der überwiegende Teil der selbsternannten Webmaster schert sich einen Dreck um einen noframes-Bereich und somit sind die Suchmaschinen nicht in der Lage, Unterseiten zu indizieren.

3. Kein Bookmarken von Unterseiten möglich.

doch.

Nein. Weil in der Adresszeile nur die URL der Startseite steht.
Um das Bookmarken zu ermöglichen, müsste man schon anfangen zu basteln.
Bevor Du aber antwortest, lass mich Dir sagen, dass ich durchaus weiß, wie man die Probleme umgeht, ich hatte auch schon mal eine Site mit Frames, wo ich all diese Probleme umgangen habe. Jedoch halst Du Dir damit weitere Probleme auf, z.B. die Abhängigkeit von JavaScript, Du wirst eine serverseitige Technik einsetzen und der Seitenaufbau wird sich verlangsamen. Keine Alternative. Frames weglassen ist die bessere.

4.,5. und 7. ist durch serverseitiges Nachladen zu lösen

Das weiß ich.

was stört dich an Pkt.6?

???
Was hast Du von einer Unterseite, wenn die Navigation fehlt (Standard-Frameset mit Standard-Webmaster, der von Tuten und Blasen keine Ahnung hat).

Die Fragestellung von Gunter lässt sich IMHO mit CSS *allein* nicht lösen (sein Beispiel 'ähnliche Funktion wie in Excel der Befehl Fenster fixieren' sagt doch eigentlich alles).

Ja, das Problem der feststehenden Spalten...das ist mir hinterher auch eingefallen.

Du argumentierst für 'position:fixed' und dass User mit dem IE5 ('superalter Browser') halt Pech haben. Schön.

Jein. Ich würde mir überlegen, ob das Feature anders richtig zu lösen gibt, und ob ich - anstatt Frames zu verwenden - lieber auf ein Feststehen verzichten würde.

Dann finde ich aber deinen Pkt.1 etwas heuchlerisch (mit Frames werden viel weniger User ausgeschlossen als mit 'CSS position:fixed').

Das Problem ist, dass Frames so viele Probleme und Workarounds mit sich ziehen, dass der Aufwand schlicht nicht gerechtfertigt ist. Und wer einen Browser benutzt, der kein CSS kann, der kann nunmal keine modernen Websites benutzen. Pferdefuhrwerke dürfen ja heute auch nicht auf Autobahnen.

Kann es sein, dass du selbst 'dich noch nicht intensiver mit Frames befasst hast' und bloss reflektorisch die Anti-Frames-Keule schwingst?

Nein.

Ich glaube nur im Nachhinein, dass wenn der Originalfragesteller wirklich unbedingt die Zeilen und Spalten feststehend haben will, dass das wahrschienlich mit CSS doch nicht so gut zu lösen ist. Andererseits sind Frames doch auch nicht die Lösung. Wenn die erste Spalte ein eigener Frame ist, damit die Spalte beim horizontal scrollen feststehen, wie machst Du das dann beim vertikalen Scrollen? Da muss der Frame dann ja mitscrollen.

Gruß,
-Efchen

[Cybaer]

Hi,

Faszinierende Behauptung.
Es war mir schon klar, dass er wahrscheinlich zu der Art Leute gehört, die nur alles mit Frames machen

Eine weitere "faszinierende Behauptung". =:-)

Ja. Und? Mosaic, auch noch in der neusten Version 3.
Ist doch ein gutes Argument.

Meine (Frame-)Seiten funktionieren auch mit dem Mosaic 1.

NS2 hat das Problem, daß man später das Verhalten des Browser-Backs bei Frameseiten geändert hat. Ansonsten funktionieren (zumindest meine) Frameseiten auch problemlos auf NS2.

Du machst auch nicht den Eindruck, als wüsstest Du nicht, was ich meine. Der überwiegende Teil der selbsternannten Webmaster schert sich einen Dreck um einen noframes-Bereich und somit sind die Suchmaschinen nicht in der Lage, Unterseiten zu indizieren.

Was hast Du von einer Unterseite, wenn die Navigation fehlt (Standard-Frameset mit Standard-Webmaster, der von Tuten und Blasen keine Ahnung hat).

Die Welt ist voll von solchen Webmastern. Sie nutzen Frames, JavaScript, PHP, CSS, XHTML, ... - oder auch nicht.

Das Problem ist, dass Frames so viele Probleme und Workarounds mit sich ziehen, dass der Aufwand schlicht nicht gerechtfertigt ist.

Da kennst Du andere Techniken, als ich. ;-)

Und wer einen Browser benutzt, der kein CSS kann, der kann nunmal keine modernen Websites benutzen. Pferdefuhrwerke dürfen ja heute auch nicht auf Autobahnen.

Was am Webmaster liegt. Nicht nur meine Frames-, auch meine Tabellen- oder CSS-Seiten lassen sich mit HTML-1-Browsern nutzen. :-o

Und nein: Der Mehraufwand ist arg gering, weil ich bereits vorher weiß, worauf ich auchten muß. Das geht so selbstverständlich, wie das Atmen. Nur auf "WSIWYG"-Editoren muß ich verzichten - aber das tue ich gerne und sowieso ... ;->

Ich glaube nur im Nachhinein, dass wenn der Originalfragesteller wirklich unbedingt die Zeilen und Spalten feststehend haben will, dass das wahrschienlich mit CSS doch nicht so gut zu lösen ist. Andererseits sind Frames doch auch nicht die Lösung. Wenn die erste Spalte ein eigener Frame ist, damit die Spalte beim horizontal scrollen feststehen, wie machst Du das dann beim vertikalen Scrollen? Da muss der Frame dann ja mitscrollen.

Da hast Du vollkommen recht. Horizontal kein Problem, vertikal auch nicht, aber horizontal & vertikal gleichzeitig? =:-o

Gruß, Cybaer

[Efchen]

Hei,

Ich glaube nur im Nachhinein, dass wenn der Originalfragesteller wirklich unbedingt die Zeilen und Spalten feststehend haben will, dass das wahrschienlich mit CSS doch nicht so gut zu lösen ist. Andererseits sind Frames doch auch nicht die Lösung. Wenn die erste Spalte ein eigener Frame ist, damit die Spalte beim horizontal scrollen feststehen, wie machst Du das dann beim vertikalen Scrollen? Da muss der Frame dann ja mitscrollen.

Da hast Du vollkommen recht. Horizontal kein Problem, vertikal auch nicht, aber horizontal & vertikal gleichzeitig? =:-o

Ja, und ich glaube, genau darum gings ja, das gleichzeitig. Oder geht das in Excel auch nicht? Hmmm ... :-)

[alfie]

Hallo!

... Horizontal kein Problem, vertikal auch nicht, aber horizontal & vertikal gleichzeitig? =:-o

Ja, und ich glaube, genau darum gings ja, das gleichzeitig. Oder geht das in Excel auch nicht? Hmmm ... :-)

In Excel geht das problemlos. Ich fürchte, eine Umsetzung in HTML *ohne* massiven Einsatz von JavaScript ist nicht möglich.

mfg Alfie

[Gunter]

Hallo Zusammen,

gestern konnte ich leider die Diskussion nicht verfolgen, ich gebe euch hier die Website, dann könnt Ihr euch das Problem in natura ansehen.

www.ffkaichen.de , links in Navi Leiste Protokolle anwählen, dann den Link Vorstand in tabellarischer Aufstellung aufrufen.

Danke Gunter

[Struppi]

gestern konnte ich leider die Diskussion nicht verfolgen, ich gebe euch hier die Website, dann könnt Ihr euch das Problem in natura ansehen.

Tja, sorry da bin ich draußen.
Mein Browser ist nicht in der Lage das Navigationsframe darzustellen, eigentlich auch kein wunder:  http://validator.w3.org/check?uri=http%3A%2F%2Fwww.ffkaichen.de%2FNavigation.html&charset=iso-8859-1+(Western+Europe)

www.ffkaichen.de , links in Navi Leiste Protokolle anwählen, dann den Link Vorstand in tabellarischer Aufstellung aufrufen.

Naja, ich hab dann im Quelltext doch den Link gefunden http://www.ffkaichen.de/Protokolle.htm
Aber mein alterschwacher Rechner macht da schlapp.

Struppi.

[Cybaer]

Hi,

www.ffkaichen.de , links in Navi Leiste Protokolle anwählen, dann den Link Vorstand in tabellarischer Aufstellung aufrufen.

Links einen Frame mit den Namen, oben einen Frame mit den Zahlen, im Haupteld rechts/unten der Frame mit den Daten.

Soweit kein Problem. Aber Du müßtest halt mittels JavaScript dafür sorgen, daß oberer und rechter Frame jeweils mitscrollen. Machbar, aber IMHO nicht ganz unkompliziert.

Ohne Frames wäre ein "Layer" immer so zu positionieren, daß er zum Scrollstand paßt. Leichter machbar, aber auch nicht unkompliziert.

Einfacher wäre es, die Tabellen so aufzustückeln, daß der (Teil-)Bereich in ganzer Höhe ohne zu Scrollen in ein "übliches" Browserfenster paßt (was eigentlich schon nicht geht/nicht sicher machbar ist, da Surfer-spezifisch). Dann könnte man die Namen in einem Frame "links liegen" lassen und die Jahreszahlen direkt ins Datendokument packen (sie werden dort dann ja einfach mitgescrollt).

Gruß, Cybaer

[Cybaer]

Hi,

Ja, und ich glaube, genau darum gings ja, das gleichzeitig. Oder geht das in Excel auch nicht? Hmmm ... :-)

Klar, in Excel kein Problem (rhetorische Antwort ;-)). In Frames halt schon. In CSS auch (nach aktuellem Stand der relevanten Browertechnik). Und da JS ja nicht voraussetzbar ist, scheidet auch DHTML als allgemeingültige Lösung aus ...

Gruß, Cybaer

[Cybaer]

Hi,

Du scheinst Dich noch nicht intensiver mit Frames befasst zu haben, denn dann würden Dir die Probleme sofort ins Auge fallen:

Och, ich nutze Frames seit Anbeginn. Oder eben auch nicht - kommt ganz drauf an.

Aber was ich bisher (auch hier im Forum) an Frame-Nachteilen zu hören bekam, war eher vereinzelt und/oder unausgereift. Da würde es mich freuen, mal wirklich eine konkrete Liste zu haben, die man abarbeiten kann! :-o

1. Inkompatibilität zu manchen Browsern.

Nein. Für Nicht-Frame-Browser wurde NOFRAMES definiert. Faulheit des Autors sollte man nicht der Technik vorwerfen. ;->

Ich kenne zumindest keinen Browser, der mit FRAMES und dazugehörigen NOFRAMES(!) inkompatibel wäre. Du wirst mir auch keinen nennen können.

2. Inkompatibilität zu Suchmaschinen (okay, meist ist das Faulheit des Webmasters).

S. 1)

3. Kein Bookmarken von Unterseiten möglich.

Niemand zwingt den Autor, Unterseiten zu verwenden. Ebenso ist es möglich, für jede Seite ein eigenes Framest zu erstellen (oder es automatisch generieren zu lassen).

4. Kein direktes Verlinken von Unterseiten möglich.

Doch, durchaus. Wenn du das als Autor allerdings universell machen willst (und nicht für jeden Anker ein eigenes FS erstellen möchtest), dann muß das Frameset allerdings dynamisch generiert werden, den Hash auslesen und in die FS-Definition integriert werden.

5. Versuch mal einem Freund mitzuteilen, wie er auf eine tolle Unterseite kommt (Geh auf www.xxx.de, klick da auf a, dann scroll zu b, klick dann auf d und um 12:00 erscheint der Link zu e. Dann bist Du bei f. Waaaahhh!)

S. Punkt 3)

Außerdem kann der Autor auch selbst eine Möglichkeit bieten, das FS aufzulösen.

6. Von Suchmaschinen endizierte Unterseiten erscheinen ohne das Frameset.

Kommt drauf an. Es ist kein Problem, dynamisch den kompletten Content zusätzlich n den NOFRAMES-Bereich zu packen und ihn selbst nicht indizieren zu lassen.

Üblicher dürfte es aber sein, das passende Frameset einfach nachzuladen. Das ist ja nun wirklich kein Problem.

7. Frameset nachladen (aufgrund von 6) nur mit JavaScript möglich. Für Leute mit abgestelltem JavaScript ist die Site unbenutzbar.

Nein. Jede Seite darf so oder so ruhig eine "Breadcrumb"-Navigation enthalten. Einen "Lade Navigations-Frames"-Button dürfte auhc niemanden umbringen (zumal er meistens nicht sichtbar sei muß).

Frames bieten keinerlei wirklich Vorteile, die wirkliche Vorteile sind und nicht auch anders machbar sind.

Alleine schon die Fixierung ist ein Vorteil - jedenfalls solange es Browser verwendet werden, die ds mit CSS nicht so schön hinkriegen (wenn überhaupt).

Das Trennen von Seitenteilen in verschiedene Dateien zum Zwecke des Nur-Einmal-Schreiben-Müssens lässt sich besser mit einer serverseitigen Include-Technik bewerkstelligen.

Die steht nicht jedem zur Verfügung. Steht sie zur Verfügung, können einige Nachteile der Frames per se entfallen. :-)

Gruß, Cybaer

[Struppi]

Aber was ich bisher (auch hier im Forum) an Frame-Nachteilen zu hören bekam, war eher vereinzelt und/oder unausgereift. Da würde es mich freuen, mal wirklich eine konkrete Liste zu haben, die man abarbeiten kann! :-o

Und wieder eine Diskussion im Kreise. Die Liste sind Nachteile, von denen niemand behauptet hat das es möglichkeiten gibt diese zu umschiffen, aber ist es wirklich sinnvoll sich erst einen Haufen Nachteile aufzuhalsen um dann in jeder Seite eine Workaround dafür einzubauen?

1. Inkompatibilität zu manchen Browsern.

Nein. Für Nicht-Frame-Browser wurde NOFRAMES definiert. Faulheit des Autors sollte man nicht der Technik vorwerfen. ;->

Das ist ein Nachteil. du musst inhalte pflegen die du nicht mal ohne weiteres selber darstellen kannst. weil eben...

2. Inkompatibilität zu Suchmaschinen (okay, meist ist das Faulheit des Webmasters).

S. 1)

es muss eine separate Suchmaschinen optimierung erfolgen und eine für Besucher mit Browsern die keine Frames können.

3. Kein Bookmarken von Unterseiten möglich.

Niemand zwingt den Autor, Unterseiten zu verwenden. Ebenso ist es möglich, für jede Seite ein eigenes Framest zu erstellen (oder es automatisch generieren zu lassen).

Der erste Satz ist ein argumentatives Glanzstück und das zweite bedeutet, dass die Pkt. 1 und 2. sich nochmals potenzieren.

4. Kein direktes Verlinken von Unterseiten möglich.

Doch, durchaus. Wenn du das als Autor allerdings universell machen willst (und nicht für jeden Anker ein eigenes FS erstellen möchtest), dann muß das Frameset allerdings dynamisch generiert werden, den Hash auslesen und in die FS-Definition integriert werden.

Du gehtst davon aus dass 100% deiner Besucher JS angeschaltet haben. In anbetracht der noch vorhandenen Lücken im IE eine Hoffnung die sich durchaus umkehren könnte.

Und auch hier, es tritt ein Problem auf und du dasgt man kann es lösen, es ist aber trotzdem noch ein Problem, dass zusätzliche (und evtl. erfolglose) Arbeit erfordert.

5. Versuch mal einem Freund mitzuteilen, wie er auf eine tolle Unterseite kommt (Geh auf www.xxx.de, klick da auf a, dann scroll zu b, klick dann auf d und um 12:00 erscheint der Link zu e. Dann bist Du bei f. Waaaahhh!)

S. Punkt 3)

d.h.?

6. Von Suchmaschinen endizierte Unterseiten erscheinen ohne das Frameset.

Kommt drauf an. Es ist kein Problem, dynamisch den kompletten Content zusätzlich n den NOFRAMES-Bereich zu packen und ihn selbst nicht indizieren zu lassen.

Üblicher dürfte es aber sein, das passende Frameset einfach nachzuladen. Das ist ja nun wirklich kein Problem.

Mit JS, aber es ist wie unter 4. beschrieben nicht zuverlässig und wieder zusätzliche Arbeit.

7. Frameset nachladen (aufgrund von 6) nur mit JavaScript möglich. Für Leute mit abgestelltem JavaScript ist die Site unbenutzbar.

Nein. Jede Seite darf so oder so ruhig eine "Breadcrumb"-Navigation enthalten. Einen "Lade Navigations-Frames"-Button dürfte auhc niemanden umbringen (zumal er meistens nicht sichtbar sei muß).

Zusätzlicher Aufwand nummero ???

Frames bieten keinerlei wirklich Vorteile, die wirkliche Vorteile sind und nicht auch anders machbar sind.

Alleine schon die Fixierung ist ein Vorteil - jedenfalls solange es Browser verwendet werden, die ds mit CSS nicht so schön hinkriegen (wenn überhaupt).

wieso ist Fixierung ein Vorteil?
In aller Regel ist doch der Inhalt einer Seite wichtig und nicht das Logo oder das Menü. es gibt durchaus Seite - wenn man sich einen Überblick verschaffen möchte - wo dies nützlich sein könnte. In der Regel bedeutet Fixierung aber eine Verkleinerung der Fläche die mir zum lesen zu Verfügung steht

Außerdem lassen sich Frames immer noch nicht skalieren.

Du hast also eine Reihe von Nachteilen, die für dich durch zweifelhafte Vorteile aufgehoben werden. Und die du durch beträchliche Mehrarbeit versuchst zu kompensieren.

Also, ich bin froh von Frames wegegkommen zu sein, für mich persönlich  stellt das einen enormen Zeitgewinn und eine einfachere Seitengestaltung dar.

Struppi.

[Cybaer]

Hi,

Und wieder eine Diskussion im Kreise.

Na, hoffe ich doch nicht. =:-o Aber "überzeugt" wird hier sicherlich niemand von den "alten Hasen". Es handelt sich also höchstens um einen Austausch von Sichtweisen. :-)

Die Liste sind Nachteile, von denen niemand behauptet hat das es möglichkeiten gibt diese zu umschiffen,

"... das es *nicht* möglichkeiten gibt ..."?!

Die "Nachteile" werden erst zu solchen, wenn man die Technik nicht richtig einsetzt. Du *kannst* z.B. auch auf externe CSS-Definitionen/Klassen verzichten und sämtliche Styles direkt mittels STYLE-Attribut definieren. Ob man dabei soviel gewinnt gegenüber FONT & Co.? Natürlich nicht. Es mag im Einzelfall durchaus sinnvoll sein, doch ist es wohl kaum der richtige (oder zumindest optimale) Weg, mit Styles zu arbeiten, oder?

aber ist es wirklich sinnvoll sich erst einen Haufen Nachteile aufzuhalsen um dann in jeder Seite eine Workaround dafür einzubauen?

Also ich sehe davon nichts als Workaround. Höchstens noch der manuelle "Frame-Nachlade-Button", falls keinerlei Dynamik (JS/PHP/...) zur Verfügung steht. Der wäre sonst echt überflüssig. ;-)

Aber verglichen mit den CSS-Workarounds und ggf. Ersatzlösungen für Nicht-CSS-Browser, ist das eine (zudem leicht zu automatisierende) "Peanut".

Nein. Für Nicht-Frame-Browser wurde NOFRAMES definiert. Faulheit des Autors sollte man nicht der Technik vorwerfen. ;->
Das ist ein Nachteil. du musst inhalte pflegen die du nicht mal ohne weiteres selber darstellen kannst. weil eben...

Mal vom Umstand abgesehen, daß (mndestens) ein frameloser Browser zu Testzwecken in jede Webmaster-Sammlung gehört: Opera sollte ohnehin jeder zu Testzwecken haben - dort kann man Frames abschalten.

2. Inkompatibilität zu Suchmaschinen (okay, meist ist das Faulheit des Webmasters).
   S. 1)
   es muss eine separate Suchmaschinen optimierung erfolgen und eine für Besucher mit Browsern die keine Frames können.

Nein. Man soll kluges, umsichtiges Webdesign betreiben. Dann muß auch für niemanden mehr was "optimiert" werden.

3. Kein Bookmarken von Unterseiten möglich.
   Niemand zwingt den Autor, Unterseiten zu verwenden. Ebenso ist es möglich, für jede Seite ein eigenes Framest zu erstellen (oder es automatisch generieren zu lassen).
   Der erste Satz ist ein argumentatives Glanzstück

Danke, aber es ist bitterernst gemeint. :-o

Ob ich z.B. Unterseite verwende, hängt stark vom Inhalt und von der Zielgruppe ab. Je allgemeiner/unerfahrener die Zielgruppe und umso stärker ich Wert auf das Bookmarking lege, desto eher bekommt jede Seite ein separates Frameset.

und das zweite bedeutet, dass die Pkt. 1

Kommt auf die Umsetzung an.

und 2. sich nochmals potenzieren.

Nein.

Doch, durchaus. Wenn du das als Autor allerdings universell machen willst (und nicht für jeden Anker ein eigenes FS erstellen möchtest), dann muß das Frameset allerdings dynamisch generiert werden, den Hash auslesen und in die FS-Definition integriert werden.
Du gehtst davon aus dass 100% deiner Besucher JS angeschaltet haben.

Keineswegs (auch wenn es faktisch fast soviele sind) - wie Du dem Archiv auch entnehmen könntest.

So etwas läßt sich auch Server-seitig erledigen.

Und auch hier, es tritt ein Problem auf und du dasgt man kann es lösen, es ist aber trotzdem noch ein Problem, dass zusätzliche (und evtl. erfolglose) Arbeit erfordert.

Anderswo hast Du keine zu lösenden Probleme?

Ich arbeite mit CGI und CMS seit ich Webseiten mache (da waren Mosaic 2 & Netscape 0.8 aktuell, PHP gab es nicht und bash & Perl waren das Maß der Dinge, Bill Gates dachte, das WWW wäre eine zu ignorierende Modeerscheinung und das CMS war - logischerweise - selbst programmiert). Ich arbeite mit Frames und JavaScript seit Anbeginn (also mit Erscheinen des Netscape 2). Ich achte auf zufriedenstellende Suchmaschinenergebnisse mindestens seit AltaVista. Und nutzbar sind meine Seiten selbst noch mit HTML-1-Browsern wie dem IE 1 oder Mosaic.

Ich glaube nicht, daß ich mich noch diesbezügl. mit Problemen herumschlagen muß, die einer Lösung bedürfen.

Daß Neueinsteiger da eher zu kämpfen haben, das glaube ich gerne (was für jede Technik gilt). Daß es ihnen auch nicht leichter gemacht wird, wenn ihnen stets ein reflexhaftes "Frames sind Mist" entgegengeschleudert wird, wenn ihnen nicht gesagt wird, wie sie etwaige Fallstricke vermeiden können, sondern ihnen stattdessen massig Hilfe geboten wird, wie man um die diversen CSS-Probleme herumkommt (oder auch nicht), sollte hingegen nicht verwundern, gell? =:-> (irgendwie erinnert mich das an "selbsterfüllende Prophezeiung" :))

Und Probleme aufzulisten, die eigentlich keine sind, oder zu behaupten/den Eindruck zu erwecken, zukünftig würde es ohnehin keine Frames mehr geben (wie es hier im Forum auch öfters mal vorkommt), würde ich als Verarschung werten ...

5. Versuch mal einem Freund mitzuteilen, wie er auf eine tolle Unterseite kommt (Geh auf www.xxx.de, klick da auf a, dann scroll zu b, klick dann auf d und um 12:00 erscheint der Link zu e. Dann bist Du bei f. Waaaahhh!)
   S. Punkt 3)
   d.h.?

Das ist exakt das "Bookmark-Problem".

Kommt drauf an. Es ist kein Problem, dynamisch den kompletten Content zusätzlich n den NOFRAMES-Bereich zu packen und ihn selbst nicht indizieren zu lassen.

Üblicher dürfte es aber sein, das passende Frameset einfach nachzuladen. Das ist ja nun wirklich kein Problem.

Mit JS, aber es ist wie unter 4. beschrieben nicht zuverlässig und wieder zusätzliche Arbeit.

Wenn Du keine Arbeit willst, dann mache keine Webseiten (oder gaaanz einfache HTML-1-Seiten?)! =:-o

Davon abgesehen: Bei mir geht *diese* Arbeit gegen 0 (bzw. ist gleich 0). Das läßt sich, ob mit JS oder PHP, sehr gut automatisieren. Wenn ein CMS zum Einsatz kommt (was zumindest ab einer gewissen Anzahl von Seiten oder bestimmten professionellen Umgebungen ohnehin mehr als sinnvoll ist), dann spielt das sowieso keine Rolle mehr, weil der Content ohnehin leicht mehrfach aufbereitet werden kann (einmal für NOFRAMES, einmal für den Frame, einmal vielleicht für eine Seite komplett ohne Grafiken/Schnickschnack, einmal für den RSS-Feed, einmal bis x-fach für Zwischenkunden die das Angebot unter eigenem Logo nutzen können sollen, ...).

Nein. Jede Seite darf so oder so ruhig eine "Breadcrumb"-Navigation enthalten. Einen "Lade Navigations-Frames"-Button dürfte auhc niemanden umbringen (zumal er meistens nicht sichtbar sei muß).
Zusätzlicher Aufwand nummero ???

Eine "Breadcumb"-Navigation ist kein zusätzlicher Aufwand, es ist eine sinnvolle Sache. Ganz egal, ob Du Frames benutzt oder nicht. :-o

wieso ist Fixierung ein Vorteil?

Weil der Anwender es ständig im Sichtfeld hat und intuitiver navigieren kann.

Uns hier macht es nichts aus, wenn die Menüs beim Scrollen verschwinden. Beim "Rentner von nebenan" sieht das ggf. schon ganz anders aus - zumal die Menüs von eventuell gewohnter Anwendungssoftware ja stets dort bleiben, wo sie sind - egal ob gescrollt wird oder nicht.

In aller Regel ist doch der Inhalt einer Seite wichtig und nicht das Logo oder das Menü.

Prinzipiell schon (umso schöner, wenn man den Content-Frame einfach ohne Navigation aufrufen kann). Aber insbesondere der unerfahrene Anwender muß erstmal zum Inhalt gelangen - und dann in ihm navigieren.

In der Regel bedeutet Fixierung aber eine Verkleinerung der Fläche die mir zum lesen zu Verfügung steht

Wir leiden z.Zt. wohl eher daran, daß die Bildschirmauflösungen viel zu groß sind, um Text noch sinnvoll frei fließen zu lassen - zumal eine Begrenzung mit CSS, max-width und Spaltensatz fällt mir da ein, noch etwas "problematisch" ist. :-(

Ich kann mit Frames jedenfalls keine diesbezügl. Probleme feststellen. Die Seiten bleiben gut nutzbar auch bei Auflösungen unterhalb 640x480 (z.B. Sharp Zaurus) - jedenfalls wenn man's nicht übertreibt mit den Frames. Für kleinere Displays, also nicht mehr Notepads sondern Handys, ist dies allerdings in der Tat ein Problem. Allerdings auch noch aus anderen Gründen ...

Außerdem lassen sich Frames immer noch nicht skalieren.

Vorausgesetzt, es ist überhaupt notwendig (andere Diskussion: Grafik- oder Textmenüs): Mit JS lassen sie sich wunderbar skalieren, und seit Anbeginn der Frames kann der Anwender die Framegrenzen manuell ändern. Und zwar ggf. auch dann, wenn der Framerahmen ausgeblendet wurde (OK, dann muß er es natürlich wissen).

Du hast also eine Reihe von Nachteilen, die für dich durch zweifelhafte Vorteile aufgehoben werden.

Unabhängig von einzelnen Bewertungen: Gibt es etwas ganz ohne Nachteile?

Und die du durch beträchliche Mehrarbeit versuchst zu kompensieren.

Davon kann, wie gesagt, keine Rede sein.

für mich persönlich  stellt das einen enormen Zeitgewinn und eine einfachere Seitengestaltung dar.

Für Dich mag das stimmen, für andere nicht. :-)

Gruß, Cybaer

[Efchen]

Moin,

schau mal, was Du geschrieben hast :-)

Aber verglichen mit den CSS-Workarounds und ggf. Ersatzlösungen für Nicht-CSS-Browser, ist das eine (zudem leicht zu automatisierende) "Peanut".

Und dann:

Nein. Man soll kluges, umsichtiges Webdesign betreiben. Dann muß auch für niemanden mehr was "optimiert" werden.

Ersatzlösungen für Nicht-CSS-Browser? Wozu?
Schreibe semantisches Markup und Trenne Layout (mit CSS) von Inhalt und Du brauchst keine Ersatzlösungen. Weil die Nicht-CSS-Browser kein CSS darstellen aber durch Dein semantisches Markup eine klar strukturierte Seite angezeigt bekommen. So soll es sein. "kluges, umsichtiges Webdesign" würde ich das nennen, da muss dann auch nichts mehr "optimiert" werden.

Ich arbeite mit CGI und CMS seit ich Webseiten mache [...] Und nutzbar sind meine Seiten selbst noch mit HTML-1-Browsern wie dem IE 1 oder Mosaic.

Da kriegt man den Eindruck, dass Du so ein alter Knacker bist, der in seinem hohen Alter auf gar keinen Fall noch was neues lernen will, weil er Angst hat, dass er den neuen Stoff nicht mehr versteht. Nichts für ungut, war keine Beleidigung, solche Leute gibts genug :-)

Und Probleme aufzulisten, die eigentlich keine sind, oder zu behaupten/den Eindruck zu erwecken, zukünftig würde es ohnehin keine Frames mehr geben (wie es hier im Forum auch öfters mal vorkommt), würde ich als Verarschung werten ...

Wenn Du mit "nicht mehr geben" meinst, dass die Browser sie nicht mehr unterstützen, dann wird dem wohl nicht so sein, da hast Du recht. Allerdings ist es FAKT, dass Frames ab XHTML 1.0 Strict nicht mehr zum Umfang von XHTML gehören, und somit tatsächlich nicht mehr existieren.

Frames wird es meines Wissens in einer der nächsten CSS-Versionen (3?) geben, aber dann nicht als Element der Strukturierung, sondern als Layout-Element (deswegen ja CSS). Wie das dann aussieht, kann ich Dir leider auch nicht sagen.

Unabhängig von einzelnen Bewertungen: Gibt es etwas ganz ohne Nachteile?

Wohl nicht :)
Aber man kann die Nachteile minimieren.

Und die du durch beträchliche Mehrarbeit versuchst zu kompensieren.

Davon kann, wie gesagt, keine Rede sein.

Ich möchte fast behaupten, dass das aber auch nur daran liegt, weil Du den relevanten Code bereits im Schlaf aus dem Ärmel schütteln kannst. Dinge, die man lange macht, sind immer einfacher als das Neue.

für mich persönlich  stellt das einen enormen Zeitgewinn und eine einfachere Seitengestaltung dar.

Für Dich mag das stimmen, für andere nicht. :-)

Für mich stimmt das auch :-)

[Cybaer]

Hi,

schau mal, was Du geschrieben hast :-)

Tue ich immer - es sei denn, ich bin in Zeitnot. ;-)

Ersatzlösungen für Nicht-CSS-Browser? Wozu?

Beachte das "ggf."! Notwendig nicht, hübsch sicher.

Man sollte natürlich auch bedenken, daß alte Nicht-CSS-Browser DIV und SPAN nicht kennen (na ja, eh verzichtbar).

Schreibe semantisches Markup und Trenne Layout (mit CSS) von Inhalt und Du brauchst keine Ersatzlösungen. Weil die Nicht-CSS-Browser kein CSS darstellen aber durch Dein semantisches Markup eine klar strukturierte Seite angezeigt bekommen. So soll es sein. "kluges, umsichtiges Webdesign" würde ich das nennen, da muss dann auch nichts mehr "optimiert" werden.

So würde ich das auch nennen. Hat aber per se nichts mit Frames zu tun.

Da kriegt man den Eindruck, dass Du so ein alter Knacker bist, der in seinem hohen Alter auf gar keinen Fall noch was neues lernen will, weil er Angst hat, dass er den neuen Stoff nicht mehr versteht.

Stillstand ist Rückschritt. An dem Tag, an dem Du nicht mehr bereit und/oder fähig bist, etwas Neues zu erlernen, solltest Du den Titel "Webdesigner" an den Nagel hängen. Eigentlich ohnehin eine Binsenweisheit, aber für ein sich so stetig entwickelndes Medium wie das Internet ...

Nichts für ungut, war keine Beleidigung, solche Leute gibts genug :-)

Du meinst, so wie Jüngere, die meinen, der letzte Schrei sei das alleinig seligmachende? :-)

Wenn Du mit "nicht mehr geben" meinst, dass die Browser sie nicht mehr unterstützen, dann wird dem wohl nicht so sein, da hast Du recht. Allerdings ist es FAKT, dass Frames ab XHTML 1.0 Strict nicht mehr zum Umfang von XHTML gehören, und somit tatsächlich nicht mehr existieren.

Die gehören schon nicht mehr zu HM 4.0 strict. Und was die zukünftigen, nicht mehr rückwärtskompatiblen XHTML-Versionen angeht: Ja, genau wie Links. Hurra, ein Web ohne Links ...

Aber vielleicht ist Dir der Begriff XLinks schonmal ins Ohr geflattert? Der Begriff XFrames offensichtlich noch nicht. Lesen junge Augen nur das, was sie lesen wollen? ;-)

Beschäftige Dich einfach mal mit dem Konzept von XHTML (Stichwort: Modularisierung).

Ich möchte fast behaupten, dass das aber auch nur daran liegt, weil Du den relevanten Code bereits im Schlaf aus dem Ärmel schütteln kannst.

Wenn ich das kann, können das andere nicht? So vermessenwürde ich wirklich nicht ein! :-)

Dinge, die man lange macht, sind immer einfacher als das Neue.

Also ich nutze auch weidlich CSS, falls Du da "Sorgen" hast. ;-) Aber ich verteufel auch nicht andere Techniken aufgrund von imaginären Vorurteilen, die vielleicht entstanden sind, weil andere es nicht besser können, man selber aber auch nicht? (Getreu dem Motto: "Also wenn ich es schon nicht kann, dann ja wohl niemand sonst!"? =:-o)

Für Dich mag das stimmen, für andere nicht. :-)
Für mich stimmt das auch :-)

Dann kann man ja durchaus CSS empfehlen, ohne bei jeder passenden und unpassenden Gelegenheit ein Pauschalurteil abzugeben, oder? Pauschalurteile sind nie passend - dazu sind Web/Aufgabenstellung/Auftaggeber i.d.R. doch zu verschieden ...

Gruß, Cybaer

[Efchen]

Moin,

Man sollte natürlich auch bedenken, daß alte Nicht-CSS-Browser DIV und SPAN nicht kennen (na ja, eh verzichtbar).

Macht ja keinen Unterschied. Wird ignoriert. span und div machen ohnehin nichts, und wenn Du einen Browser hast, der CSS nicht interpretiert, dann ist es irrelevant, ob der Browser div und span versteht oder nicht, denn die beiden bewirken ja nichts.

Und was die zukünftigen, nicht mehr rückwärtskompatiblen XHTML-Versionen angeht: Ja, genau wie Links. Hurra, ein Web ohne Links ...

Wie?

Aber vielleicht ist Dir der Begriff XLinks schonmal ins Ohr geflattert? Der Begriff XFrames offensichtlich noch nicht. Lesen junge Augen nur das, was sie lesen wollen? ;-)

Hmmm...bist also doch ein alter Knacker? ;) Ich fühle mich aber auch nicht mehr allzu jung ;) Und: Ich mache das alles nicht beruflich, sondern rein hobby-mäßig und habe nicht immer die Zeit dazu, die ich gern hätte, allein schon wegen meiner zwei Tamagotchis zuhause ;-)
Daher entschuldige ich mir das, dass ich wewder von XLinks noch von XFrames gehört habe. Ich kenne nur XWindows ;-)

Aber ich verteufel auch nicht andere Techniken aufgrund von imaginären Vorurteilen, die vielleicht entstanden sind, weil andere es nicht besser können, man selber aber auch nicht? (Getreu dem Motto: "Also wenn ich es schon nicht kann, dann ja wohl niemand sonst!"? =:-o)

Ich sagte ja, dass ich mit Frames umzugehen weiß und auch weiß, wie man all die klassischen "Darum-sind-Frames-Mist"-Gründe umgehen kann, weiß aber auch, dass man sich mit den Workarounds die nächsten Probleme einfängt.

Dann kann man ja durchaus CSS empfehlen, ohne bei jeder passenden und unpassenden Gelegenheit ein Pauschalurteil abzugeben, oder?

Ich finde das nicht als Pauschalurteil. Nach meinen Erfahrungen sind Frames keine gute Wahl und die Gründe habe ich ja dargelegt. Das ist für mich nicht "pauschal".

Pauschalurteile sind nie passend - dazu sind Web/Aufgabenstellung/Auftaggeber i.d.R. doch zu verschieden ...

Ausnahmen bestätigen wie immer die Regel :-)

Gruß,
-Efchen

[Gernot Back]

Hallo Efchen,

hast du meine Framelösung für Gunters Problem schon gesehen? Das geht vielleicht auch mit noch mehr JavaScript und CSS, dann auch ohne Frames, aber bestimmt nicht mit mit weniger, so schätze ich es jedenfalls ein.

http://www.sprachlernspiele.de/dynframe

Getestet bei mir in IE 6.0, Mozilla 1.6 sowie Opera 7.11 unter Windows 98 mit mickrigen 64 MB RAM, die bewirken, dass das Frameset ziemlich lange braucht, bis es sich sortiert hat.

Gruß Gernot

[Cybaer]

Hi,

Macht ja keinen Unterschied. Wird ignoriert.

Och, ein bißchen kenne ich mich mit HTML ja aus. >;->

span und div machen ohnehin nichts,

Was natürlich falsch ist. DIV ist ein Blockelement und der Inhalt beginnt in einer neuen Zeile. <div>X<div>HTML</div></div> sieht schon etwas anders aus, wenn der Browser DIV nicht kennt.

Alt:
XHTML

Neu:
X
HTML

Und was die zukünftigen, nicht mehr rückwärtskompatiblen XHTML-Versionen angeht: Ja, genau wie Links. Hurra, ein Web ohne Links ...
Wie?

Links lassen sich in SGML nicht verwenden. Auch hier wurde bei HTML Inhalt und Funktion vermengt. Nur logisch, daß das zukünftig getrennt wird. Die Definition der Links heißt XLinks, die Definition von Frames nennt sich XFrames und viele weitere Module machen XHTML zu dem, was es mal werden soll.

Hmmm...bist also doch ein alter Knacker? ;)

Na ja, noch ein Jahr und ich schließe die 30er ab ... =;-)
Ich habe also schon programmiert und Daten übers Netz geschoben (mit damals sagenhaften 300 Baud, also ca. 300 Bits/s), da waren viele hier noch nicht mal ein Funkeln in den Augen ihrer Eltern. :)

Ich fühle mich aber auch nicht mehr allzu jung ;)

Also *fühlen* fühle ich mich wie 30 - Minimum. ;->

Daher entschuldige ich mir das, dass ich wewder von XLinks noch von XFrames gehört habe.

Google und/oder W3C sind dein Freund - falls Du XHTML verstehen möchtest.

Ich kenne nur XWindows ;-)

Was schon deutlich mehr ist als nur Windows. :-)

Ich sagte ja, dass ich mit Frames umzugehen weiß und auch weiß, wie man all die klassischen "Darum-sind-Frames-Mist"-Gründe umgehen kann, weiß aber auch, dass man sich mit den Workarounds die nächsten Probleme einfängt.

Na, wenn Du das sagst ... =:}

Ich finde das nicht als Pauschalurteil. Nach meinen Erfahrungen sind Frames keine gute Wahl und die Gründe habe ich ja dargelegt. Das ist für mich nicht "pauschal".

Vielleicht hast Du "hobby-mäßig" unzureichende Erfahrungen? Könnte doch sein?! Rein theoretisch natürlich. ;->

Und Du kennst natürlich auch reichlich Hintergrund-Literatur, wie z.B. über Verkaufs-/Marketingpsychologie. Auch hast Du selbst Erfahrungen in Werbung und Verkauf und im Bereich Schulung. Das einzige, was hier fehlt, scheint mir die Fähigkeit zu sein, für Probleme die sich dir stellen, kreative Lösungen zu finden, die nicht den Namen "krude Workarounds mit noch mehr Problemen" tragen? ;-)

Gruß, Cybaer

[Efchen]

Moin,

span und div machen ohnehin nichts,

Was natürlich falsch ist. DIV ist ein Blockelement und der Inhalt beginnt in einer neuen Zeile. <div>X<div>HTML</div></div> sieht schon etwas anders aus, wenn der Browser DIV nicht kennt.

Ja, Du hast natürlich recht. Mein Fehler.

Links lassen sich in SGML nicht verwenden. Auch hier wurde bei HTML Inhalt und Funktion vermengt. Nur logisch, daß das zukünftig getrennt wird. Die Definition der Links heißt XLinks, die Definition von Frames nennt sich XFrames und viele weitere Module machen XHTML zu dem, was es mal werden soll.

Ich dachte, die Frames sollen mit CSS gemacht werden, nicht mit XHTML? Bah, ich glaub ich halt doch etwas öfter meinen Mund :-)

Hmmm...bist also doch ein alter Knacker? ;)

Na ja, noch ein Jahr und ich schließe die 30er ab ... =;-)

Okay, dahin hab ich noch ein bisschen, die Hälfte davon erreiche ich nächstes Jahr ;)

Ich habe also schon programmiert und Daten übers Netz geschoben (mit damals sagenhaften 300 Baud, also ca. 300 Bits/s), da waren viele hier noch nicht mal ein Funkeln in den Augen ihrer Eltern. :)

Mit 300baud Akustikkoppler im Internet...jaaaaa, das kenn ich auch noch. Und wehe, jemand hat auf den Boden gestampft! ;-)

Daher entschuldige ich mir das, dass ich wewder von XLinks noch von XFrames gehört habe.

Google und/oder W3C sind dein Freund - falls Du XHTML verstehen möchtest.

Naja, bei Gelegenheit vielleicht mal.

Ich kenne nur XWindows ;-)

Was schon deutlich mehr ist als nur Windows. :-)

Ja, darauf bestehe ich! Ich bin kein Gates-Jünger! Ich bin seit 1989 mit Unix in Kontakt, habe da diverses kennengelernt und arbeite auch heute noch unter SINIX, AIX, SCO Unixware und Linux. Nicht, dass ich so ein fanatischer Linux-Befürworter bin, aber ich kann diese Windows-Jünbger nicht leiden, die glauben, die Welt bestünde nur noch aus Windows. Das Internet damals ohne einen einzigen Windows-Rechner war in der Hinsicht fast angenehmer ;)

Ich finde das nicht als Pauschalurteil. Nach meinen Erfahrungen sind Frames keine gute Wahl und die Gründe habe ich ja dargelegt. Das ist für mich nicht "pauschal".

Vielleicht hast Du "hobby-mäßig" unzureichende Erfahrungen? Könnte doch sein?! Rein theoretisch natürlich. ;->

Ja. *seufz* Untypisch für mich, aber ich gebe nach, okay? :-)
Für *meine* Zwecke sind Frames keine Lösung. Und Nachteile *haben* sie. Und die Workarounds dafür haben *weitere* Nachteile. Das heißt nicht, dass es keine Anwendungsmöglichkeiten dafür gibt.

Und Du kennst natürlich auch reichlich Hintergrund-Literatur, wie z.B. über Verkaufs-/Marketingpsychologie. Auch hast Du selbst Erfahrungen in Werbung und Verkauf und im Bereich Schulung. Das einzige, was hier fehlt, scheint mir die Fähigkeit zu sein, für Probleme die sich dir stellen, kreative Lösungen zu finden, die nicht den Namen "krude Workarounds mit noch mehr Problemen" tragen? ;-)

Muss ich auch Psychologie studiert haben, um jetzt zu verstehen, warum dieser Studiengang eine Berechtigung für die Existenz von Frames ist?

Gruß,
-Efchen

[Cybaer]

Hi,

Ja, darauf bestehe ich! Ich bin kein Gates-Jünger! Ich bin seit 1989 mit Unix in Kontakt, habe da diverses kennengelernt und arbeite auch heute noch unter SINIX, AIX, SCO Unixware und Linux.

Ziemlich viel für einen jungen Hüpfer! (duck) ;-)

Ja. *seufz* Untypisch für mich, aber ich gebe nach, okay? :-)

Ist ja auch keine Schande. Wem ginge das mal nicht so?! :-))

Muss ich auch Psychologie studiert haben, um jetzt zu verstehen, warum dieser Studiengang eine Berechtigung für die Existenz von Frames ist?

Frames haben ihre Berechtigung, weil es sie gibt - und man mit ihnen, gewußt wie, auch problemlos arbeiten kann. Ob man sie einsetzt, ist nur eine Frage der Umstände und Bewertung selbiger. Wie gesagt: Ich sehe das eher neutral. Halt eine Technik von vielen ...

Gruß, Cybaer

[Efchen]

Moin,

Ziemlich viel für einen jungen Hüpfer! (duck) ;-)

Bäh. Wegen der 5 Jahre ... ;)

Ja. *seufz* Untypisch für mich, aber ich gebe nach, okay? :-)

Ist ja auch keine Schande. Wem ginge das mal nicht so?! :-))

Für mein Image schon ;)

Frames haben ihre Berechtigung, weil es sie gibt

Soweit ich das weiß, sieht das W3C das anders...aber da ich sag nicht bestätigen oder belegen kann, bleibt es einfach mal so im Raum stehen.

• und man mit ihnen, gewußt wie, auch problemlos arbeiten kann.

Naja. Als Fortgeschritteter, ja. Als jemand, der um die Probleme weiß, ja. Als DAU? Nein.

Ob man sie einsetzt, ist nur eine Frage der Umstände und Bewertung selbiger.

Naja, irgendwie schon.

Schönes Wochenende,
-Efchen

[Cybaer]

Hi,

Ziemlich viel für einen jungen Hüpfer! (duck) ;-)
Bäh. Wegen der 5 Jahre ... ;)

Hmm, 34?

Für mein Image schon ;)

Heute "verliert" man, morgen "gewinnt" man. Über sowas mache ich mir keinen Kopf - schont das Herz ... ;-)

Soweit ich das weiß, sieht das W3C das anders...

Na ja, immerhin wurden sie in HTML-Standard aufgenommen (und bleiben auch zukünftig drin).

Naja. Als Fortgeschritteter, ja. Als jemand, der um die Probleme weiß, ja. Als DAU? Nein.

Das betrifft aber die meisten Techniken.

Und wenn es nur Webseiten gäbe, mit HTML/CSS/Frames/JavaScript/PHP/... wo sich der Autor (halbwegs) gut mit auskennt, dann wäre Google wohl 'ne kleine Klitsche mit einem größeren PC & Raid-Controller ... >>;->>

Gruß, Cybaer

[Efchen]

Moin,

Hmm, 34?

Mathe LK? ;-)

Soweit ich das weiß, sieht das W3C das anders...

Na ja, immerhin wurden sie in HTML-Standard aufgenommen (und bleiben auch zukünftig drin).

Naja, wenn nichts anderes da ist, kann man sowas schon mal aufnehmen.
Und zukünftig kommen sie doch nur in CSS vor, aber nicht mehr in HTML.

Naja. Als Fortgeschritteter, ja. Als jemand, der um die Probleme weiß, ja. Als DAU? Nein.

Das betrifft aber die meisten Techniken.

Aber einige sind definitiv einfacher, als das Umgehen der Frames-Probleme.

Und wenn es nur Webseiten gäbe, mit HTML/CSS/Frames/JavaScript/PHP/... wo sich der Autor (halbwegs) gut mit auskennt, dann wäre Google wohl 'ne kleine Klitsche mit einem größeren PC & Raid-Controller ... >>;->>

Unkommentiert außer mit einem Grinsen :-)

Gruß,
-Efchen

[Cybaer]

Hi,

Hmm, 34?
Mathe LK? ;-)

Wie hast Du das erraten? :-)

OK, nehme alles zurück, was "hüpft"! ;-)

Und zukünftig kommen sie doch nur in CSS vor, aber nicht mehr in HTML.

So so ...

Gruß, Cybaer

[Efchen]

Da würde es mich freuen, mal wirklich eine konkrete Liste zu haben, die man abarbeiten kann! :-o

Und? Habe ich Deine Erwartungen erfüllt? :-)

1. Inkompatibilität zu manchen Browsern.

Ich kenne zumindest keinen Browser, der mit FRAMES und dazugehörigen NOFRAMES(!) inkompatibel wäre. Du wirst mir auch keinen nennen können.

Nein. Richtig.

3. Kein Bookmarken von Unterseiten möglich.

Niemand zwingt den Autor, Unterseiten zu verwenden. Ebenso ist es möglich, für jede Seite ein eigenes Framest zu erstellen (oder es automatisch generieren zu lassen).

Dann wäre aber einer der Vorteile von Frames dahin: Nämlich, dass nur der Inhalt ausgetauscht wird, und wiederkehrende Teile der Seite stehenbleiben. Mit dem Neuaufbau eines kompletten Framesets steigt die Ladezeit außerdem deutlich an.
Das ließe sich dann mit include() besser lösen.

4. Kein direktes Verlinken von Unterseiten möglich.

Doch, durchaus. Wenn du das als Autor allerdings universell machen willst (und nicht für jeden Anker ein eigenes FS erstellen möchtest), dann muß das Frameset allerdings dynamisch generiert werden, den Hash auslesen und in die FS-Definition integriert werden.

Indem Du eine serverseitige Technik verwendest. Und am Ende doch wieder je Seite ein neues Frameset aufbaust. Die Ladezeit wird erhöht. Und was die Besucher nicht verstehen, warum ist da ein Frameset, wenn dann doch wieder alle Frames neu geladen werden.

6. Von Suchmaschinen endizierte Unterseiten erscheinen ohne das Frameset.

Kommt drauf an. Es ist kein Problem, dynamisch den kompletten Content zusätzlich n den NOFRAMES-Bereich zu packen und ihn selbst nicht indizieren zu lassen.

Klar.

Üblicher dürfte es aber sein, das passende Frameset einfach nachzuladen. Das ist ja nun wirklich kein Problem.

Wenn JavaScript deaktiviert ist, schon.

Frames bieten keinerlei wirklich Vorteile, die wirkliche Vorteile sind und nicht auch anders machbar sind.

Alleine schon die Fixierung ist ein Vorteil - jedenfalls solange es Browser verwendet werden, die ds mit CSS nicht so schön hinkriegen (wenn überhaupt).

Nun gut. Es ist halt außerordentlich schade, dass ein Dinosaurier unter den Browsern die Weiterentwicklung im Web verhindert. Andererseits finde *ich persönlich* bislang fixe Elemente nutzlos.

Das Trennen von Seitenteilen in verschiedene Dateien zum Zwecke des Nur-Einmal-Schreiben-Müssens lässt sich besser mit einer serverseitigen Include-Technik bewerkstelligen.

Die steht nicht jedem zur Verfügung. Steht sie zur Verfügung, können einige Nachteile der Frames per se entfallen. :-)

Wenn sie nicht zur verfügung steht, dann kannst Du aber auch einige Frames-Nachteile nicht ausbessern :)
Und wenn sie zur Verfügung steht, dann kannst Du es auch nutzen, das geht schneller udn einfacher und übersichtlicher, als der Haufen Workarounds für Frames.

Wie ich schon bei ... wie hieß der jetzt? Na, im Posting unten halt :)
geantwortet habe, ich habe auch shcon vor einigen Jahren eine Site mit Frames gemacht, bei denen jede Seite eine eindeutige URL hatte, bookmarken, direkt verlinken und so also problemlos möglich war, das Frameset wurde mit JavaScript nachgeladen und auch im noframes-Bereich habe ich mich so ausgetobt, dass die Site in Suchmaschinen zu finden war, und sie war komplett auch im Mosaic 3 (ohne Frames) lauffähig.

Allerdings hat mich daran gestört:
a) Der Einsatz einer serverseitigen Technik zum Aufbau des Framesets
b) Die daraus resultierende lange Ladezeit jeder Seite
c) Die Abhängigkeit von JavaScript

Am meisten aber wirklich die lange Ladezeit und das Aufblitzen beim erneuten Aufbau des Framesets. Da ich nicht der Meinung bin, dass fixe Elemente so wichtig sind, kann ich eine Site auch einfach mit include ohne Frames machen, das gefällt mir heute wesentlich besser.

Gruß,
-Efchen

[Cybaer]

Hi,

Und? Habe ich Deine Erwartungen erfüllt? :-)

Ja, danke. Also mir fällt, zumindest auf die Schnelle, kein weiteres "Gegenargument" ein. :-o

Dann wäre aber einer der Vorteile von Frames dahin: Nämlich, dass nur der Inhalt ausgetauscht wird, und wiederkehrende Teile der Seite stehenbleiben. Mit dem Neuaufbau eines kompletten Framesets steigt die Ladezeit außerdem deutlich an.

Ach was. Zumal die Nav-Frames gecachet sind.

Das ließe sich dann mit include() besser lösen.

Eine Möglichkeit - so PHP zur Verfügung steht.

Indem Du eine serverseitige Technik verwendest.

... oder Client-seitige oder parallel beides.

Und am Ende doch

wieder je Seite ein neues Frameset aufbaust. Die Ladezeit wird erhöht.

Wenn: Um wieviele Millisekunden?

Und was die Besucher nicht verstehen, warum ist da ein Frameset, wenn dann doch wieder alle Frames neu geladen werden.

Das müssen wohl echte Grübler sein. ;-) Na ja, wenigstens "blitzt" der IE dabei nicht ...

Üblicher dürfte es aber sein, das passende Frameset einfach nachzuladen. Das ist ja nun wirklich kein Problem.
Wenn JavaScript deaktiviert ist, schon.

Nein.

Wenn sie nicht zur verfügung steht, dann kannst Du aber auch einige Frames-Nachteile nicht ausbessern :)

Kommt drauf an. Aber es fehlen dann die gelobten Alternativen. :)

Am meisten aber wirklich die lange Ladezeit und das Aufblitzen beim erneuten Aufbau des Framesets. Da ich nicht der Meinung bin, dass fixe Elemente so wichtig sind, kann ich eine Site auch einfach mit include ohne Frames machen, das gefällt mir heute wesentlich besser.

Jedem das seine! :-) Und meine Seiten sind von gar nichts abhängig - außer einem Browser, der HTML darstellen kann. ;-)

Gruß, Cybaer

[Beat]

3. Kein Bookmarken von Unterseiten möglich.

Man kann sich Frames in einem neuen Browserfenster anzeigen lassen
damit hat man auch den Bookmark in der Adressleiste

4. Kein direktes Verlinken von Unterseiten möglich.

Aus Verfahren in Punkt 3 wird deutlich dass es möglich ist.

mfg beat

[Efchen]

Moin,

3. Kein Bookmarken von Unterseiten möglich.

Man kann sich Frames in einem neuen Browserfenster anzeigen lassen
damit hat man auch den Bookmark in der Adressleiste

Ja, man kann auch den aktuellen Frame ohne Frameset im aktuellen Fenster anzeigen lassen. Man kann so vieles. Aber glaubst Du, das kann der durchschnittliche DAU? Wenn hier im Forum sogar von einigen gepredigt wird, dass der Standard-WWW-Nutzer nichtmal "Link speichern unter" kennt, und somit immer wieder so sinnfreie Lösungen wie das Zippen von Dateien, damit man sie Downloaden kann, angeboten werden, dann kannst Du auch von sowas nicht ausgehen. Und es geht ja darum, dem Benutzer eine Website so einfach wie möglich, und alle Websites insgesamt so gleich wie möglich zu machen. Und nicht darum, Browserfunktionen, die überall gelten sollten, durch solche Dinge wie Frames kaputt zu machen.

Genaugenommen gibts natürlich auch "Lösungen", das Bookmarken trotz Frameset zu erlauben. Problemlos. Allerdings hast Du damit ne Abhängigkeit von einer serverseitigen Technik (wohingegen Frames noch von DAUs geschrieben werden können, werden sie hieran versagen) und u.U. etwas kompliziertere URLs.

4. Kein direktes Verlinken von Unterseiten möglich.

Aus Verfahren in Punkt 3 wird deutlich dass es möglich ist.

Nein. Auch wenn Punkte 3 und 4 verwandt sind, aber das Verlinken von Unterseiten (inkl. Frameset versteht sich, denn was bringt mir eine Unterseite, wenn ich den Rest nicht habe, der ja zumeist aus der essentiellen Navigation besteht) ist mit der Methode nicht möglich. Dazu bedarf es des Einsatz weiterer Umgehungstechniken seitens des Admins der Website, auf die der Verlinkende keinen Einfluss hat.

Gruß,
-Efchen

[Cybaer]

Hi,

Aber glaubst Du, das kann der durchschnittliche DAU?

Kann er IMHO nicht. Nach meiner Erfahrung können das selbst viele User nicht, die selbst (hobby-mäßig) Webseiten schreiben. =:-o

Dazu bedarf es des Einsatz weiterer Umgehungstechniken seitens des Admins der Website, auf die der Verlinkende keinen Einfluss hat.

Also für mich ist das "direkte Linken auf Unterseiten" eigentlich ein Link "mitten auf eine Unterseite" (z.B. "contentframe.htm#Absatz1"), also der Link auf einen Anker. Nun wird man sicherlich nicht für jeden Zielanker ein eigenes Frameset machen, aber man kann den Hash auch in einem Frameset verwenden, wenn man ihn z.B. mittels PHP und/oder JavaScript im Frameset-SRC generiert.

Gruß, Cybaer

[Beat]

Ja, man kann auch den aktuellen Frame ohne Frameset im aktuellen Fenster anzeigen lassen. Man kann so vieles. Aber glaubst Du, das kann der durchschnittliche DAU?

Der Durchschnitt kann genau das:
sterben.
Der Durchschnitt ist irrelevant um an ihm eine absolute Maxime (zum Beispiel gegen Frames) zu begründen.
Der Durchschnitt hat noch nicht einmal 1 PC geschweige denn einen Internetzugang.
Und wenn dir der Durchschnitt so die Norm abgäbe dann dürften die Webautoren noch nicht einmal eine CSS Datei benutzen.

Wenn hier im Forum sogar

Dieses Forum hat kein Gütesiegel

von einigen gepredigt wird, dass der Standard-WWW-Nutzer nichtmal "Link speichern unter" kennt, und somit immer wieder so sinnfreie Lösungen wie das Zippen von Dateien, damit man sie Downloaden kann, angeboten werden, dann kannst Du auch von sowas nicht ausgehen.

Bitte die Hysterie deiner "Prediger" hat nichts mit Frames zu tun.....
Downloadversionen sind ein ALL IN ONE Produkt inklusive Bilder CSS Files etc. und sind deshalb für diese Diskussion gar nicht relevant noch ein Argument. Gerade in Downloadversionen finden Frames im lokalen Anwendungsbereich den Schrecken, den man ihnen sonst abergläubisch zumisst.

Und es geht ja darum, dem Benutzer eine Website so einfach wie möglich, und alle Websites insgesamt so gleich wie möglich zu machen. Und nicht darum, Browserfunktionen, die überall gelten sollten, durch solche Dinge wie Frames kaputt zu machen.

du meinst _zu ersetzen_ ....
Deine Aussage ist wiederum off, denn sie unterstellt dass Framelinks die übliche Navigation ersetzen. Das ist aber kein Argument gegen das was ich gesagt habe, dass es möglich sei, Frameseiten lokal zu speichern.
Dass Framenavigation eine übliche Navigation -in der Regel- nicht ersetzen kann: Dies bestätige ich. Dies steht aber hier nicht zur Debatte.

Genaugenommen gibts natürlich auch "Lösungen", das Bookmarken trotz Frameset zu erlauben.

Genau genommen, rechtklick frame in neuem Fenster.
Oder welche Lösung meinst du?

Problemlos. Allerdings hast Du damit ne Abhängigkeit von einer serverseitigen Technik

also anscheinend doch nicht so problemlos ....?

(wohingegen Frames noch von DAUs geschrieben werden können, werden sie hieran versagen) und u.U. etwas kompliziertere URLs.

Mit serverseitiger Technik kann mehr kaputt gemacht werden als mit Frames.
Ich habe oft gerätselt, wie ich jetzt diese sch... index.php mit wechselndem Inhalt überhaupt bookmarken sollte, wenn ich durch Servertechnik keinen effektiven Bookmark Link bekomme.

Aus Verfahren in Punkt 3 wird deutlich dass es möglich ist.

Nein. Auch wenn Punkte 3 und 4 verwandt sind, aber das Verlinken von Unterseiten (inkl. Frameset versteht sich, denn was bringt mir eine Unterseite, wenn ich den Rest nicht habe, der ja zumeist aus der essentiellen Navigation besteht) ist mit der Methode nicht möglich.

......wenn ich die Seite eines Frames in einem neuen Fenster öffnen kann, dann ist die Bedingung für einen Bookmark erledigt, der Rest interessiert nicht.
Warum brauchst du das Franmeset für einen Bookmark ?????
Ich gehe davon aus, dass eine normale Navigation immer wieder das Frameset aufrufen kann, um den übergeordneten Zusammenhang aufzurufen.

Dazu bedarf es des Einsatz weiterer Umgehungstechniken seitens des Admins der Website, auf die der Verlinkende keinen Einfluss hat.

Er muss nämlich nicht weniger oder mehr als eine scheissnormale Navigation bauen. Aber das bezweifle ich nicht und steht nicht zur Debatte.

Gruß,
-Efchen

mfg Beat

[Efchen]

Moin,

jaja, Du hast schon recht und ich bin doof.
Ich denke, Du redest außerdem von was ganz anderem als ich, also beenden wir diese Diskussion hier.

Gruß,
-Efchen

[Gernot Back]

Moin Efchen,

also das Thema finde ich jetzt total spannend. Deshalb Gunter, wenn's keine Firmengeheimnisse sind, rück doch mal mit deiner Riesentabelle raus! Dann können wir experimentieren!

Gruß Gernot

[Gunter]

Hallo Zusammen,

gestern konnte ich leider die Diskussion nicht verfolgen, ich gebe euch hier die Website, dann könnt Ihr euch das Problem in natura ansehen.

www.ffkaichen.de , links in Navi Leiste Protokolle anwählen, dann den Link Vorstand in tabellarischer Aufstellung aufrufen.

Danke Gunter

[Gernot Back]

Hallo Gunter,

das ist ja wirklich ein Mordsding von Tabelle, und zwar nicht so sehr an der Oberfläche wie im Quelltext. Der sieht ja mit Excel erstellt offensichtlich noch monströser aus, als wenn man das mit Microsoft Word tut.

Ich habe spaßeshalber mal - wie beschrieben - ein Frameset mit vier Frames über Kreuz gebaut, in das die Monster-Tabelle vier mal geladen wird. Aber schon bei dem Versuch, die Einzelteile so mit negativen Absolutwerten des Hauptdivs ins OFF zu versetzen, dass die Überschriften nicht doppelt angezeigt werden, macht Mozilla schlapp.

Es gibt in deiner Tabelle viel mehr CSS-Klassen als nötig. Ein halbes Dutzend sollte nach meiner Einschätzung ausreichen und darin braucht es auch beileibe nicht so viele Angaben. Es gibt auch viel mehr Tabellenzellen als erforderlich, davon könnte man einige mit colspan  zusammenfassen. Ich fürchte, dass bei soviel Ballast, wie im Moment in der Tabelle steckt, die Scrollkoordination der Frames auch im MSIE scheitern muss.

Wenn es dir also wichtig ist, dann bereinige das mal mit einem vernünftigen Editor. Dann kann man bestimmt auch das mit den jeweils nur in eine Richtung scrollenden Überschriftenframes regeln. Aufwändig bleibt das Vorhaben aber in jedem Fall.

Gruß Gernot

[Struppi]

Hallo Zusammen, ich habe eine Vorstandsübersicht in einer Homepage. Mein Problem ist, das diese sehr groß ist. Ich habe links einen Frame mit Namen und oben einen Frame mit Jahreszahlen eingesetzt. Wenn nun ein User nach unten scrollt, verschwinden die Jahrezahlen, scrollt er nach rechts, verschwinden die Namen. Gibt es in HTML, oder Java eine ähnliche Funktion wie in Excel der Befehl Fenster fixieren??

Du meinst spalten oder Zeilen?
Du kannst Bereiche mit CSS fixieren (position:fixed) das klappt im IE aber nur mit Tricks.
http://de.selfhtml.org/css/eigenschaften/positionierung.htm#position
http://www.fabrice-pascal.de/artikel/posfixedie6/

Struppi.

[Gernot Back]

Hallo Struppi,

so wie ich Gunter verstanden habe, würde ihm das nicht helfen, denn die Überschriften oben sollen nur horizontal gescrollt werden, die Überschriften links aber nur vertikal, je nachdem wie die übrigen Informationen, die unter diesen Überschriften stehen scrollen. Von "fixed" kann also gar keine Rede sein, allenfalls in jeweils einer Richtung.

Gruß Gernot

[Fritz]

Hallo Zusammen,

Hallo

Gibt es in HTML, oder Java eine ähnliche Funktion wie in Excel der Befehl Fenster fixieren??

Also in Java kannst du sowas sehr schön mit "Layout Managers" (Border Layout, Grid Layout, etc...) lösen.

Fritz

PS: Vermutlich wird dir folgender Link weiterhelfen. Beachte besonders Unterpunkt: 1.4.1 Java und...
http://www.galileocomputing.de/openbook/javainsel/java-01.htm#Xxx819841

[Cybaer]

Hi,

Gibt es in HTML, oder Java eine ähnliche Funktion wie in Excel der Befehl Fenster fixieren??

Mir ist etwas eingefallen, was ohne Scrollen auskommt:

Ignoriere die Scrollbalken ganz! Stattdessen mach selbst eine "Blättere nach unten"- und eine "Blättere nach oben"-Funktion. Mach eine normale Tabelle mit den Daten und blende nur die Zeilen und Spalten ein, die Du dargestellt haben willst (geht mit http://Coding.vampirehost.de/Toggle). Wieviele Zeilen & Spalten Du darstellen kannst, ergibt sich aus Breite und Höhe der Zellen und der Breite des Browserfensters (letzteres ist ermittelbar mit http://Coding.vampirehost.de/Systemvariable).

Surfer ohne JavaScript hätten dann noch die komplette Tabelle mit allen Daten, aber beim Scrollen verschwinden dann logischerweise Namen und/oder Zahlen. Eine IMHO faire Lösung, mit der alle leben können und den JavaScript-Surfern einen Zusatznutzen bringt.

Ist IMHO die am einfachsten umzusetzende und in alle Richtungen kompatibelste Variante.

Eine Nicht-DHTML-Lösung wäre noch mit PHP denkbar, indem der sichtbare Ausschnit mit PHP als Grafik erstellt wird. Weniger elegant, aber wohl die einfachste Lösung.

Gruß, Cybaer

[Gernot Back]

Hallo Gunter,

normalerweise mache ich ja nicht anderen die Hausaufgaben, aber das Problem fand ich spannend, zumal die Frage hier ja auch häufiger gestellt zu werden scheint:

[pref:t=84723&m=497216]

Die Sache geht mit dem onScroll-Event in der von mir schon weiter unten beschriebnen Weise in modernen Browsern:

http://www.sprachlernspiele.de/dynframe

Allerdings braucht es, obwohl ich die ursprünglich von Excel angelegten Klassen radikal durchgeforstet habe, immer erst einmal eine Weile, bis sich das Frameset sortiert hat. Es waren auch zum Ausgleich der Scrollleisten zwei weitere leere Frames nötig, insgesamt also sechs.

Elegant ist das so alles bestimmt nicht, auch wenn die Scrollkoordinationsfunktion dann mit dem onScroll-Event doch leichter war, als zuerst befürchtet.

Du kannst ja mal mal versuchen, ob du eine der anderen vorgeschlagenen Lösungen umsetzen kannst.

Gruß Gernot

[Cybaer]

Hi,

Elegant ist das so alles bestimmt nicht,

Ds Problem ist, daß bei nicht vorhandenem JS die Legende nicht mehr mitläuft, obwohl man scrollt.

Also hier IMHO entweder auf Frames verzichten und nur mit DHTML arbeiten, oder das Frameset zur Laufzeit mit JS erstellen. Geht das nicht, bekommt der Surfer halt die große Tabelle zum 2unkontrollierten Scrollen" (genau wie bei einer DHTML-Lösung ohne JS halt auch).

Gruß, Cybaer

PS: Aber ich stimme zu: Mal was anderes im "wie ändere ich 2 Frames gleichzeitig"-Einerlei. ;-)

[Gernot Back]

Hallo Cybear,

Ds Problem ist, daß bei nicht vorhandenem JS die Legende nicht mehr mitläuft, obwohl man scrollt.

Doch tut sie, weil nämlich dann das Ganze mit zwei mal zwei Legenden angezeigt wird, je einer horizontal und einer vertikal im Hauptframe mitlaufenden und zwei weiteren, die statisch bleiben.

Es wird ja viermal die gleiche Tabelle in die Frames geladen. Im Hauptframe unten rechts wird sie um die Breite der ersten Spalte und um die Höhe der ersten Zeile erst onLoad entsprechend ins "negative Off" versetzt.

Aber du hast Recht, den unnötigen Platzverlust bei nicht-aktiviertem JS könnte man mit einer vorgeschalteten JS-Weiterleitung auch noch abfangen.

Gruß Gernot

[Cybaer]

Hi,

Doch tut sie, weil nämlich dann das Ganze mit zwei mal zwei Legenden angezeigt wird, je einer horizontal und einer vertikal im Hauptframe mitlaufenden und zwei weiteren, die statisch bleiben.

Nein, tut sie nicht! (Fuß-aufstampf) ;-)

Ohne JavaScript hast Du statische Legenden in den Frames, sowie die "assoziierten" Legenden im Hauptframe selbst.

Scrollst Du den Hauptframe nun diagonal, wandern die "assoziierten" Legenden aus dem Bild, die statischen bleiben so, wie sie sind - und passen nicht mehr zum Inhalt des gescrollten Hauptframes.

Ergo: Kein JavaScript -> keine Frames mit statischer Legende.

Gruß, Cybaer

[Gernot Back]

Hallo Cybaer,

ich glaube, wir reden aneinander vorbei: Was wir wollen, aber natürlich ohne JavaScript niemals bekommen werden, sind halbstatische Legenden oben und links, die nur in jeweils eine Richtung mitscrollen.

Ohne JavaScript haben wir in meinem Frame unten rechts aber einen Bereich, der in beide Richtungen scrollt, mitsamt den Legenden, die dann natürlich auch schnell aus dem Blickfeld verschwinden.

Die zusätzlichen, in beiden Richtungen statischen Legenden nehmen oben und links dann auch ohne JS noch unnötig Platz weg. Aber das kann man ja mit einer vorgeschalteten JS-Weiterleitung lösen, die von der entsprechenden Tabelle ohne Frames auf das Frameset geht.

Ich arbeite übrigens gerade weiter an einer Vereinfachung der Monstertabelle mit colspans und stattdessen per Hintergrundkachel imitierten Zellenbegrenzungen.

Vielleicht schreibe ich was dazu als Tipps- und Tricks-Artikel, wenn ichs anständig hinbekomme.

Gruß Gernot