Frame mit bestimmten Seiten öffnen

[Simon Lammerding]

Hallo,

ich möchte einen Link erstellen, der in einem neuen Fenster ein Frameset öffnet und dabei angeben, welche Seiten in welchem Frame zu laden sind. Ist so etwas möglich und, wenn ja, wie?
Viele Grüße

Simon

[WauWau]

Hallo Simon,

ich möchte einen Link erstellen, der in einem neuen Fenster ein Frameset öffnet und dabei angeben, welche Seiten in welchem Frame zu laden sind. Ist so etwas möglich und, wenn ja, wie?

ja, das ist auf ganz unterschiedliche art und weise(n) möglich. Zum einen mal wunderbar Klientseitig. Da gibt es zum einen http://selfhtml.teamone.de/javascript/objekte/location.htm#search, mit dem deine Frameseite beispielsweise per Query-String übermittelte Variablen bekommen könnte (Beispiel: Dein Link ruft "frameseite.htm?oben=seite2.htm&unten=seite2htm" auf. Ein script in der Frameseite schneidet von seinem document.location.search das erste zeichen ("?") weg, dann zerteilt es den string anhand von "&", und jedes Arrayelement anhand von "=". Oder der gesamte string wird mit einem regulären ausdruck auseinander genommen. Die einzelnen Framelokationen können nun dynamisch gewählt werden.

Eine andere Klientseitige Lösungsmöglichkeit ist der Zugriff der Variablen Fensterübergreifend. So stellst du in dem Fenster mit dem Link ein paar Variablen bereit, auf die das andere Fenster mittels "opener" zugreift. Ist aber noch dümmer als die erste Variante, da hier die fenster beim laden des zweitfensters von einander abhängig sind und dass zweitfenster einen syntaxfehler melden würde, würdest du den opener bereits schließen und es möchte zugriff darauf finden. Aber dann könntest du wiederum ein try-catch-Gefüge zusammenbasteln, usw. pp.

Letztenendes scheitert alles klientseitige, wenn javascript "deaktiviert" ist. Dann hilft nur noch serverseitiges, wo die Lösung klar ist: Querystring. Ganz gemütlich geht das dann, und wie, das erklärt dir Patrick Canterin auf dieser Seite: http://aktuell.de.selfhtml.org/artikel/phpasp/php-frames/index.htm

Weiterführende Links im Selfraum:

- http://aktuell.de.selfhtml.org/artikel/javascript/dyn-frames/index.htm (und es geht doch klientseitig ;-)

ich hoffe, ich habe dir geholfen ;-),

WauWau

[Ingo Turski]

Hi,

ich möchte einen Link erstellen,

<a href="seite.html">

der in einem neuen Fenster

<a href="seite.html" target="_blank">

ein Frameset öffnet

das schreibst Du dann in die "seite.html" rein

und dabei angeben, welche Seiten in welchem Frame zu laden sind.

und diese Angaben gehören natürlich auch dort mit rein wie in jede Frameset-Datei.

Ist so etwas möglich und, wenn ja, wie?

wenn ich Dich jetzt nicht völlig falsch verstanden habe, sollte das doch wohl kein Problem sein.

freundliche Grüße
Ingo

[WauWau]

Hallo Ingo,

wenn ich Dich jetzt nicht völlig falsch verstanden habe, sollte das doch wohl kein Problem sein.

er will afaik dynamisch ein Frameset generieren, und nicht auf ein statisches Frameset verweisen. Siehe [pref:t=77711&m=448833].

WauWau

[Ingo Turski]

Hi,

er will afaik dynamisch ein Frameset generieren, und nicht auf ein statisches Frameset verweisen. Siehe [pref:t=77711&m=448833].

ich hatte Dein Posting vorher schon gelesen. Nur sehe ich weder aus der Frage ein Indiz dafür noch würde der Themenbereich HTML dies vermuten lassen.

Und einmal abgesehen von der Ausgangsfrage: Eine Navigation (besonders die einer ansonsten mit normalen HTML-Links ausgestatteten Frameseite) von JavaScript abhängig zu machen, ist denkbar ungünstig und ich finde, daß der berüchtigte "Zweiframes" Artikel in Selfhtml dringend überarbeitet werden sollte. Es spricht überhaupt _nichts_ dagegen, ein (oder ein paar) extra angepaßte(s) Frameset(s) zu konstruieren um mehrere Frames gleichzeitig auszutauschen. Dagegen hat diese Methode u.a. den positiven Nebeneffekt, daß man zumindest Links auf Unterseiten eines Framesets setzen kann.

