Frames und Tabbed Browsing

[muderseb]

Hallo liebe Forumsmitglieder

meine erste (natürlich mit Hilfe von SELFHTML :-) fertiggestellte Website nähert sich der Vollendung, und ich hätte eine Frage bzgl. von Frames. Diese habe ich nämlich eingesetzt, um eine bequeme Seitenaufteilung zu erreichen und zu verhindern, zentrale Bestandteile wie Navi-Leisten immer in jeder Unterseite neu formulieren zu müssen => erhöhter Wartungsaufwand.

Mein Problem lautete: Wie verhindert man, dass beim Öffnen der Verweise in Tabs nicht nur die Unterseite dort auftaucht, sondern das gesamte Frameset mit Navigationsleiste etc.?

Meine Lösung ist bisher wenig elegant: Ich habe alle Verweise so definiert, dass sie nicht mehr auf Einzelseiten, sondern ihrerseits auf Framesets verweisen, in denen auch die Navi-Leist etc. wieder neu geladen wird. Problem: Dadurch geht m.E. ein möglicher Geschwindigkeitsvorteil von Frames, dass man nämlich das zentrale Frameset nur einmal laden und ansonsten immer nur eine Einzelseite neu lädt, verloren.

Ich vermute mal, dass man auch mit JavaScript operieren könnte (in SELFHTML selbst wird ja beschrieben, wie man zwei Fenster gleichzeitig in verschiedene Frames lädt, dass müsste doch dann auch mit [in meinem Fall] fünf Fenstern möglich sein?) - aber wie genau würde das funktionieren?

Oder gibt es vielleicht noch einen besseren Weg???

Würde mich freuen, Ratschläge von euch zu hören!

Viele Grüße,
Sebastian

[wucher wichtel]

Hallo!

meine erste (natürlich mit Hilfe von SELFHTML :-) fertiggestellte Website nähert sich der Vollendung,

Cool :-)

und ich hätte eine Frage bzgl. von Frames.

Hmm... Frames sind nicht so toll. Genaugenommen sogar ziemlich schlecht.

Diese habe ich nämlich eingesetzt, um eine bequeme Seitenaufteilung zu erreichen und zu verhindern, zentrale Bestandteile wie Navi-Leisten immer in jeder Unterseite neu formulieren zu müssen => erhöhter Wartungsaufwand.

Dann lagere deinen Quelltext aus. Mit PHP, Perl, SSI oder sonstirgendwas. Wir helfen dir dabei. Aber benütze keine Frames. Das macht dir nur Probleme - wie du gerade eben siehst.

Mein Problem lautete: Wie verhindert man, dass beim Öffnen der Verweise in Tabs nicht nur die Unterseite dort auftaucht, sondern das gesamte Frameset mit Navigationsleiste etc.?

Das geht mit JavaScript. Mein Tip: Lass die Finger davon. Mach es mit irgendwas serverseitigem :) Wenn du dir aber Ärger einhandeln willst, dann hiflt dir eine Googlesuche weiter ;-)

Oder gibt es vielleicht noch einen besseren Weg???

Jaaaaa! ;-) Bei PHP mit include. Das geht mit jeder serverseitigen Sprache.

ciao, ww

[muderseb]

Hallo zusammen,

Hmm... Frames sind nicht so toll. Genaugenommen sogar ziemlich schlecht.

Erst mal danke für die schnelle Antwort!!
Dass das allgemeine Auffassung ist, ist mir natürlich bereits bekannt... und ich habe damit ja auch tatsächlich Probleme, wie man sieht. *seufz* Aber da ich mich erst seit vier Wochen in meiner Freizeit mit (X)HTML und CSS beschäftige, bin ich noch nicht zu PHP gekommen - abgesehen davon, dass diese Technologie in der aktuellen Version von SELFHTML auch gar nicht beschrieben wird.

Dann lagere deinen Quelltext aus. Mit PHP, Perl, SSI oder sonstirgendwas. Wir helfen dir dabei. Aber benütze keine Frames. Das macht dir nur Probleme - wie du gerade eben siehst.

