Frames vs. Iframes als Konstrukt

[dey]

Hallo,

zuerst einmal bin ich dank PHP seit Jahren in der Lage auf Frames zu verzichten (natürlich mit Ausnahmen).

Es gibt aber noch genug (Anfänger!?), die nicht wirklich dran vorbeikommen, weil Alternativen häufig kompliziert sind oder die Technik erst gar nicht zur Verfügung steht.

Wenn ich die Diskusionen richtig verfolgt habe geht es bei der Seitenerstelllung mit Frameset um 3 Probleme:

1. Suchmaschine

• die Suchmaschinen ignorieren die Seite weil die Startseite mit dem Frameset keine Inhalt halt
• das Frameset wird nicht weiter verfolgt
• da keine Links da sind kann keinem Index gefolgt werden

2. Bookmarking
direktes Bookmarking ist nicht möglich da

• der Unterseitenname zuerst mal nicht offensichtlich ist (steht nicht in der Adressleite
• die Unterseite möglicherweise ohne Frameset unvollständig ist

3. Barrierefreiheit
will ich jetzt mal weglassen, denn sehr viele Seiten ohne Frames sind es auch nicht

Wenn nun anstatt dem Frameset ein Iframe (oder mehrere) eingesetzt wird (speziell für die Navi) ändert das die Situation doch:

1. Suchmaschine

• die Startseite hat Inhalt und möglicherweise sogar einige Links
• wenn ich jetzt die navi.html zusätzlich zu src im iframe noch richtig (verstecjkt oder mit noframe) wird sie doch gefunden und kann indiziert werden?

2. Bookmarking

• keine Probleme

Bitte erlöst mich von diesem Unsinn, sonst emfehle ich noch was Falsches!

bydey

[Thomas Schenkeli]

Bitte erlöst mich von diesem Unsinn, sonst emfehle ich noch was Falsches!

Hört sich im ersten Augenblick wirklich nach einem Haufen Blödsinn an ...

Also ich hatte bei iFrames immer ein großes Problem mit der Größe: Bei der Erstellung des iFrames wusste ich oft noch nicht was für ein Inhalt genau rein kommen wird, bzw. der Inhalt konnte sich ja verändern. Ich musste aber schon beim Erstellen des iFrames sagen wie groß es genau sein sollte und es veränderte sich anschließend nicht mehr.

Vielleicht lässts sich das ja über 100%-Angaben regeln, aber ein Konstrukt von iFrames wo ein Teil eine fixe Größe hat (Logo, Navigation, ...) und ein Teil eine variable (Content) stell ich mir als sehr kompliziert und eventuell nur über javascript lösbar vor.

Und falls man einfach fixe Größe wählt und für eine Auflösung optimiert kann man eh gleich absolut positionierte DIVs nehmen.

lg
Thomas

PS.: Alle Angaben ohne Gewähr, hab noch nie probiert ein Layout über iFrames zu realisieren (und werde mich auch hüten, versuche gerade von Frames wegzukommen ;-)

bydey

[dey]

Hallo,

Bitte erlöst mich von diesem Unsinn, sonst emfehle ich noch was Falsches!

Hört sich im ersten Augenblick wirklich nach einem Haufen Blödsinn an ...

Hört hört!

Also ich hatte bei iFrames immer ein großes Problem mit der Größe: Bei der Erstellung des iFrames wusste ich oft noch nicht was für ein Inhalt genau rein kommen wird, bzw. der Inhalt konnte sich ja verändern. Ich musste aber schon beim Erstellen des iFrames sagen wie groß es genau sein sollte und es veränderte sich anschließend nicht mehr.

Das Problem hast du immer wenn du nicht sauber variable arbeitest.
Und ich dnke die Iframe-Dimensionen kannst du per externem CSS einstellen. Ergo 1 Änderung für alle Seiten

Vielleicht lässts sich das ja über 100%-Angaben regeln, aber ein Konstrukt von iFrames wo ein Teil eine fixe Größe hat (Logo, Navigation, ...) und ein Teil eine variable (Content) stell ich mir als sehr kompliziert und eventuell nur über javascript lösbar vor.

Das ist Standard!
Sehr viele Seiten habe fixe Dimensionen für Top logos und Navigation, während Inhalt aufgrund seiner Variabilität flexibel gehalten.

Und falls man einfach fixe Größe wählt und für eine Auflösung optimiert kann man eh gleich absolut positionierte DIVs nehmen.

Frames sind ja nicht nur wegen der Positionierung der Elemente gefragt sondern meist, so sehe ich es zumindest, wegen der vereinheitlichten Navigation.
Das ist auch meinPunkt hier.
Du redest über Punkt 3 den ich außen vor halten wollte. Tabellen- und Div-Layouter sind auch oft genug zu doof es ordentlich zu machen.

PS.: Alle Angaben ohne Gewähr, hab noch nie probiert ein Layout über iFrames zu realisieren (und werde mich auch hüten, versuche gerade von Frames wegzukommen ;-)

Und das ist gut so!. Dauert aber ganz schön lange (zumindest bei mir war es so)

bydey

[Schenkeli Thomas]

Hallo,

Bitte erlöst mich von diesem Unsinn, sonst emfehle ich noch was Falsches!

Hört sich im ersten Augenblick wirklich nach einem Haufen Blödsinn an ...
Hört hört!

War nicht negativ gemeint, sondern eher:"He, klingt im ersten Moment nach Blödsinn, aber vielleicht ist was dahinter"

Das Problem hast du immer wenn du nicht sauber variable arbeitest.
Und ich dnke die Iframe-Dimensionen kannst du per externem CSS einstellen. Ergo 1 Änderung für alle Seiten

Klar, ich kann unsauber arbeiten. Vor allem muss ich dann unsauber arbeiten, wenn ich Layouts die für den Print-Bereich gedacht sind auf den Bildschrim übertragen muss. So sachen wie "der Footer muss immer ganz unten kleben und sichtbar sein, egal ob ich ganz wenig oder ganz viel Inhalt habe" die aus dem Print-Bereich kommen machen das Layouten schwierig. Warum darf ein footer sich nicht mit verschieben?

Vielleicht lässts sich das ja über 100%-Angaben regeln, aber ein Konstrukt von iFrames wo ein Teil eine fixe Größe hat (Logo, Navigation, ...) und ein Teil eine variable (Content) stell ich mir als sehr kompliziert und eventuell nur über javascript lösbar vor.
Das ist Standard!
Sehr viele Seiten habe fixe Dimensionen für Top logos und Navigation, während Inhalt aufgrund seiner Variabilität flexibel gehalten.

Und genau da es Standard ist muss man sich über diese Art von Layout an meisten Gedanken machen, etwas, was CSS bisher versäumt hat (weil bei Nav und Content auch die gleiche Höhe wichtig ist)

Und falls man einfach fixe Größe wählt und für eine Auflösung optimiert kann man eh gleich absolut positionierte DIVs nehmen.
Frames sind ja nicht nur wegen der Positionierung der Elemente gefragt sondern meist, so sehe ich es zumindest, wegen der vereinheitlichten Navigation.

Absolut, in meinen Augen der einzige Grund der noch für Frames spricht, vor allem bei "Intranet-Seiten", also nix Internet sondern firmenintern, da sind mir dann auch Suchmaschinen und eingeschränkte Benutzergruppen egal (Es interessieren mich nur meine Mitarbeiter).

Du redest über Punkt 3 den ich außen vor halten wollte. Tabellen- und Div-Layouter sind auch oft genug zu doof es ordentlich zu machen.

Weil es gar nciht so simpel ist es gut zu machen. Als ich vor nicht langer Zeit mich zum ersten Mal ausgiebig mit CSS und DIVs beschäftigt habe, hat es mich gewundert wie wenig gut erklärte Beispiele es für diverse Standardlayouts gibt ... Da besteht in der COmmunity noch großer Aufholbedarf. Auch bei Self-Html, da werden Layoutbeispiele die heutzutage eigentlich DIV-Sache sein sollten noch mit Frames erklärt. Sollte eigentlich nicht sein.

PS.: Alle Angaben ohne Gewähr, hab noch nie probiert ein Layout über iFrames zu realisieren (und werde mich auch hüten, versuche gerade von Frames wegzukommen ;-)
Und das ist gut so!. Dauert aber ganz schön lange (zumindest bei mir war es so)

Irgendwie hatte ich es auch nicht vor ;-)