freundliche Grüße
Ingo

[Simon Lammerding]

Hallo,

vielen Dank für die Antworten. So müsste ich es nun hinbekommen.

Simon

[WauWau]

Hallo Ingo,

er will afaik dynamisch ein Frameset generieren, und nicht auf ein statisches Frameset verweisen. Siehe [pref:t=77711&m=448833].
ich hatte Dein Posting vorher schon gelesen. Nur sehe ich weder aus der Frage ein Indiz dafür noch würde der Themenbereich HTML dies vermuten lassen.

hmm, ich habe es so aufgefasst, aber villeicht liegt es auch daran, dass ich eine möglichst flexibele lösung gesucht habe... [s.u.]

Und einmal abgesehen von der Ausgangsfrage: Eine Navigation (besonders die einer ansonsten mit normalen HTML-Links ausgestatteten Frameseite) von JavaScript abhängig zu machen, ist denkbar ungünstig

full ACK erst mal.... [habe ich aber auch in meinem posting andeutungsweise geschrieben]

und ich finde, daß der berüchtigte "Zweiframes" Artikel in Selfhtml dringend überarbeitet werden sollte.

Um es mal zuzugeben: Ich habe ihn nicht gelesen (nur kurz überflogen) und wollte eigentlich nur mein Posting in sich abrunden und ein paar weiterführende Links hinschreiben 8]

Es spricht überhaupt _nichts_ dagegen, ein (oder ein paar) extra angepaßte(s) Frameset(s) zu konstruieren um mehrere Frames gleichzeitig auszutauschen.

Hmm... mehr Traffic für den Autor (er muss mehr dateien hochladen), mehr arbeit für den Autor (wenn z.b. die URI der "navigationsleiste" in dem frameset sich ändert), usw. Erstens bin ich kein Fan (mehr) von Frames. Und dann kommt noch dazu, dass ich das x-malige speichern der ein-und-derselben datei überhaupt nicht mag, vielleicht liegt das daran, dass ich mit serverseitigen programmiersprachen so verwöhnt bin ;-) *g*

Dagegen hat diese Methode u.a. den positiven Nebeneffekt, daß man zumindest Links auf Unterseiten eines Framesets setzen kann.

Naja, Frames hin oder her, man kann sie schlichtweg vergessen (größtenteils).

WauWau

PS: Zum letzten Statement: Ivbm. intelligent eingesetzten Scripten und serverseitigen Technologien könnten sie im begrenzten Rahmen jedoch noch durchaus sinn machen. So habe ich beispielsweise bei einem größeren Projekt von mir eine hand voll seiten, die nicht in das Seitensystem (allein schon vom design) her rein passen bzw. sollen. Die haben dann z.B. einen Script verpasst bekommen (einfach eingebunden):

if(top == self) {
     top.location.replace("/librarys/extra/?title="+escape(document.title)+"&src="+escape(self.location.href+self.location.search));
   }

Und die PHP-Datei /librarys/extra/index.php, die letztenendes dahintersteckt, erstellt dynamisch ein Frameset mit dem <title>, der im Querystring übertragen wurde. Drinnen stecken 2 Frames, ein Homepagenavigationsframe (nur ein paar wichtige links, um evv. noch mal ins webangebot zurückzufinden bzw. erst hinzufinden) und rechts die im Querystring übertragene richtige seite.
Diese Benutzung von Frames finde ich überaus gut, da hierbei

a) Suchmaschinen die seite noch indexieren können
  b) JavaScript-nichtbenutzer trotzdem die seite in ihrer vollen fülle anzeigen lassen können
  c) Keine Navigationsprobleme in der History entstehen (...location.replace())
  d) Dem Benutzer nach lesen der Seite weiterführende Links zum Webangebot zur Verfügung stehen

WauWau

[Ingo Turski]

Hi,

