nicht angemeldet
Alternative zu Frames?
Hi ihr alle!
Ich hab jetz schon oft gelesen, Frames seien "schlechter Stil"!
Kann mir mal einer erklären, warum - und was ich als Alternative dazu verwenden sollte!!
Wie soll ich sonst ein grafisches Menü einbinden, ohne es in jeder aufgerufenen Datei neu laden zu müssen?
Danke schonmal
CU, DU
-
Hallo Daniel,
ich denke nicht das Du dass so pauschalisieren kannst. Du wirst wohl um Frames oft kaum herumkommen. Dennoch lassen sich viele Layout-strukturen auch mit blinden Tabellen loesen.
Gruesse Christian
Hi ihr alle!
Ich hab jetz schon oft gelesen, Frames seien "schlechter Stil"!
Kann mir mal einer erklären, warum - und was ich als Alternative dazu verwenden sollte!!Wie soll ich sonst ein grafisches Menü einbinden, ohne es in jeder aufgerufenen Datei neu laden zu müssen?
Danke schonmal
CU, DU
-
Aber was ist denn nun das schlechte an Frames? Wo liegen die Probleme?
Und gibt es eine Möglichkeit, (jetz ohne Frames) in verschiedenen Dateien gleichbleibende Dinge (headline, Menü, etc) beizubehalten und nur das andere zu ändern (also das Menü, etc muss nicht neu geladen werden, nur der Inhalt der Seite wird geändert)
CU, DU
-
Hallo
Über PHP, ASP, (bin mir nicht 100% sicher)JSP und SSI!
Es gibt aber sicher noch mehrere Möglichkeiten
tschüss
-
Aber was ist denn nun das schlechte an Frames? Wo liegen die Probleme?
Frames haben ihre Berechtigung, absolut! Aber sie müssen von der Situation her passen. Wenn es nur darum geht, sich weniger Arbeit machen zu wollen, weil man nicht in alle Seiten die Navigation einfügen will (und auch alle Seiten ändern muß, weil sich die Navigation geändert hat), dann sind Frames sicher nicht unbedingt gerechtfertigt.
Das Problem ist: Ich würde die Nützlichkeit von Frames stark von der vorhandenen Nutzsituation abhängig machen, deshalb fällt die Antwort schwer, ob Frames gut oder schlecht sind.
Wenn ich im Internet recherchiere und eine gute Seite mit nützlichen Informationen finde, wie z.B. SelfHTML, dann möchte ich vielleicht nicht nur ein Bookmark auf die Startseite setzen (http://selfhtml.teamone.de), sondern vielleicht zwecks besserem Zugriff auch noch auf die Objektreferenz von Javascript, weil ich die häufig brauche (http://selfhtml.teamone.de/javascript/objekte/index.htm), und für die ganz harten Fälle hier im Forum brauche ich auch noch den Link zum ZweiFrames-Skript (http://selfhtml.teamone.de/javascript/beispiele/zweiframes.htm).
Hingegen ist es mir völlig gleichgültig, daß meine Online-Bank Frames verwendet: Ich muß ohnehin auf die Startseite, um mich einzuloggen, also fällt dieses Argument weg. Und da die Seiten dort auch ohne ZweiFrames-Skript funktionieren (ein Klick auf einen Menüpunkt bringt mir entweder den Kontostand im Hauptframe, oder lädt mir das Wertpapierhandelsmenü im Naviframe), ist es also absolut kein Bedienungsproblem. Und da alle Seiten auch einen Link zu einer Druckversion haben, die im Popupfenster geöffnet wird und frameslos ist (und weniger bunt, was meinem Schwarzweiß-Laserdrucker gefällt), kann ich auch das gut erledigen (wobei die monatlichen Kontoauszüge ohnehin als PDF kommen, also muß ich im Prinzip garnichts drucken).
Es hängt also vom Anwendungsfall ab. Man sollte wissen, welche Nachteile Frames haben, und welche Vorteile sie für die Entwicklung und Darstellung der Website bieten, und das gegeneinander abwägen.
Und gibt es eine Möglichkeit, (jetz ohne Frames) in verschiedenen Dateien gleichbleibende Dinge (headline, Menü, etc) beizubehalten und nur das andere zu ändern (also das Menü, etc muss nicht neu geladen werden, nur der Inhalt der Seite wird geändert)
-
Du kannst das immer gleiche Navigationsmenü per Hand in jede einzelne HTML-Datei eintragen. Änderungen sind in jeder Datei einzeln durchzuführen (aber kopieren funktioniert natürlich auch, wenn sonst keine Anpassungen notwendig sind).
-
Du kannst einen Editor beauftragen, diese Aktualisierung automatisch durchzuführen. Du bearbeitest also "die Navi-Datei", welche sich in ihrer Form an eine bestimmte Stelle in den Seiten einfügen läßt (das ist dann keine komplette HTML-Datei mehr, wie sie im Frameset benötigt würde), und läßt den Editor alle Dateien aktualisieren. Phase 5 (http://www.meybohm.de) leistet sowas mit den "Include-Dateien".
-
Du benutzt SSI (Server Side Includes). Damit kannst du das Zusammenfügen der HTML-Fragmente zu einer kompletten Datei auf dem Server erledigen lassen und mußt nur noch die geänderte Navi-Datei hochladen, nicht mehr alle HTML-Dateien (wie in 1) und 2) notwendig). Nachteil: SSI ist eine Sonderfunktion des Servers, und nicht jeder Webspace hat diese Möglichkeit.
-
Du benutzt eine serverseitige Programmiersprache wie ASP, PHP, JSP etc, um die Navigation dynamisch in die Seiten zu integrieren. Das kann vom schlichten Zusammensetzen einer festen Datei (genau wie bei SSI) bis hin zum programmierten Einfügen gehen, bei dem die aktive Seite automatisch hervorgehoben wird. Diese serverseitigen Sprachen sind aber genau wie SSI eine Sonderfunktion, die nicht bei jedem Webspace dabei ist.
Was allen vier Lösungen gleich ist: Du erzeugst in allen Fällen eine HTML-Datei, welche in irgendeiner Weise Platz für den Inhalt und die Navigation hat - du mußt dich nur entscheiden, wie das aussehen soll, und dann aus einer Vorlage die passenden Einzelteile schneiden und im Live-Betrieb wieder korrekt zusammensetzen.
Ob du nun Tabellen oder Layer nimmst, ist erstmal egal. Layer bieten allerdings in Verbindung mit Stylesheets die Möglichkeit, durch die CSS-Anweisung position:fixed eine dauerhafte, feste Position auf dem Bildschirm einzunehmen und dadurch, genau wie bei Frames, immer sichtbar zu sein. Der IE kann das leider noch nicht, da scrollt der Layer mit. Und Mozilla hat derzeit wohl noch ein paar Geschwindigkeitsprobleme, wenn bewegter und fester Inhalt überlappt (was aber kein Hinderungsgrund sein sollte).
- Sven Rautenberg
-
Moin Sven!
Also, ich antworte Dir mal stellvertretend als Frage ins Forum, weil dein Post wunderbar zu meiner Frage past. Ja, es geht um Frames, und es sprechen viele immer wieder davon, dass es bei Frames "irgendwelche" Vorteile gibt, die imho aber immer etwas metaphorisch rumschweben, ohne mir wirklich ein konkretes Beispiel zu geben, wozu man ueberhaupt zu irgendeinem besonderen Zweck Frames benutzen sollte. Ich habe jedenfalls noch keine Seite gesehen, wo ich aufgeschreckt bin und mir gesagt habe "hey, _das_ ist sinnvolle anwendung von Frames - das waere anders viel schwieriger/unschoener/kompliverzwickter/wasauchimmer gewesen". Deshalb meine Frage, wo es ein solches Beispiel gibt - Ich kann es beim besten Willen nicht finden ;-)
Viele Gruesse,
Einbecker
-
Hi!
Jetz mal angenommen ich möchte keine Serverseitige Lösung (PHP, SSI, ...), aus welchen Gründen auch immer (Vielleicht weils mir für meine erste Seite einfach zuviel ist und ich das ganze auch offline bestauen können will ;) ...)
Ich hab mir jetz überlegt, eine "Hauptseite" zu machen, in der Headline, Menü, etc... drin ist und die verschiedenen Inhalte (also verschiedne HTML-Seiten) in einen <div>-Bereich reinlade.
Jetz aber die Frage: Was nehm ich da am besten? Mir schwante da so <object> als Lösung vor??
CU, DU
-
Moin!
Ich hab mir jetz überlegt, eine "Hauptseite" zu machen, in der Headline, Menü, etc... drin ist und die verschiedenen Inhalte (also verschiedne HTML-Seiten) in einen <div>-Bereich reinlade.
Jetz aber die Frage: Was nehm ich da am besten? Mir schwante da so <object> als Lösung vor??
Wie gesagt: Entweder Handarbeit (alles manuell einfügen), die Include-Lösung von Phase 5 (da mußt du dann aber Headline, Menü etc. in die Inhaltsdatei einfügen), und vielleicht geht auch <object>. Ganz sicher geht auch <iframe>. Das ist aber IMHO nichts, was Frames umgeht, sondern sowohl IFrames als auch objekte haben immer eine gewisse Größe, welche eben gerade nicht unbedingt dynamisch ist.
Das Einbinden von Content mittels <object> habe ich noch nicht probiert, würde es aber einerseits für Overkill halten, andererseits (wie gesagt: Ohne es genauer zu kennen) sehr kritisch sehen, weil es von Netscape 4 z.B. noch nicht verstanden wird (IIRC).
- Sven Rautenberg
-
hi
Das Einbinden von Content mittels <object> habe ich noch nicht probiert, würde es aber einerseits für Overkill halten, andererseits (wie gesagt: Ohne es genauer zu kennen) sehr kritisch sehen, weil es von Netscape 4 z.B. noch nicht verstanden wird (IIRC).
damit machen sich <iframe>s bei mir richtig beliebt. Im inneren kann man jersuchen das ganze zusätzlich mit <ilayer> o.ä. einzubauen. <object> ist dann die Harte Tour: da semmelt nn4 gerne mal ab...
gruss Kai
-
-
-
-
-
-
hi
für Frames sprechen 2 Argumente:
1. man kann bestimmte Elemente fest auf die Seite setzen.
Das geht in allen aktuellen Browsern (außer IE...) aber auch einfacher, man kann ein Element irgendwo auf der Seite "festnageln".2. dynamisches Einbinden von Navigation u.ä.
Das kann man Server-Seitig lösen (mit SSi, PHP o.ä.) oder Client-Seitig mit <iframe>.. (das kann nu aber Bugscrap 4 nit)Argumente gegen Frames:
1. versuch mal eine Frame-Seite zu drucken... Meistens musst du ersteinmal irgendwie herausfinden, in welchem Frame denn nun die interessante Information steht.2. schonmal über JS von einem Frame auf einen anderen zugegriffen? Ähnlich nervig.
3. kennst du das "I got framed" Problem? Links auf andere Seiten öffnen sich per default im Aktuellen Frame...
4. eine Seite in einem Frame zu bookmarken ist schlicht unmöglich. Entweder man bookmarkt das Frameset, dann muss man sich jedesmal neu zur eigentlichen Information klicken, oder man bookmarkt die Seite selbst, hat dann aber keine Navigation.
ich persönlich mach es jetzt so, dass was fest sitzen soll über position:fixed an eine Stelle gesetzt wird. Der IE kriegt ein position:absolute, und der ram Scrollt wech - Pech.
Die Navigation wird über PHP eingebunden, ebenso andere Dinge, die immer da sind. Dazu habe ich ein aufklappbares Menü an einer Stelle, in dem ich mit über JS erzeugten iFrames arbeite (eine JS-lose Navigation gibt's daneben, nn4 und Opera-User merkt von nix, bei IE, Mozilla und konqueror kann man beides..)-
Hallo Kai,
- dynamisches Einbinden von Navigation u.ä.
Das kann man Server-Seitig lösen (mit SSi, PHP o.ä.)
Und passend zu diesem Thema ganz frisch auf dem Tisch:
http://aktuell.de.selfhtml.org/artikel/phpasp/php-frames/ von Patrick Canterino :-)viele Gruesse
Stefan Muenz-
He Stefan
- dynamisches Einbinden von Navigation u.ä.
Das kann man Server-Seitig lösen (mit SSi, PHP o.ä.)
Und passend zu diesem Thema ganz frisch auf dem Tisch:
http://aktuell.de.selfhtml.org/artikel/phpasp/php-frames/ von Patrick Canterino :-)Welchen Anspruch haben eigentlich die Feature-Artikel? Ich meine, was ist ihr Zweck? Die neueren lesen sich oft als einfache Praxisbeispiele für Anfänger. Nicht schlecht, aber etwas, äh, unausgegoren. Nicht böse sein. Bei dem hier wundere ich mich zum Beispiel sehr über die Aussage, eine Perl-Lösung mache nur mit SSI Sinn. Damit steht diese Behauptung doch gegen den Perl-Teil aus selfhtml. Damit kann man eine wenigstens genauso komfortable Lösung zusammenzimmern. Ich finde es schade, dass die Artikel so ein wildes Durcheinander sind.
Titziana
-
Hallo Titziana
Welchen Anspruch haben eigentlich die Feature-Artikel? Ich meine, was ist ihr Zweck? Die neueren lesen sich oft als einfache Praxisbeispiele für Anfänger. Nicht schlecht, aber etwas, äh, unausgegoren. Nicht böse sein.
Es ist durchaus gut, wie du das da formuliert hast!
Ich versuche es mal so zu erklaeren wie ich es sehe: SELFHTML ist eine vergleichsweise "starre" Angelegenheit. Es ist versionenorientiert, und wenn du dir die Download-Zahlen anguckst, wirst du vermutlich auch verstehen, dass es nur zu einem Mega-Chaos fuehren wuerde, wenn ich da alle Naslang irgendwas Neues reinbaue und Versionen von der Sorte 8.1.13 anbiete (dieses Phaenomen ist ja auch schon "vergeben" und unter dem Namen "Apache" bekannt ;.)
Der Selfaktuell-Raum nimmt anstelle dessen die Aufgabe wahr, Sachen anzubieten, die in dieser Form in SELFHTML nicht drin stehen, aber fuer Leute, die sich taeglich mit den entsprechenden Technologien auseinandersetzen, sehr wertvoll sein koennen.
Dabei gibt es verschiedene Ansaetze. Das Forum hier richtet sich mehr an kommunikative Leute, die gern diskutieren, die sich durch Austausch und Feedback weiterentwickeln. Aber es gibt nicht nur typische "Forumer". Im Forum verkehren taeglich ein paar hundert Leute, auf Selfaktuell sind es aber an die zehntausend pro Tag. Es ist also sozusagen nur eine Minderheit, die dieses Forum kennt und nutzt. Von den vielen anderen bekommt man hier halt nichts mit, eben weil sie hier nichts von sich geben. Trotzdem gibt es sie, diese schweigende Mehrheit, und auch sie sollen hier interessante Inhalte finden, die ueber die "Kerndokumentation" SELFHTML hinaus gehen.
Nun kann ich das nicht mehr alles selber machen. Stattdessen moechte ich den Traffic, der auf den Seiten hier herrscht, dafuer nutzen, um anderen Webworkern, die ueber viel Fachwissen verfuegen, eine Publikationsplattform zu bieten. Und das entscheidene redaktionelle Modell dafuer sind eben die Feature-Artikel.
Da sollen nun also ganz verschiedene Autoren publizieren, die ganz unterschiedliche Voraussetzungen, Spezialkenntnisse und natuerlich auch oft ihre Leser anders ansprechen, als ich es in SELFHTML tue. Klar versuchen wir (die Developer hier und ich), so gut wie es geht einen gewissen Qualitaetsmassstab einzuhalten und auch auf die SELF-Maxime, also die Energie des Verstehens, zu achten. Dennoch ist es halt so, dass die Feature-Artikel sehr individuell ausfallen, da es Individuen sind, die sie geschrieben haben. Manche sind flapsiger, manche abgehobener, manche einseitiger usw. als SELFHTML. Das alles ist halt nicht aus einem Guss. Ungeachtet dessen steckt aber in den Artikeln, die zusammengenommen mittlerweile selber fast einen 1000-Seiten-Buchschinken fuellen wuerden, unglaublich viel Spezialwissen, und es werden dort viele Tricks verraten, die hier im Forum jeden Tag wieder als Frage auftauchen.
Ich hoffe auch, den Bereich der Artikel noch weiter ausbauen zu koennen. Das haengt natuerlich immer davon ab, wie weit Leute bereit sind, sich selber mal an die Arbeit zu machen und solche Artikel zu schreiben.
Bei dem hier wundere ich mich zum Beispiel sehr über die Aussage, eine Perl-Lösung mache nur mit SSI Sinn. Damit steht diese Behauptung doch gegen den Perl-Teil aus selfhtml.
Ich weiss zwar nicht genau, was du jetzt damit meinst (embedded Perl?), aber der Artikel stellt es zweifellos so dar, als sei mit PHP alles viel einfacher. Das ist natuerlich relativ. Hier bei uns auf dem Server haben wir PHP als CGI-Service eingerichtet und nicht als Apache-Modul. Deswegen (weil die PHPs in CGI-Verzeichnissen liegen muessen) hatte ich z.B. heute meine liebe Not damit, die PHP-Beispiele des Artikels zum Laufen zu bringen, waehrend das Perl-Beispiel auf Anhieb lief (weil es von vorneherein als eingebundenes CGI-Script konzipiert ist). Das ist also immer relativ und server-abhaengig. Aber der Artikel steht ja auch in der Abteilung "PHP", und eigentlich muesste er Perl ueberhaupt nicht erwaehnen. Patrick hat Perl wohl deshalb erwaehnt in dem Artikel, weil er weiss, dass hier viele Perler verkehren, die etwas misstrauisch sind gegen Versuche, PHP immerzu als die Superduper-Loesung hinzustellen, mit der alles viel einfacher ist. Kann natuerlich sein, dass er sich gerade dadurch nun eine Kritik einhandelt, der er mit dem entsprechenden Abschnitt gerade zuvor kommen wollte. Aber so ist das wohl im Leben: man meint es gut, und erreicht das Gegenteil davon ;-)
Tja, bleibt nur noch zu sagen: wir haben hier einen Buchstaben, der groesser ist als alle anderen - naemlich das supergrosse "<I>". Es steht fuer "Initiativstrafe". Gemeint ist damit: wir warten jetzt alle auf einen tollen Perl-Artikel von Titziana, der zeigt, wie man Frame-Probleme loest, oder auch andere Probleme ;-)
viele Gruesse
Stefan Muenz-
Hallo
Nun kann ich das nicht mehr alles selber machen. Stattdessen moechte ich den Traffic, der auf den Seiten hier herrscht, dafuer nutzen, um anderen Webworkern, die ueber viel Fachwissen verfuegen, eine Publikationsplattform zu bieten. Und das entscheidene redaktionelle Modell dafuer sind eben die Feature-Artikel.
... und es werden dort viele Tricks verraten, die hier im Forum jeden Tag wieder als Frage auftauchen.
Dann kann man den Artikel-Bereich also mit der üblichen Tipps- und Tricks-Ecke einer Massenmarkt-PC-Zeitschrift vergleichen? Hm, so hatte ich es noch nicht gesehen. Danke für die Erläuterung.
Hier bei uns auf dem Server haben wir PHP als CGI-Service eingerichtet und nicht als Apache-Modul. Deswegen (weil die PHPs in CGI-Verzeichnissen liegen muessen ...
Sorry, das ist falsch.
Kann natuerlich sein, dass er sich gerade dadurch nun eine Kritik einhandelt, der er mit dem entsprechenden Abschnitt gerade zuvor kommen wollte. Aber so ist das wohl im Leben: man meint es gut, und erreicht das Gegenteil davon ;-)
Kleine Anregung: ein fachkundiges Lektorat/Co-Autor kann die Qualität enorm steigern.
Tja, bleibt nur noch zu sagen: wir haben hier einen Buchstaben, der groesser ist als alle anderen - naemlich das supergrosse "<I>". Es steht fuer "Initiativstrafe". Gemeint ist damit: wir warten jetzt alle auf einen tollen Perl-Artikel von Titziana, der zeigt, wie man Frame-Probleme loest, oder auch andere Probleme ;-)
Danke für das Angebot. Im Moment ist mein Interesse nicht groß genug. Vielleicht ein anderes Mal.
Titziana
-
- dynamisches Einbinden von Navigation u.ä.
-
Hallo Stefan
Und passend zu diesem Thema ganz frisch auf dem Tisch:
http://aktuell.de.selfhtml.org/artikel/phpasp/php-frames/ von Patrick Canterino :-)weiter unten bin ich darauf hingewiesen worden das in einem frameset im "noframe" Bereich ein "<body>" nichts zu suchen hat.
Das ist auch im feature zu framesets so dargestellt.
In welchem feature ist denn jetzt die korrekte Schreibweise dargestellt. Im alten oder im neuen? Oder ist es am Ende dann doch egal...Ist nicht so wichtig, interresiert mich aber dennoch, zum einen möchte ich das alles ja einigermaßen richtig hinbekommen, zum anderen scheint mir daß ich ohne den <body> keine Angaben mehr über die bgcolor machen kann......oder geht das dann auch anders?
grüße, hahe
-
Monne!
weiter unten bin ich darauf hingewiesen worden das in einem frameset im "noframe" Bereich ein "<body>" nichts zu suchen hat.
Das ist auch im feature zu framesets so dargestellt.
In welchem feature ist denn jetzt die korrekte Schreibweise dargestellt. Im alten oder im neuen? Oder ist es am Ende dann doch egal...Bist Du sicher, dass Du weisst, was das Wort Feature bedeutet? Ich weiss jedenfalls nicht, was Du meinst. Ich kann Dir aber sagen, dass so, wie Patrick Canterino es gemacht hat, richtig ist. (Nur der Text ist etwas sinnlos.) Genaugenommen darf ein <NOFRAMES> innerhalb des <FRAMESET> AUSSCHLIESSLCH genau ein <BODY> enthalten, nicht mehr und nicht weniger.
So long
-
Hallo Calocybe,
Bist Du sicher, dass Du weisst, was das Wort Feature bedeutet? Ich weiss jedenfalls nicht, was Du meinst. Ich kann Dir aber sagen, dass so, wie Patrick Canterino es gemacht hat, richtig ist. (Nur der Text ist etwas sinnlos.) Genaugenommen darf ein <NOFRAMES> innerhalb des <FRAMESET> AUSSCHLIESSLCH genau ein <BODY> enthalten, nicht mehr und nicht weniger.
Was ist an dem Text sinnlos?
Viele Grüße
Patrick Canterino
-
Moin!
Was ist an dem Text sinnlos?
Na glaubst Du nicht, dass ein Besucher, der diese Nachricht zu sehen bekommt, bereits weiss, dass sein Browser keine Frames kann bzw. die Anzeige derer abgeschaltet ist? Falls er es doch nicht weiss, dann wird er auch nicht wissen, was Frames ueberhauot sind, und dann ist diese Nachricht genauso sinnlos fuer ihn.
Nein, dieser Bereich hat den Sinn, dieselben Inhalte wie die Frames-Version in einer alternativen Darstellungsform anzubieten. Z.B. die Navigation, die sonst in einem Extra-Frame ist, an den Anfang der Seite zu setzen. Oder einen Site-Map anzubieten, von dem aus jede Seite zu erreichen ist.
So long
-
-
-
- dynamisches Einbinden von Navigation u.ä.
-
Dankeschön!
Nur hab ich null Plan von PHP... ich lad mir jetz grad mal SelfPHP runter, aber wenn das Serverseitig ist, dann kann ich die Seite nicht offline lesen, oder? Und ich kann ja dann auch nicht auf jedem Server PHP haben, muss ich mal da schauen wo iuich bin ;)
Das mit dem drucken wär bei mir kein Problem, *so wichtig* ist der Inhalt net...
- schonmal über JS von einem Frame auf einen anderen zugegriffen? Ähnlich nervig.
Ja, das kenn ich, einer der Gründe, warum ich frage...
- kennst du das "I got framed" Problem? Links auf andere Seiten öffnen sich per default im Aktuellen Frame...
Das ist doch kein Problem, kann man den Link ja entsprechernd schreiben!?
Das Bookmark-Problem ist echt übel! Das nervt mich auch immer wieder bei Framebasierten Seiten...
CU, DU
-
hi
Nur hab ich null Plan von PHP... ich lad mir jetz grad mal SelfPHP runter, aber wenn das Serverseitig ist, dann kann ich die Seite nicht offline lesen, oder? Und ich kann ja dann auch nicht auf jedem Server PHP haben, muss ich mal da schauen wo iuich bin ;)
naja.. Server, die kein SSI oder PHP anbieten sollte selten sein...
Das mit dem drucken wär bei mir kein Problem, *so wichtig* ist der Inhalt net...
wie man es sieht, alles, was die Bezeichnung "Inhalt" verdient, wird auch irgendjemand drucken wollen.
- kennst du das "I got framed" Problem? Links auf andere Seiten öffnen sich per default im Aktuellen Frame...
Das ist doch kein Problem, kann man den Link ja entsprechernd schreiben!?
es geht dabei eher dadrum, wenn man eben irgendwelche dubiosen Seiten hat, wo das nur schlampig gemacht wird, dann hat man oft bei externen Links ein Problem...
Das Bookmark-Problem ist echt übel! Das nervt mich auch immer wieder bei Framebasierten Seiten...
allerdings! Das ist wohl auch der grund, weshalb keine größere Seite Frames benutzt, oder es gibt eine Lösung wie in dem von Stefan genannten Feature-Artikel erwähnt. (bei Microsoft in Aktion zu sehen :)
gruss Kai
-