Ja, Perl, wäre wohl dann meine Wahl, da das in der Dokumentation beschrieben wird. Wäre aber nett, wenn man mir sagen könnte, wie ich als Anfänger da am besten vorgehe bzw. mir zumindest im Groben erklärt, was zu tun ist zum Auslagern von Quelltext. Genaueres Nachlesen kann ich dann ja selbst. Meine bisherigen Programmierkenntnisse sind nämlich bisher gleich null.

Viele Grüße,
Sebastian

[steckl]

Hi,

Ja, Perl, wäre wohl dann meine Wahl, da das in der Dokumentation beschrieben wird.

Ich mag zwar eigentlich Perl lieber wie PHP, aber ich glaube wenn du "nur" Quelltext auslagern willst ist das mit PHP einfacher. Hier musst du nur eine Zeile einbauen:
<?PHP include("name_der_datei_mit_der_navigation"); ?>

Wäre aber nett, wenn man mir sagen könnte, wie ich als Anfänger da am besten vorgehe bzw. mir zumindest im Groben erklärt, was zu tun ist zum Auslagern von Quelltext. Genaueres Nachlesen kann ich dann ja selbst. Meine bisherigen Programmierkenntnisse sind nämlich bisher gleich null.

In den FAQ gibt es einen extra Punkt zum Auslagern von Quelltext. Hier sind auch Links zum Thema.

mfG,
steckl

[muderseb]

Super, danke für den Link!

Den werde ich mir erstmal in Ruhe durchlesen, zusammen mit dem Link zu dem PHP-Tutorial.

Viele Grüße und danke für eure schnelle Hilfe,
Sebastian

[wucher wichtel]

Hallo!

Erst mal danke für die schnelle Antwort!!

Bitte.

Dass das allgemeine Auffassung ist, ist mir natürlich bereits bekannt...

Das ist schon mal besser als nichts :-)

und ich habe damit ja auch tatsächlich Probleme, wie man sieht. *seufz*

Das ist mit Frames immer so.

Aber da ich mich erst seit vier Wochen in meiner Freizeit mit (X)HTML und CSS beschäftige, bin ich noch nicht zu PHP gekommen

Dann spiel noch ein bisschen rum. Wenn du dich in HTML & CSS eingelebt hast kannst du dich ja mit PHP beschäftigen.

• abgesehen davon, dass diese Technologie in der aktuellen Version von SELFHTML auch gar nicht beschrieben wird.

SELFHTML kann leider nicht alles abdecken. Dafür gibt es andere Tutorials die PHP sehr gut behandeln. Und am Ende ist es am besten einfach damit zu spielen.

Ja, Perl, wäre wohl dann meine Wahl, da das in der Dokumentation beschrieben wird.

Ich weiß nicht, wie aktuell die Perl-Dokumentation ist. Wir helfen dir auch, wenn du von einem anderen Tutorial lernst :-) Wenn du PHP lernen willst, dann könnte ich dir http://tut.php-quake.net/ empfehlen.

Wäre aber nett, wenn man mir sagen könnte, wie ich als Anfänger da am besten vorgehe bzw. mir zumindest im Groben erklärt, was zu tun ist zum Auslagern von Quelltext.

Bei PHP kann ich dir weiterhelfen. Mit Perl leider nicht. Entscheide dich zuerst welche Sprache du lernen willst. Dann findet sich sicher jemand, der dir hilft.

ciao, ww

[muderseb]

Hallo,

Ich weiß nicht, wie aktuell die Perl-Dokumentation ist. Wir helfen dir auch, wenn du von einem anderen Tutorial lernst :-) Wenn du PHP lernen willst, dann könnte ich dir http://tut.php-quake.net/ empfehlen.

Danke für den Link. Ich habe mir die Dokumentation gerade angesehen und werde versuchen, mich in den nächsten Tagen bis zu dem "include"-Abschnitt vorzuarbeiten. Wenn dann Fragen offen sind, poste ich einfach.