Es spricht überhaupt _nichts_ dagegen, ein (oder ein paar) extra angepaßte(s) Frameset(s) zu konstruieren um mehrere Frames gleichzeitig auszutauschen.

Hmm... mehr Traffic für den Autor (er muss mehr dateien hochladen), mehr arbeit für den Autor (wenn z.b. die URI der "navigationsleiste" in dem frameset sich ändert), usw.

das trifft in den meisten Fällen aber garnicht zu. Die Regel ist doch, daß seitens der Navigation nur ein Frame mit neuem Inhalt versorgt werden muß und nur bei einem Bereichwechsel zusätzlich in einem zweiten Frame die Subnavigation.
Da es von diesen Bereichen meist nicht mal ein Dutzend gibt, hält sich der Aufwand dann in Grenzen. Dfür hat man jedoch die besagten Vorteile.

if(top == self) {

und was ist, wenn ich ohne JS auf diese Seite gehe? Ich sehe hier keinen Unterschied zu einer reinen JS-Lösung.

freundliche Grüße
Ingo

[WauWau]

Hallo Ingo,

Hmm... mehr Traffic für den Autor (er muss mehr dateien hochladen), mehr arbeit für den Autor (wenn z.b. die URI der "navigationsleiste" in dem frameset sich ändert), usw.
das trifft in den meisten Fällen aber garnicht zu. Die Regel ist doch, daß seitens der Navigation nur ein Frame mit neuem Inhalt versorgt werden muß und nur bei einem Bereichwechsel zusätzlich in einem zweiten Frame die Subnavigation.
Da es von diesen Bereichen meist nicht mal ein Dutzend gibt, hält sich der Aufwand dann in Grenzen. Dfür hat man jedoch die besagten Vorteile.

OK, man kann es letztenendes drehen, wie man will. Ist ja auch egal, ich nutze sowieso nicht Frames (in dieser Art und weise)...

if(top == self) {
und was ist, wenn ich ohne JS auf diese Seite gehe? Ich sehe hier keinen Unterschied zu einer reinen JS-Lösung.

Oh doch, denn im Frameset findet sich letztenendes kein javaSCript mehr. Was ist, wenn du ohne JS auf die Seite "gehst"? Nichts, es lädt sich kein Frameset und du kannst die Seite sehen, wie sie ist - nur ohne Frame auf der linken seite.

Hier ein Beispiel:

------- Start "egal.html" --------
<html>
<head>
  <title>Blabla.de :: Hintergründe zu Versionen</title>
  <script type="text/javascript" src="../extra/check.js"></script>
  <link rel="stylesheet" type="text/css" href="../css/extra.blue.css" title="Unabhängiges Blau-CSS" />
</head>
<body>
<h1>Hintergründe zu Versionen und Designs</h1>
<a name="1.1"><h2>Vorwort</h2></a>
<p>Langes Vorwort hier</p>
<a name="1.2"><h2>Inhalt</h2></a>
<ol>
        <li><a href="#top">Hintergründe zu Versionen und Designs</a>
        <ol>
                <li><a href="#1.1">Vorwort</a></li>
                ....
------- Ende "egal.html" --------

------- Start "check.js" --------
   if(top == self) {
     top.location.replace("/librarys/extra/?title="+escape(document.title)+"&src="+escape(self.location.href+self.location.search));
   }
------- Ende "check.js" --------

Was passiert hier? Ein x-beliebiges Dokument wird geladen. In seinem Header ein Script eingebunden. Der Script überprüft, ob die Seite in einem Frameset ist oder nicht. Ist sie es nicht, überschreibt sie den aktuellen History-eintrag (damit die History mittels back-button noch benutzbar ist) zu einem neuen, der auf ein serverseitiges Frameset verweist. Interpretiert der Browser __nicht__ JavaScript, passiert gar nichts und der User bekommt das Dokument zu sehen. Interpretiert er nun JavaScript passiert das gerade gesagte und der Browser bekommt ein in diesem fall von PHP generiertes Frameset, dass hier in diesem fall so aussehen wird:

---------- start "http://server.de/librarys/extra/?title=Blabla.de%20%3A%3A%20Hintergr%FCnde%20zu%20Versionen&src=http%3A//server.de/librarys/umstellung/longinfo.html" -----------
    <html>
    <head>
      <title>Blabla.de :: Hintergründe zu Versionen</title>
    </head>
      <frameset cols="115,*" frameborder="0">
         <frame src="/librarys/extra/index.php?content=frame&buttons=all" name="Infolinks" scrolling="no" />
         <frame src="http://server.de/librarys/umstellung/longinfo.html" name="mainframe" />
         <noframes>
           <h2>blabla.de :: Hintergründe zu Versionen</h2>
           <h1>Fehler: Dein Browser kann keine Frames anzeigen</h1>
           <p>Zu besseren Navigierungsmöglichkeiten wurden auf dieser Seite Frames eingesetzt. Diese kann dein Browser jedoch nicht darstellen. Daher hier die 2 Links zu den sonst angezeigten Frameinhalten:</p>
           - <a href="http://server.de/librarys/umstellung/longinfo.html">Hauptseite (http://server.de/librarys/umstellung/longinfo.html)</a>
           <br /> - <a href="/librarys/extra/index.php?content=frame&buttons=all">Informationslinks-Frame (/librarys/extra/index.php?content=frame&buttons=all)</a>
         </noframes>
      </frameset>
    </html>

---------- ende "http://server.de/librarys/extra/?title=Blabla.de%20%3A%3A%20Hintergr%FCnde%20zu%20Versionen&src=http%3A//server.de/librarys/umstellung/longinfo.html" -----------

So wunderbar, nicht wahr? Letztenendes bekommt der Benutzer hier ein Frameset, das 2 Frames hat: Einen kleinen "Informationslinks-Frame" und einen hauptframe, in dem sich das Dokument befindet, das er auch sehen würde, hätte er Javascript ausgeschaltet.

WauWau

[Ingo Turski]

Hi,

if(top == self) {
und was ist, wenn ich ohne JS auf diese Seite gehe? Ich sehe hier keinen Unterschied zu einer reinen JS-Lösung.

Oh doch, denn im Frameset findet sich letztenendes kein javaSCript mehr. Was ist, wenn du ohne JS auf die Seite "gehst"? Nichts, es lädt sich kein Frameset und du kannst die Seite sehen, wie sie ist - nur ohne Frame auf der linken seite.

das meinte ich doch. Ohne JS ist es aus Clientseite absolut kein Unterschied zu einer reinen JS-Lösung, so daß ich sarüber hinaus noch nicht einmal einen Vorteil darin sehe, den Server die Arbeit machen zu lassen, die der Client ebensogut schaffen kann.
Etwas ganz anderes wäre natürlich eine Lösung, die nur beim Server abläuft und ohne Clientunterstützung auskommt.

freundliche Grüße
Ingo

[WauWau]

Hallo Ingo,

Ohne JS ist es aus Clientseite absolut kein Unterschied zu einer reinen JS-Lösung, so daß ich sarüber hinaus noch nicht einmal einen Vorteil darin sehe, den Server die Arbeit machen zu lassen, die der Client ebensogut schaffen kann.

Im Vergleich zu Seiten, wo nichts läuft ohne JavaScript ist da ein ganz gehöriger Unterschied drin.

Etwas ganz anderes wäre natürlich eine Lösung, die nur beim Server abläuft und ohne Clientunterstützung auskommt.

Wie stellst du dir das vor? Ein CGI-Programm (PHP...) könnte natürlich schauen, welche URi der "Referer" ist und demnach ggf. handeln (also wenn die URI des Dokumentes der "Referer" ist, das Dokument ausgeben, ansonsten ein Frameset mit der URi des dokumentes). Aber man kann bei Browsern ganz gemütlich einstellen, eben nicht die URI des Refferers zu übermitteln, dann klappt es wieder nicht...

WauWau

[Ingo Turski]

Hi,

Im Vergleich zu Seiten, wo nichts läuft ohne JavaScript ist da ein ganz gehöriger Unterschied drin.

schon - aber eben nicht im Unterschied zu Deiner halben Serverlösung.

Wie stellst du dir das vor? Ein CGI-Programm (PHP...) könnte natürlich schauen, welche URi der "Referer" ist und demnach ggf. handeln (also wenn die URI des Dokumentes der "Referer" ist, das Dokument ausgeben, ansonsten ein Frameset mit der URi des dokumentes). Aber man kann bei Browsern ganz gemütlich einstellen, eben nicht die URI des Refferers zu übermitteln, dann klappt es wieder nicht...

stimmt - hat er dann halt Pech gehabt ;-) und bekommt dann vielleicht zumindest einen generierten Link auf das Frameset.
Ich könnte mir aber noch andere Möglichkeiten denken. Z.B. wenn eine neue IP eine Frameseite aufruft, stehen die Chancen sehr hoch, daß hier das Frameset fehlt; und wenn nicht, auch nicht schlimm, kommt's halt nochmal.

freundliche Grüße
Ingo

[WauWau]

Hallo Ingo,

Im Vergleich zu Seiten, wo nichts läuft ohne JavaScript ist da ein ganz gehöriger Unterschied drin.
schon - aber eben nicht im Unterschied zu Deiner halben Serverlösung.

Naja, ich wüsste nicht, was hierbei auszusetzen sei. Es funktioniert wunderbar, der Benutzer bekommt keine 2 Framesets oder andere misslungene Werke zu gesicht (s.u.) und alle sind zufrieden...

stimmt - hat er dann halt Pech gehabt ;-) und bekommt dann vielleicht zumindest einen generierten Link auf das Frameset.

wenn, dann würde ich ihm das dokument ausgeben, und dann wären wir wieder....bei denen, die JavaScript deaktiviert haben, also die Sorte Surfer, die den evv. notwendigen Standarts der Seite nicht stand halten können. Ist aber auch nicht schlimm, da sie ja nichts schlimmes verpassen. Also ich meine eher: Sie verpassen überhauptnichts außer ein hässlicher läppischer Navigationsframe, in dem ich sowieo wieder ein paar DHTML-Spielchen reingebaut habe (ich finde ein mittels CSS nachgebautes <option>-Feld für Verweise passt da einfach rein ;-)

Ich könnte mir aber noch andere Möglichkeiten denken. Z.B. wenn eine neue IP eine Frameseite aufruft, stehen die Chancen sehr hoch, daß hier das Frameset fehlt; und wenn nicht, auch nicht schlimm, kommt's halt nochmal.

Oh je, das ist imho eine besonders schlechte möglichkeit. erstens mal, weil das mit der Ip-Adresse immer ein gewurschtel ist... ich meine, wenn meine internetverbindung nach 1er minute inaktivität aufgelegt wird (wird sie bei mir erst nach 10, aber egal), und ich dann ein doppeltes frameset bekomme, nein danke. Doppelte framesets sind wohl schon ein arger fehler. zweitens müssen die IP-Adressen dann irgendwo extra serverseitig gespeichert werden, und das gesamte verfahren ist im Gegensatz zu der einfachen Javascript-lösung extrem aufwendig.

Also um es kurz zu fassen: Die IP-Lösung ist wahnsinnig fehleranfällig. Ich sitze beispielsweise hinter nem router. surft ein anderer in meinem lan auf der gleichen seite rum, dann bekommt er beispielsweise kein frameset, und ich habe schon eins....

WauWau

[Ingo Turski]

Hi,

Naja, ich wüsste nicht, was hierbei auszusetzen sei.

Du verstehst mich wohl falsch. Ich setze nichts aus, sondern sage nur, daß beide Lösungen völlig gleichwertig sind. Naja, fast, denn bei Deiner Methode hat der Server etwas mehr zu tun.

eine besonders schlechte möglichkeit. erstens mal, weil das mit der Ip-Adresse immer ein gewurschtel ist... ich meine, wenn meine internetverbindung nach 1er minute inaktivität aufgelegt wird (wird sie bei mir erst nach 10, aber egal), und ich dann ein doppeltes frameset bekomme,

Du kennst BASE HREF und TARGET="_TOP"?

zweitens müssen die IP-Adressen dann irgendwo extra serverseitig gespeichert werden, und das gesamte verfahren ist im Gegensatz zu der einfachen Javascript-lösung extrem aufwendig.

zugegeben. Dafür funktioniert es serverseitig. Mir ist besonders bei sehr großen Seiten _positiv_ aufgefallen, daß ich das Frameset ohne Javascript bekomme; ein Beispiel: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp.

Ich sitze beispielsweise hinter nem router. surft ein anderer in meinem lan auf der gleichen seite rum, dann bekommt er beispielsweise kein frameset, und ich habe schon eins....

Hihi. Pech gehabt, soll er sich bei Dir beschweren. ;-)

freundliche Grüße
Ingo

[WauWau]

Hallo Ingo,

Naja, ich wüsste nicht, was hierbei auszusetzen sei.
Du verstehst mich wohl falsch. Ich setze nichts aus, sondern sage nur, daß beide Lösungen völlig gleichwertig sind. Naja, fast, denn bei Deiner Methode hat der Server etwas mehr zu tun.

Also für mich ist die "andere" Methode, also nicht meine, über die wir hier reden, ein Link auf ein Frameset, in dem ein Script rumwuschelt, der das ganze macht..., was bedeuten würde, dass der Benutzer ohne JavaScript nichts, aber auch gar nichts sieht außer villeicht ein paar 404's und ähnlichem.

Du kennst BASE HREF und TARGET="_TOP"?

ach ja, und übrigens: Meine Seiten, denen ich so ein Zusatzframeset ermögliche, sind vom Grund auf ganz_normale_seiten ohne <base>-Tags oder anderen Verschnörlelungen wegen dem Frameset. Das heißt, würde man die Zeile
  <script type="text/javascript" src=".../ckeck.js"></script>
entfernen, würden sie wunderbar funktionieren, auch wenn man sie auf den kopf stellen und in sonst ein Verzeichnis verschleppen würde. Das einzige, was also evv. ein kleines Framechen an der linken seite ermöglicht, ist ein völlig unabhängiger kleiner externer script, alles, aber wirklich alles andere übernimmt der Server. Das bedeutet für den Klienten kein 5maliges Laden von Daten, wie es beispielswäre der Fall wäre, würde ein Script serverseitig unter einer Datei ggf. die Datei oder ein frameset oder sonstiges rausgeben, und sonstigem - letztenendes sieht er ein und die selbe datei. Also eine simple HTML-Datei, und sonst nix. Ich meine, ich will da keine großen anderen Kunststücke ans land legen und letztenendes meine Datei als Perl-Script speichern, nur damit der sonstwas erledigt, und der klient gar nix.

zweitens müssen die IP-Adressen dann irgendwo extra serverseitig gespeichert werden, und das gesamte verfahren ist im Gegensatz zu der einfachen Javascript-lösung extrem aufwendig.
zugegeben. Dafür funktioniert es serverseitig. Mir ist besonders bei sehr großen Seiten _positiv_ aufgefallen, daß ich das Frameset ohne Javascript bekomme; ein Beispiel: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp.

Ich bekomme bei deinem Ding da nur das folgende geliefert: http://msdn.microsoft.com/library/shared/deeptree/bot/bot.asp?dtcnfg=/library/deeptreeconfig.xml... Da wolltest du mich nicht hinverweisen, oder!?

Ich sitze beispielsweise hinter nem router. surft ein anderer in meinem lan auf der gleichen seite rum, dann bekommt er beispielsweise kein frameset, und ich habe schon eins....
Hihi. Pech gehabt, soll er sich bei Dir beschweren. ;-)