bydey

[dey]

Hallo,

War nicht negativ gemeint, sondern eher:"He, klingt im ersten Moment nach Blödsinn, aber vielleicht ist was dahinter"

War auch nur geflachst

Klar, ich kann unsauber arbeiten. Vor allem muss ich dann unsauber arbeiten, wenn ich Layouts die für den Print-Bereich gedacht sind auf den Bildschrim übertragen muss. So sachen wie "der Footer muss immer ganz unten kleben und sichtbar sein, egal ob ich ganz wenig oder ganz viel Inhalt habe" die aus dem Print-Bereich kommen machen das Layouten schwierig. Warum darf ein footer sich nicht mit verschieben?

Warum das unsauber sein soll hab ich jetzt nich verstanden!
Elemente (auc <iframe> darf als solches bezeichnet werden) per CSS zu layouten ist doch nicht unsauber.
Gerade die Umsetzung von Printlayout sollte doch über Frames leichter funktionieren. Printlayout = fix / Framelayout = fix

Und genau da es Standard ist muss man sich über diese Art von Layout an meisten Gedanken machen, etwas, was CSS bisher versäumt hat (weil bei Nav und Content auch die gleiche Höhe wichtig ist)

Da kann ich dir ja gar nicht mehr folgen! Daß Navi und Content irgendwie gleich hoch sein müssen ist eher eine proprietäre Meinung (obwohl es bei mir auch häufig vorkommt, weil es mir gefällt

Weil es gar nciht so simpel ist es gut zu machen. Als ich vor nicht langer Zeit mich zum ersten Mal ausgiebig mit CSS und DIVs beschäftigt habe, hat es mich gewundert wie wenig gut erklärte Beispiele es für diverse Standardlayouts gibt ... Da besteht in der COmmunity noch großer Aufholbedarf. Auch bei Self-Html, da werden Layoutbeispiele die heutzutage eigentlich DIV-Sache sein sollten noch mit Frames erklärt. Sollte eigentlich nicht sein.

Da muß ich dir recht geben. Es ist schwer Frame oder Tabellenlayout mit Divs/CSS zu ersetzen. Aber das sollst du ja nicht! Ist nämlich was anderes.
Du mußt in  anderen Layout-Dimensionen denken -> Barrierefrei
Und das vermitteln sie hier schlecht.

Irgendwie hatte ich es auch nicht vor ;-)