Bei PHP kann ich dir weiterhelfen. Mit Perl leider nicht. Entscheide dich zuerst welche Sprache du lernen willst. Dann findet sich sicher jemand, der dir hilft.

Die allgemeine Meinung hier scheint ja zu sein, dass PHP für das bloße Auslagern vollkommen genügt. Daher werde ich zuerst mal da reinschauen und gucken, wie weit ich als Non-Programmierer komme. Das Tutorial von Deinem Link oben scheint ja tatsächlich auch für Anfänger gedacht zu sein.

Also vielen vielen Dank erstmal!

Sebastian

[MudGuard]

Hi,

Ja, Perl, wäre wohl dann meine Wahl, da das in der Dokumentation beschrieben wird.

Kläre aber vorher ab, ob der Webspace, auf den Du Deine Seiten zu legen gedenkst, auch die von Dir zu wählende Technologie unterstützt. (Perl findet man bei Billig-Anbietern wesentlich seltener als PHP, noch seltener JSP ...).

cu,
Andreas

[frankx]

Hellihello wucher wichtel,

Hmm... Frames sind nicht so toll. Genaugenommen sogar ziemlich schlecht.

"Durch den Einsatz von Frames wachsen die Gestaltungsmöglichkeiten außerordentlich. Frames stellen an das Design von HTML-Seiten aber auch besonders hohe Ansprüche und haben einige nicht zu bestreitende Nachteile. Einige Tips, die Sie beachten sollten, finden Sie im Abschnitt Seite Frames als Mittel für Seiten-Layouts."

(http://de.selfhtml.org/html/frames/definieren.htm)).

Dank und Gruß,

frankx

[wucher wichtel]

Hallo!

Hmm... Frames sind nicht so toll. Genaugenommen sogar ziemlich schlecht.

"Durch den Einsatz von Frames wachsen die Gestaltungsmöglichkeiten außerordentlich. Frames stellen an das Design von HTML-Seiten aber auch besonders hohe Ansprüche und haben einige nicht zu bestreitende Nachteile. Einige Tips, die Sie beachten sollten, finden Sie im Abschnitt Seite Frames als Mittel für Seiten-Layouts."

Ähm, was willst du mir damit sagen? :) Dass in SELFHTML etwas anderes steht? Dass Frames doch nicht so schlecht sind?

ciao, ww

[frankx]

Hellihello wichtel,

Ähm, was willst du mir damit sagen? :) Dass in SELFHTML etwas anderes steht? Dass Frames doch nicht so schlecht sind?

Nun, dass in SELFHTML etwas anderes steht ist doch mal ein Ansatz. Kann doch jeder sich self eine Ansicht bilden.

Ansonsten würde ich aus prinzipiellen Gründen soweit gehen zu meinen, dass streng genommen der Satz "Frames sind schlecht/gut" mir sinnfrei erscheint. Um nur kurz anzureissen, was ich meine, käme der Satz "Frames sind für diesen oder jenen Zweck diese und/oder jene Nachteile/Vorteile" einer sinnhafteren Aussage meiner Meinung nach näher (s.a. Zitat). Ich kann aber auch damit leben, dass jemand Frames ganz allgemein "schlecht" findet und auch damit, dass es dazu unterschiedliche Ansichten gibt.

Gruß,

frankx

[wucher wichtel]

Hallo!

Nun, dass in SELFHTML etwas anderes steht ist doch mal ein Ansatz. Kann doch jeder sich self eine Ansicht bilden.

Wie aktuell ist diese Meinung, die da von SELFHTML vertreten wird? Haben die Devs diese erst neulich so geschrieben bzw. überarbeitet, oder ist dieser Abschnitt noch älter?

Ansonsten würde ich aus prinzipiellen Gründen soweit gehen zu meinen, dass streng genommen der Satz "Frames sind schlecht/gut" mir sinnfrei erscheint.

Generell erscheinen mir Aussagen, die verallgemeinern auch sinnfrei.

Um nur kurz anzureissen, was ich meine, käme der Satz "Frames sind für diesen oder jenen Zweck diese und/oder jene Nachteile/Vorteile" einer sinnhafteren Aussage meiner Meinung nach näher (s.a. Zitat).