jo, ganz genau.

WauWau

[Ingo Turski]

Hi,

Das einzige, was also evv. ein kleines Framechen an der linken seite ermöglicht, ist ein völlig unabhängiger kleiner externer script, alles, aber wirklich alles andere übernimmt der Server.

Und genauso sieht es bei den Frameseiten, die ich leider noch nicht umgeschrieben habe, auch aus. Nur daß komplett alles in dem externen JS geregelt wird und das Ganze theoretisch auch offline funktionieren würde. "Theoretisch" deshalb, weil ich das Script für mich so geschrieben habe, daß es im lokalen Betrieb nichts macht.

ein Beispiel: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp.

Ich bekomme bei deinem Ding da nur das folgende geliefert: http://msdn.microsoft.com/library/shared/deeptree/bot/bot.asp?dtcnfg=/library/deeptreeconfig.xml... Da wolltest du mich nicht hinverweisen, oder!?

sorry, ich habe da aus Versehen die vom Server generierte Nachlade-URL gepostet. Scheint so, als wenn die bei aktiviertem Javascript nicht funktioniert?! ;-)

richtig wäre als URL der Unterseite des Framesets http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp (vielleicht klappt ja diesmal die Verlinkung?)

freundliche Grüße
Ingo

[WauWau]

Hallo Ingo,