Was?

bydey

[Thomas Schenkeli]

Warum das unsauber sein soll hab ich jetzt nich verstanden!
Elemente (auc <iframe> darf als solches bezeichnet werden) per CSS zu layouten ist doch nicht unsauber.
Gerade die Umsetzung von Printlayout sollte doch über Frames leichter funktionieren. Printlayout = fix / Framelayout = fix

Ich empfinde eher iFrame als "unsauber", wenn möglich sollte es verhindert werden. Ich hab iFrame bisher immer verwendet um Teile einer Seite aktualisieren zu können, ohne alles andere Aktualisieren zu müssen. Jetzt mach ich sowas lieber über AJAX, da muss man nur austauschen was man wirklich verändern will, und nicht das ganze iFrame.

Da kann ich dir ja gar nicht mehr folgen! Daß Navi und Content irgendwie gleich hoch sein müssen ist eher eine proprietäre Meinung (obwohl es bei mir auch häufig vorkommt, weil es mir gefällt

Ja, aber es gefällt sehr vielen Leuten weshalb es sehr schade ist, dass es bei der Planung von CSS nicht befolt wurde. Erweckt irgendwie den Anschein als ob CSS nicht gemacht wurde um die Anforderungen der "Community" abzudecken sondern um die Anforderungen dieser zu definieren.

Da muß ich dir recht geben. Es ist schwer Frame oder Tabellenlayout mit Divs/CSS zu ersetzen. Aber das sollst du ja nicht! Ist nämlich was anderes.

Auf der einen Seite sind Layouts die ganz klar mit DIVs umzusetzen sind und auf der anderen Seite Layouts die eindeutig mit Frames umzusetzen sind und manche Exoten sprechen eindeutig für Tabellen. Aber die Grenze dazwischen verschiebt sich immer mehr von DIVs weg hin zu Frames und Tabellen. Und wo genau diese Grenze zu ziehen ist habe ich noch nirgends mit Hand und Fuss erklärt gesehen. Würde mich nämlich auch interessieren. Vielleicht soetwas wie "http://www.wikimatrix.org/" aber eben für Layouts ;-)

Irgendwie hatte ich es auch nicht vor ;-)
Was?

Layouts auf iFrame-Basis

bydey

bye

[Ingo Turski]

Hi,

1. Suchmaschine

• die Suchmaschinen ignorieren die Seite weil die Startseite mit dem Frameset keine Inhalt halt