Kannst du mir Vorteile von Frames nennen, die nicht mit anderen Techniken, ohne die Nachteile von Frames, erreicht werden können?

Ich kann aber auch damit leben, dass jemand Frames ganz allgemein "schlecht" findet und auch damit, dass es dazu unterschiedliche Ansichten gibt.

Bei Frames verallgemeinere ich. Auch wenn ich normalerweise versuche das zu umgehen. Aber ich kenne wirklich keine Vorteile von Frames. Wenn es welche gibt, dann wäre es wirklich cool, wenn ich die erfahren würde. Dann könnte ich meine Meinung überdenken.

ciao, ww

[frankx]

Hellihello wichtel,

Bei Frames verallgemeinere ich. Auch wenn ich normalerweise versuche das zu umgehen. Aber ich kenne wirklich keine Vorteile von Frames. Wenn es welche gibt, dann wäre es wirklich cool, wenn ich die erfahren würde. Dann könnte ich meine Meinung überdenken.

mmh:

"25.01.2005 - Neuer Feature-Artikel: Übergroße Tabellen in koordiniert scrollenden Frames

E-Mail Gernot Back hat einen neuen Feature-Artikel Seite Übergroße Tabellen in koordiniert scrollenden Frames geschrieben. Dort beschreibt er, wie man eine sehr große Tabelle mit Hilfe von Frames und JavaScript für die Bildschirmdarstellung so aufbereitet, dass der Benutzer den Überblick behält. Die Lösung ist so ausgelegt, dass Besucher mit deaktiviertem JavaScript sowie Suchmaschinen schlicht die gesamte Tabelle ohne Frames zu Gesicht bekommen. Somit bleibt die Seite benutzbar, auch wenn JavaScript deaktiviert ist." (http://aktuell.de.selfhtml.org/archiv/news/newsticker_2005.htm#news_1106648160)

Ansonsten war mir so, als wäre bei der Ankündigung der letzten Version ausdrücklich angemerkt gewesen, dass das Kapitel über Frames bearbeitet wurde. Das Argument, der Frameartikel sei veraltet, gabs vorher nämlich auch schon.

Ansonsten ist von meiner Seite unter http://forum.de.selfhtml.org/archiv/2005/12/t120529/#m774156 und http://forum.de.selfhtml.org/archiv/2005/10/t117305/#bottom und findichnichtmehr einiges gesagt. Da gabs mal eine Diskussion mit Ingo. Vielleicht nicht archiviert, ich find sie grad nciht. Ich versuchte den Punkt zu machen, dass eine Navigation aus (puristisch- ?) semantischen Gründen eigentlich keinen Platz auf einer (super- ?)korrekt strukturierten Seite hätte.

  
<h1>Nahrung</h1>  
 <p>Wat essen denn nun Pferde</p>  
 <h2>Sommer</h2>  
   <p>Sie essen Gras.</p>  
 <h2>Winter</h2>  
   <p>Sie essen Heu</p>  

Vor h1 kommt nix, denn das ist ja die erste Überschrift über alles. Danach hat das Menü nix zu suchen, denn es hat nix mit der Nahrung der Pferde zu tun. Auch in einem Buch steht es auf einem "anderen Blatt". U.u. gibt es aufklappbare Inhaltsverzeichnisse, die bei Bedarf zur Seite hinzugefügt werden können. Eine Möglichkeit bietet hier das Frameset. Wenn die "border" nicht visuell versteckt wird ("border=0"), kann der User sogar durch schieben die Navi-Seite kleinschieben.