Das einzige, was also evv. ein kleines Framechen an der linken seite ermöglicht, ist ein völlig unabhängiger kleiner externer script, alles, aber wirklich alles andere übernimmt der Server.
Und genauso sieht es bei den Frameseiten, die ich leider noch nicht umgeschrieben habe, auch aus. Nur daß komplett alles in dem externen JS geregelt wird und das Ganze theoretisch auch offline funktionieren würde. "Theoretisch" deshalb, weil ich das Script für mich so geschrieben habe, daß es im lokalen Betrieb nichts macht.

das letzte könnte ich meinem noch hinzufügen, eine sehr gute idee.

richtig wäre als URL der Unterseite des Framesets http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp (vielleicht klappt ja diesmal die Verlinkung?)

Und was ist damit? Ich bekomme mit dem Opera kein Frameset geladen, obwohl JavaScript "on" ist.

WauWau

[Ingo Turski]

Hi,

richtig wäre als URL der Unterseite des Framesets http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp (vielleicht klappt ja diesmal die Verlinkung?)

bin gerade mal mit Opera draufgegangen und habe festgestellt, daß hier noch nichmal das CSS funktioniert. Man sollte mit Opera wohl auch nicht auf MS Seiten gehen.;-)

Dieser Link sollte ein Beispiel für rein serverseitiges Nachladen des Framesets sein - alsp ohne JS - was auch im IE und Mozilla funktioniert.