Das stimmt so nicht (mehr). Die Framesetseite kann Inhalt in noframes haben, der auch gelesen wird.

• das Frameset wird nicht weiter verfolgt

Suchmaschinen folgen durchaus den Frames - allerdings mit dem Nachteil, dass auf der Framesetseite nur ein einziger Verweis zu einer Inhaltsseite ist und die übrigen Seiten erst eine Ebene tiefer verlinkt sind. Das ist zwar kein Hinderungsgrund, verzögert/verschlechtert die Indizierung jedoch.

• da keine Links da sind kann keinem Index gefolgt werden

Auch Frame-Definitionen sind Verweise, denen gefolgt werden kann und wird.

2. Bookmarking
   direktes Bookmarking ist nicht möglich da

• der Unterseitenname zuerst mal nicht offensichtlich ist (steht nicht in der Adressleite
• die Unterseite möglicherweise ohne Frameset unvollständig ist

Möglich schon - nur halt sehr umständlich. Und gegen das zweite Problem kann eine kleine Javascriptroutine zumindest bei einem Großteil der Besucher helfen.

Dennoch soll das jetzt kein Plädoyer für Frames sein! ;-)

• wenn ich jetzt die navi.html zusätzlich zu src im iframe noch richtig (verstecjkt oder mit noframe) wird sie doch gefunden und kann indiziert werden?

Aber mit derselben Einschränkung w.o.

2. Bookmarking

• keine Probleme

nur wenn Du die Navigation in iframe setzt, so dass die Hauptseite i.d.R. (über Suchmaschinen) aufgesucht wird.

Das größte Problem von iframes hat aber Thomas angeführt.
Für eine Navigation ist meist eine Breitenangabe in em sinnvoll und 100%-xem gibt's nicht. Frames dagegen kennen "*".

freundliche Grüße
Ingo

[dey]

Hallo,

Das größte Problem von iframes hat aber Thomas angeführt.
Für eine Navigation ist meist eine Breitenangabe in em sinnvoll und 100%-xem gibt's nicht. Frames dagegen kennen "*".

Wie sieht es mit folgendem Konstrukt aus?

  
<div style="width:15em;heigth:100%">  
<iframe src.... style="width:100%">  
</div>  

bydey

[Ingo Turski]

Hi,

Wie sieht es mit folgendem Konstrukt aus?

<div style="width:15em;heigth:100%">
<iframe src.... style="width:100%">
</div>

stimmt auch wieder... wobei sogar das div unnötig ist und dem iframe width und float zugewiesen werden könnte.  
  
freundliche Grüße  
Ingo

-- 
[[barrierefreie Ingo Webdesign](http://www.1ngo.de/web/) » [Suchmaschinenoptimierung](http://www.1ngo.de/web/seo.html) | [em?](http://www.1ngo.de/web/em.html) | [IE7 - Bugs](http://www.1ngo.de/web/ie7.html)]

[Cheatah]

Hi,

Wenn ich die Diskusionen richtig verfolgt habe geht es bei der Seitenerstelllung mit Frameset um 3 Probleme:

es geht bei Frames ebenso um 3 Probleme, wie es beim IE 6 um 17 Bugs ging[1]. Es sind lediglich die _auffälligsten_ Probleme, also die, auf die man am ehesten stößt. Wenn Du im Archiv nach Frames suchst (oft im Zusammenhang mit JavaScript), wirst Du aber auf eine gigantische Masse diverser Zusatzprobleme treffen, von denen _jeder_, der Frames einsetzt, früher oder später einige haben wird - aber immer jeweils andere.

1. Suchmaschine

Ergänze diesen Punkt um das, was Du beim Bookmarking geschrieben hast.

Wenn nun anstatt dem Frameset ein Iframe (oder mehrere) eingesetzt wird (speziell für die Navi) ändert das die Situation doch:

Nein. Insbesondere das, was bei Bookmarking und (inzwischen ;-)) bei Suchmaschinen steht, ist unverändert.

Bitte erlöst mich von diesem Unsinn, sonst emfehle ich noch was Falsches!

Frames sind und bleiben Frames, auch wenn man sie einbettet.

Cheatah

[1] Das IE-7-Entwicklerteam hat AFAIK die dort genannten Bugs (mit Referenz auf die Liste) behoben. Wer nun glaubt, der IE 7 hätte somit eine nutzbringende CSS-Unterstützung, darf sich auf eine Überraschung "freuen".