Dann kommen noch Überlegungen wie "nur eine andere Version des Inkludens", "was für Möglichkeiten habe ich", "was kann ich schon", "was für technische Möglichkeiten habe ich", "was kann ich sonst noch", "wieviel Zeit will ich investieren", "ist die Seite so klein, dass mich das Direktverlinkungsproblem nicht nervt" u.ä.. Die Gegenargumente überspitzt formuliert: "'der' User deiner Seite ist der Herr, du sein Sklave, mach alles perfekt für alle und sieh zu dass Du alles dafür lernst, was 'man' dafür braucht" kenne ich, kann das zT. auch nachvollziehen, muss ich aber wohl nicht teilen. Hierzu sei vielleicht auch mal auf Dirks Weblog-Eintrag verwiesen (http://aktuell.de.selfhtml.org/weblog/webpublikation-mensch-dienstleister). Faszinieren tut mich aber auch die weltanschauliche Intensität, die diese Diskussionen immer wieder haben können,könnten,konnten.

Dank und Gruß,

frankx

[wucher wichtel]

Hallo!

Cool dass du soviel dazu geschrieben hast :-)

"25.01.2005 - Neuer Feature-Artikel: Übergroße Tabellen in koordiniert scrollenden Frames

E-Mail Gernot Back hat einen neuen Feature-Artikel Seite Übergroße Tabellen in koordiniert scrollenden Frames geschrieben. [...]

Das ist scheinbar wirklich ein Einsatzgebiet, auf dem Frames von Vorteil sind.

Ansonsten war mir so, als wäre bei der Ankündigung der letzten Version ausdrücklich angemerkt gewesen, dass das Kapitel über Frames bearbeitet wurde. Das Argument, der Frameartikel sei veraltet, gabs vorher nämlich auch schon.

Mir war so, als ob er nicht überarbeitet worden wäre. Aber das ist nur eine undeutliche Erinnerung. Kann sehr gut sein, dass das nicht zutrifft.

Ich versuchte den Punkt zu machen, dass eine Navigation aus (puristisch- ?) semantischen Gründen eigentlich keinen Platz auf einer (super- ?)korrekt strukturierten Seite hätte. [...]

Ich verstehe was du meinst, aber ich denke nicht, dass man deswegen auf Frames zurück greifen sollte. Allerdings ist das warscheinlich Geschmackssache.

Dann kommen noch Überlegungen wie "nur eine andere Version des Inkludens", "was für Möglichkeiten habe ich", "was kann ich schon", "was für technische Möglichkeiten habe ich", "was kann ich sonst noch", "wieviel Zeit will ich investieren", "ist die Seite so klein, dass mich das Direktverlinkungsproblem nicht nervt" u.ä..

Es gibt schon Gründe, die für Frames sprechen (s.o.). Allerdings denke ich, dass die Nachteile überwiegen. Manche ignorieren die Nachteile. Aber ich würde aus den, im letzten Absatz genannten Gründen, keine Frames verwenden.

Die Gegenargumente überspitzt formuliert: "'der' User deiner Seite ist der Herr, du sein Sklave, mach alles perfekt für alle und sieh zu dass Du alles dafür lernst, was 'man' dafür braucht" kenne ich, kann das zT. auch nachvollziehen, muss ich aber wohl nicht teilen. Hierzu sei vielleicht auch mal auf Dirks Weblog-Eintrag verwiesen (http://aktuell.de.selfhtml.org/weblog/webpublikation-mensch-dienstleister).

Mich persönlich nerven Frames. Meistens verlasse ich die Seiten, die Frames einsetzen, frühzeitig. Allerdings mag das auch daran liegen, dass sehr viele, die Frames einsetzen, auch sonst keine guten Seiten machen. Was nicht heißen soll, dass jeder der Frames einsetzt, kein "schönes" HTML und keine guten Seiten machen kann.

Einem Anfänger, der gerade seine erste Seite mit Frames zusammenbaut, werde ich sagen, dass mMn Frames schlecht sind. Weil er höchstwarscheinlich Frames so einsetzt, dass sie durch bessere Sachen ersetzt werden können. Ob er das dann umsetzt, bleibt ihm überlassen. Es kommt sehr auf den Geschmack an. Was ich vorher nicht gewusst habe: Es gibt (wenn auch selten) Situationen, in denen Frames nützlich sind :)

Danke für die ausführliche Antwort ;-)

ciao, ww

[frankx]

Hellihello ww,