freundliche Grüße
Ingo

[WauWau]

Hallo Ingo,

bin gerade mal mit Opera draufgegangen und habe festgestellt, daß hier noch nichmal das CSS funktioniert. Man sollte mit Opera wohl auch nicht auf MS Seiten gehen.;-)

Hmm, ein CSS bekomme ich aber schon geladen...

Dieser Link sollte ein Beispiel für rein serverseitiges Nachladen des Framesets sein - alsp ohne JS - was auch im IE und Mozilla funktioniert.

Komisch ist dann aber, dass es nicht unter Opera funktioniert, wenn doch alles rein serverseitig sein soll.

WauWau

[Ingo Turski]

Hi,

Komisch ist dann aber, dass es nicht unter Opera funktioniert, wenn doch alles rein serverseitig sein soll.

find' ich nicht unbedingt. Opera hatte sich doch schonmal arg über MS beschwert, daß Opera-Usern einige Seiteninhalte vorenthalten werden... Gerade weil die Sache serverseitig geschieht, kann MS prima die Operas gesondert behandeln.

freundliche Grüße
Ingo

[WauWau]

Hallo Ingo,

Komisch ist dann aber, dass es nicht unter Opera funktioniert, wenn doch alles rein serverseitig sein soll.
find' ich nicht unbedingt. Opera hatte sich doch schonmal arg über MS beschwert, daß Opera-Usern einige Seiteninhalte vorenthalten werden... Gerade weil die Sache serverseitig geschieht, kann MS prima die Operas gesondert behandeln.

ach so. Wusste nicht, dass MS versucht, Opera in auf diese Art und Weise in die Knie zu zwingen...

Nach dem motto: Benutzt unseren IE oder bekommt keine Updates für das scheißprogramm (windoofs), welches ihr ja benutzt. basta.

Soll der Bill doch verrecken mit seinem Windows-Scheiß. Strengenommen hat er bereits billiarden von aberbilliarden schaden auf dieser welt damit angerichtet. Man, würde alle welt intelligente produkte (es gibt ja ne ganze menge Linux-distributionen, dann noch Apples OS und wahnsinnig viel mehr brauchbares) benutzen, gäbs auch keine bööööösen viren, die milliardenschäden anrichten würden.

Kleine Frage: Wie alt ist Billy? [er könnte nämlich langsam mal verrecken, dann noch ein paar Attentate auf MS, und die Schei*firma geht den bach runter]

Sorry für meine Ausdrucksweise, aber MS ist echt das ____letzte____

WauWau