Einem Anfänger, der gerade seine erste Seite mit Frames zusammenbaut, werde ich sagen, dass mMn Frames schlecht sind. Weil er höchstwarscheinlich Frames so einsetzt, dass sie durch bessere Sachen ersetzt werden können. Ob er das dann umsetzt, bleibt ihm überlassen. Es kommt sehr auf den Geschmack an. Was ich vorher nicht gewusst habe: Es gibt (wenn auch selten) Situationen, in denen Frames nützlich sind :)

Danke für die ausführliche Antwort ;-)

So ein bisschen Meinungsaustausch in friedlichem Miteinander kann doch eine feine Sache sein (;-).

Guts Nächtle aus Berlin,

frankx

[wucher wichtel]

Hallo!

So ein bisschen Meinungsaustausch in friedlichem Miteinander kann doch eine feine Sache sein (;-).

ja :-)

Guts Nächtle aus Berlin,

Guts Nächtle hört sich weniger nach Berlin an :)

ciao, ww

[frankx]

Hellihello WW,

Guts Nächtle hört sich weniger nach Berlin an :)

Äh, ich vergaß: _Vorstadt_Berlin oder Randbezirk oder in dem Fall sogar der "grüne Bezirk". Hier hüppen neuerdings nachts sogar Füchse durch die Gärten, die Wildsäue sind am Waldrand schon immer aktiv gewesen.

Gruß,

frankx

[Orlando]

Nun, dass in SELFHTML etwas anderes steht ist doch mal ein Ansatz.

Was in SELFHTML steht ist beileibe nicht immer der Weisheit letzter Schluss, die Meinung der Redakteure oder gar eine unumstößliche Wahrheit. Vieles wurde einfach nur noch nicht überarbeitet.

Wie aktuell ist diese Meinung, die da von SELFHTML vertreten wird?

Versionen der Datei in HTML und neuerdings XML.

Kannst du mir Vorteile von Frames nennen, die nicht mit anderen Techniken, ohne die Nachteile von Frames, erreicht werden können?

Sie funktionieren clientseitig.

Aber ich kenne wirklich keine Vorteile von Frames. Wenn es welche gibt, dann wäre es wirklich cool, wenn ich die erfahren würde. Dann könnte ich meine Meinung überdenken.

Die http://de.selfhtml.org/navigation/sidebars/@title=SELFHTML-Sidebars sind vom Prinzip her Framesets.

Roland

[Timo "God's Boss" Reitz]

Kannst du mir Vorteile von Frames nennen, die nicht mit anderen Techniken, ohne die Nachteile von Frames, erreicht werden können?
Sie funktionieren clientseitig.

Was man so unter "funktionieren" versteht...

Aber ich kenne wirklich keine Vorteile von Frames. Wenn es welche gibt, dann wäre es wirklich cool, wenn ich die erfahren würde. Dann könnte ich meine Meinung überdenken.
Die http://de.selfhtml.org/navigation/sidebars/@title=SELFHTML-Sidebars sind vom Prinzip her Framesets.

Nein. Im Prinzip bastle ich mir dort eine Seitenleiste mit zusätzlichen Schaltflächen. Dass diese eine HTML-Seite ist, ist eher Zufall (andere Mechanismen wären problemlos denkbar).
HTML-Frames (um diese geht es hier) machen Folgendes: Sie zeigen mehrere HTML-Dokumente unter einer Adresse gleichzeitig an.

[Orlando]

Vorteile von Frames
Sie funktionieren clientseitig.
Was man so unter "funktionieren" versteht...

Unsachlich. Sie funktionieren clientseitig.

Sie decken ferner position:fixed, overflow:scroll und gleichzeitige Manipulation der Darstellungsgröße ab.

Die http://de.selfhtml.org/navigation/sidebars/@title=SELFHTML-Sidebars sind vom Prinzip her Framesets.
Nein.

Doch, absolut. Sie erweitern die Anzeige um einen statischen und anpassbaren Bereich, aus dem heraus navigiert wird.

Im Prinzip bastle ich mir dort eine Seitenleiste mit zusätzlichen Schaltflächen.

Es sind ganz normale Links mit einem angepassten target-Attribut.

Dass diese eine HTML-Seite ist, ist eher Zufall (andere Mechanismen wären problemlos denkbar).

Nein, das ist kein Zufall, da dies die einzige browserunabhängige Möglichkeit darstellt, Sidebars zu implementieren.

Roland

[Timo "God's Boss" Reitz]

Vorteile von Frames
Sie funktionieren clientseitig.
Was man so unter "funktionieren" versteht...
Unsachlich. Sie funktionieren clientseitig.
Sie decken ferner position:fixed, overflow:scroll und gleichzeitige Manipulation der Darstellungsgröße ab.

Also nichts, was man nicht auch so hinkriegen könnte, ohne die Nachteile (Uneindeutigkeit der URL-Seite-Zuordnung).

Die http://de.selfhtml.org/navigation/sidebars/@title=SELFHTML-Sidebars sind vom Prinzip her Framesets.
Nein.
Doch, absolut. Sie erweitern die Anzeige um einen statischen und anpassbaren Bereich, aus dem heraus navigiert wird.

Dann wäre meine Bookmarkleiste ja auch ein Frame. Und meine Leiste mit der Navigation (vor, zurück, etc.) auch. Du dehnst den Begriff über die hier gemeinte Bedeutung hinaus, um künstlich Vorteile zu erschaffen. Ursprünglich war die Rede von *HTML-Framesets*. Bei der Einbindung meiner Sidebar kommt kein <frame> oder <frameset> vor, also liegt auch kein Frameset vor. Dass abstrahiert ein ähnlicher Mechanismus verwendet wird, ist irrelevant.

Im Prinzip bastle ich mir dort eine Seitenleiste mit zusätzlichen Schaltflächen.
Es sind ganz normale Links mit einem angepassten target-Attribut.

Siehe oben - das sind meine Bookmarks auch. Und sogar die Vor- und Zurück-Buttons sind ja eigentlich nur Links, die stetig angepasst werden. Komisch, nicht?

Dass diese eine HTML-Seite ist, ist eher Zufall (andere Mechanismen wären problemlos denkbar).
Nein, das ist kein Zufall, da dies die einzige browserunabhängige Möglichkeit darstellt, Sidebars zu implementieren.

Auch das ist Zufall. Und hat nichts mit der eigentlichen Thematik zu tun.

[Orlando]

Vorteile von Frames
Sie funktionieren clientseitig.
Was man so unter "funktionieren" versteht...
Sie decken ferner position:fixed, overflow:scroll und gleichzeitige Manipulation der Darstellungsgröße ab.
Also nichts, was man nicht auch so hinkriegen könnte,

Ich warte gespannt auf einen Entwurf, wie du das hinkriegen willst. Findest du eine Lösung, die rein clientseitig funktioniert und alle oben angeführten Punkte abdeckt, stehen die Chancen auf eine Aufnahme in SELFHTML vermutlich ziemlich gut.

ohne die Nachteile

Die sind gemeinhin bekannt und nicht das Thema, da wucher wichtel explizit nach Vorteilen gefragt hatte. Nichts gegen ein „ja, aber“ solange das „ja“ nicht verloren geht.

Die http://de.selfhtml.org/navigation/sidebars/@title=SELFHTML-Sidebars sind vom Prinzip her Framesets.
Nein.
Doch, absolut. Sie erweitern die Anzeige um einen statischen und anpassbaren Bereich, aus dem heraus navigiert wird.
Dann wäre meine Bookmarkleiste ja auch ein Frame. Und meine Leiste mit der Navigation (vor, zurück, etc.) auch.

Erstellst du diese selbst? Browserübergreifend? Mit HTML? Wie?

Du dehnst den Begriff über die hier gemeinte Bedeutung hinaus, um künstlich Vorteile zu erschaffen.

Keineswegs. Sidebars sind wie Framesets in Browsern implementiert mit dem Unterschied, dass ein eigener Bereich für sie reserviert ist. Sie ließen sich problemlos in ein herkömmliches Frameset einbinden und würden ohne weitere Änderungen funktionieren. Installiere die SELFHTML-Sidebars und erkenne den Vorteil von Frames, wie ihn tausende Anfänger für sich nutzen. Oder nenne Alternativen.

Ursprünglich war die Rede von *HTML-Framesets*. Bei der Einbindung meiner Sidebar kommt kein <frame> oder <frameset> vor, also liegt auch kein Frameset vor. Dass abstrahiert ein ähnlicher Mechanismus verwendet wird, ist irrelevant.

Sidebars sind „vom Prinzip her Framesets“. Die Formulierung war durchaus beabsichtigt. Warum versteifst du dich so auf das frameset-Element, wenn es um die prinzipiellen Vorteile geht, die sowohl das Original als auch deren Abwandlung bieten? Ob Frameset oder Sidebar ist doch dabei völlig wurscht.

Im Prinzip bastle ich mir dort eine Seitenleiste mit zusätzlichen Schaltflächen.
Es sind ganz normale Links mit einem angepassten target-Attribut.
Siehe oben - das sind meine Bookmarks auch. Und sogar die Vor- und Zurück-Buttons sind ja eigentlich nur Links, die stetig angepasst werden. Komisch, nicht?

Und meine Mausgesten und Sprachbefehle sind also auch nur Links, oder wie? Welche HTML-Elemente nutzt du denn für deine Bookmarks und Browser-Buttons? Aber ja, das kommt mir jetzt auch komisch vor.

Dass diese eine HTML-Seite ist, ist eher Zufall
Nein, das ist kein Zufall, da dies die einzige browserunabhängige Möglichkeit darstellt, Sidebars zu implementieren.
Auch das ist Zufall.

Wow. Der große Plan der Chaostheorie führt sohin zu Quasistandards?

Und hat nichts mit der eigentlichen Thematik zu tun.

Du magst keine Frames, ich weiß. Wollen wir die Kategorie auf (MEINUNG) ändern, um deine weitere Argumentation nicht zu behindern? >;)

Roland

[Cybaer]

Hi,

Kannst du mir Vorteile von Frames nennen, die nicht mit anderen Techniken, ohne die Nachteile von Frames, erreicht werden können?
Sie funktionieren clientseitig.
Was man so unter "funktionieren" versteht...

Man sollte nicht von schlechten Beispielen ausgehen, die von Webautoren stammen, die sich mit Frames nicht/schlecht auskennen ...

... sonst könnte man *jede* Webtechnik als nicht funktionabel bezeichnen. >;->

Gruß, Cybaer

[frankx]

Hellihello orlando,

Die http://de.selfhtml.org/navigation/sidebars/@title=SELFHTML-Sidebars sind vom Prinzip her Framesets.

Cool das...;

Dank und Gruß,

frankx

[Cybaer]

Hi,

Meine Lösung ist bisher wenig elegant: Ich habe alle Verweise so definiert, dass sie nicht mehr auf Einzelseiten, sondern ihrerseits auf Framesets verweisen, in denen auch die Navi-Leist etc. wieder neu geladen wird. Problem: Dadurch geht m.E. ein möglicher Geschwindigkeitsvorteil von Frames, dass man nämlich das zentrale Frameset nur einmal laden und ansonsten immer nur eine Einzelseite neu lädt, verloren.

Das sind echt Peanuts. Wie Du es machst, ist es prinzipiell richtig, wenn man sich nicht anderweitig Probleme einhandeln möchte. Und außerdem werrden die Frame-Dateien ja gecacht - also nicht erneut übertragen.

Oder gibt es vielleicht noch einen besseren Weg???

Ja, mit PHP: Gar kein Frameset erstellen, sondern stattdessen es mit PHP tun. Dieses PHP sollte auch den Content-Datei auslesen, und den BODY in den NOFRAMES-Bereich des (virtuellen) Framesets setzen, damit die Seite komplett von SEs indiziert wird.

Gruß, Cybaer