Die Frames-Frage...

[Markus]

Hallo!
Ich will in nächster Zeit meine Homepage überarbeiten. Nun stellt sich mir die "Frames-Frage"! Man liest immer, dass Frames nicht von allen Browsern dargestellt werden können bzw. nicht richtig. Aber ist die Aussage noch haltbar?

Mal abgesehen von den Textbrowsern (z.B. unter Linux) sollte es heute doch jedem Browser möglich sein Frames korrekt anzuzeigen oder?

Also kann man heute Frames ohne Bedenken verwenden oder nicht? Die wenigen Leute, die mit Textbrowsern die Seite besuchen, klammere ich mal aus, da das mit Sicherheit nicht mal 1% ist.

MfG

[MudGuard]

Hi,

Ich will in nächster Zeit meine Homepage überarbeiten. Nun stellt sich mir die "Frames-Frage"! Man liest immer, dass Frames nicht von allen Browsern dargestellt werden können bzw. nicht richtig. Aber ist die Aussage noch haltbar?
Mal abgesehen von den Textbrowsern (z.B. unter Linux) sollte es heute doch jedem Browser möglich sein Frames korrekt anzuzeigen oder?

Gegenfrage: welche Vorteile erhoffst Du Dir durch die Verwendung von Frames gegenüber framefreien Seiten?

cu,
Andreas

[Markus]

Gegenfrage: welche Vorteile erhoffst Du Dir durch die Verwendung von Frames gegenüber framefreien Seiten?

cu,
Andreas

Ich wollte einfach eine andere Seitengestaltung mit fixen Hauptnavigations-Elementen erstellen. Außerdem wäre es doch auch mit weniger Traffic verbunden, wenn Teile der Seite nicht ständig wieder geladen werden müssen - oder?

MfG

[Cheatah]

Hi,

Ich wollte einfach eine andere Seitengestaltung mit fixen Hauptnavigations-Elementen erstellen.

dafür gibt es eine gigantische Masse weitaus besserer Techniken. Das </archiv/> ist ein Quell des Wissens.

Außerdem wäre es doch auch mit weniger Traffic verbunden, wenn Teile der Seite nicht ständig wieder geladen werden müssen - oder?

Wenn Du nur zwei Frames hast, sind für das Laden der ersten Seite _drei_ Roundtrips nötig. Und in sehr vielen Fällen bleibt es bei der ersten Seite.

Cheatah

[MudGuard]

Hi,

Ich wollte einfach eine andere Seitengestaltung mit fixen Hauptnavigations-Elementen erstellen.

Zum Fixieren gibt es auch CSS - für unfähige Browser auch entsprechende JS-Hacks. Wobei fixierte Navigationen meist eine ziemliche Platzverschwendung sind.

Außerdem wäre es doch auch mit weniger Traffic verbunden, wenn Teile der Seite nicht ständig wieder geladen werden müssen - oder?

Dafür müßte in jeder Einzelseite ein Script zum Nachladen des Framesets drin sein, dazu noch ein noscript-Bereich mit einem Link auf das Frameset.
Beim ersten Laden muß zusätzlich die Frameset-Datei geladen werden, statt eines head-Bereichs sind mehrere vorhanden, dazu noch für jeden einzelnen Frame zusätzlicher http-Overhead (mehrere Requests, mehrere Response-Header).
Wo ist da der große Traffic-Gewinn?
Bilder usw. bleiben im Normalfall sowieso im Cache, es geht also nur um ein bißchen HTML.
Sorge lieber dafür, daß Du konsequent auf CSS setzt - dann bleiben Deine HTML-Dateien auch klein.

cu,
Andreas

[hook]

Hi,

Ich wollte einfach eine andere Seitengestaltung mit fixen Hauptnavigations-Elementen erstellen. Außerdem wäre es doch auch mit weniger Traffic verbunden, wenn Teile der Seite nicht ständig wieder geladen werden müssen - oder?

Wenn du eh schon Include-Techniken nutzt, dann ist die Verwendung von Frames doch ein Schritt in die falsche Richtung.
Außerdem ist die Darstellung fixer Elemente mit CSS bestens realisierbar (sogar im IE, wenn auch mir ein paar Umwegen). Das mit dem Traffic ist Käse, denn wenn ein Teil deiner Seite einmal aufgerufen wurde, dann liegt er im Browsercache.

Efchen und ich basteln gerade an einer Seite nach dem "Seybold-Prinzip" - http://frames.jan-andresen.de - Warum Layout mit Frames dumm ist

[Cyx23]

Hallo,

... Das mit dem Traffic ist Käse, denn wenn ein Teil deiner Seite einmal aufgerufen wurde, dann liegt er im Browsercache.

der Traffic-Vorteil mag sich natürlich durch evtl. nötige noframes-Strategien wieder verringern, aber abgesehen von Bild- oder Scriptdateien gibt es wohl keine Teile einer Seite sondern nur eine komplette Seite.

Der Text und HTML-Code der "Hauptnavigations-Elemente" wird wohl kaum aus dem Browsercache bezogen, es sei denn als komplette Datei eines Frames, mit Frames lässt sich insofern durchaus Traffic einparen.

Grüsse

Cyx23

[MudGuard]

Hi,

der Traffic-Vorteil mag sich natürlich durch evtl. nötige noframes-Strategien wieder verringern, aber abgesehen von Bild- oder Scriptdateien gibt es wohl keine Teile einer Seite sondern nur eine komplette Seite.
Der Text und HTML-Code der "Hauptnavigations-Elemente" wird wohl kaum aus dem Browsercache bezogen, es sei denn als komplette Datei eines Frames, mit Frames lässt sich insofern durchaus Traffic einparen.

Naja, der Markup für die Navigation ist - wenn man es sinnvoll macht - ne Liste mit ner Handvoll links drin. Der Rest ist CSS bzw. Graphik - und somit extern und bereits im Cache. Also geht es nicht um sehr viele Bytes...

cu,
Andreas

[Cyx23]

Hallo Andreas,

die Idee verschiedene Quellen in einer Seite nutzen zu können hat ja was, und per iframe-Tag läßt sich das Problem der Framesets mit der URI auch lösen; eine Antwort auf "Die Frames-Frage.." kann also "Iframe" lauten.

Naja, der Markup für die Navigation ist - wenn man es sinnvoll macht - ne Liste mit ner Handvoll links drin. Der Rest ist CSS bzw. Graphik - und somit extern und bereits im Cache. Also geht es nicht um sehr viele Bytes...

Neben der möglichen Ersparnis von Traffic geht oder ging es bei Frames auch um andere ergonomische Effekte. Besonders bei alten Browsern und bei langsameren Verbindungen nervt das erneute Aufbauen statischer Teile der Seiten und das Blitzen anderer Hintergrundfarben enorm. Solche Erfahrungen führen denn auch dazu dass Kunden ausdrücklich Frames wünschen bzw. eine gewünschte Lösung so beschreiben dass sie eine Darstellung möchten bei der nur ein bestimmter Teil der Seite verändert wird. Sie erwarten dann schon dass die übrige Seite konstant ohne Seitenaufbaueffekte permanent sichtbar bleiben soll, und der Wunsch ist ja gut nachvollziehbar.

Grüsse

Cyx23

[Cheatah]

Hi,

eine Antwort auf "Die Frames-Frage.." kann also "Iframe" lauten.

nein, das ist nur eine Verlagerung des Problems. Von der Art und Wirkungsweise ist es aber noch das selbe.

Cheatah

[Cyx23]

Hallo,

eine Antwort auf "Die Frames-Frage.." kann also "Iframe" lauten.

nein, das ist nur eine Verlagerung des Problems. Von der Art und Wirkungsweise ist es aber noch das selbe.

ist "das selbe" eigentlich mittlerweile das Gleiche wie "das gleiche"?

Aber nachvollziehen kann ich deine Äusserung dennoch nicht, zumal ich den Iframe nicht als Allheilmittel angepriesen habe. Einige wichtige Probleme bestehen wegen der Hierarchie nicht mehr, und andere Probleme gibt es bei Bildern oder anderen Quellen auch.

Grüsse

Cyx23

[hook]

Moin,

Der Text und HTML-Code der "Hauptnavigations-Elemente" wird wohl kaum aus dem Browsercache bezogen, es sei denn als komplette Datei eines Frames, mit Frames lässt sich insofern durchaus Traffic einparen.

Mag sein, aber wenn man schon eine Frame-Site bastelt, dann sollten auch Bookmarks und Querverweise funktionieren. Das setzt aber voraus, daß das Frameset immer nachgeladen wird, was wiederum JS voraussetzt. Und das erhöht ungemein den Traffic.

Wenn man PHP-include nutzt, heißt das ja noch lange nicht, daß man in alle Seiten das Menü includieren muß. Man kann die Seite auch so bauen, daß es nur noch die index.php gibt und dann wird dort nur noch der Inhalt includiert.

Frames sind auf jeden Fall out. Schau hier: http://frames.jan-andresen.de

[Cyx23]

Hallo,

Mag sein, aber wenn man schon eine Frame-Site bastelt, dann sollten auch Bookmarks und Querverweise funktionieren. Das setzt aber voraus, daß das Frameset immer nachgeladen wird, was wiederum JS voraussetzt. Und das erhöht ungemein den Traffic.

JavaScript erhöht den Traffic nicht, und das Nachladen des Framesets beim direkten Aufrufen eines Frames kann auch so gelöst werden dass die betr. Datei dann aus den Cache, also auch ohne nennenswerten Traffic, kommt.

Wenn man PHP-include nutzt, heißt das ja noch lange nicht, daß man in alle Seiten das Menü includieren muß. Man kann die Seite auch so bauen, daß es nur noch die index.php gibt und dann wird dort nur noch der Inhalt includiert.

Da versteh ich den Zusammenhang nicht, ausserdem ergeben solche Lösungen mit einer index.php unschöne Bookmarks und sind u.U. weniger performant als andere Lösungen.

Frames sind auf jeden Fall out.

Das oft unreflektierte "out" ist ja ein Grund mehr sich mit der Sache zu beschäftigen, ob Frames oder Tabellen.

Einige Vorteile der Frames sind heute weniger wichtig, einige Nachteile und Vorteile bleiben, und die entspr. Bilanz muss nicht pauschal ausfallen, eben kein "auf jeden Fall".

Grüsse

Cyx23

[Efchen]

Moin,

JavaScript erhöht den Traffic nicht

Und wer bringt dann den Code vom Server zum Browser? Der Storch? :)

ausserdem ergeben solche Lösungen mit einer index.php unschöne Bookmarks

Was sind denn "unschöne Bookmarks". Die Dinger setzt man, damit man sie aufrufen kann. Wie sie aussehen ist doch irrelevant!

Gruß,
-Efchen

[Cyx23]

Hallo,

JavaScript erhöht den Traffic nicht

Und wer bringt dann den Code vom Server zum Browser? Der Storch? :)

das was du meinst sind im einfachsten Fall keine 100 Zeichen, trotzdem erhöht JavaScript den Traffic nicht :o)

ausserdem ergeben solche Lösungen mit einer index.php unschöne Bookmarks

Was sind denn "unschöne Bookmarks". Die Dinger setzt man, damit man sie aufrufen kann. Wie sie aussehen ist doch irrelevant!

Es gibt serverseitige Methoden bei denen "normale" Adressen zu sehen sind, insofern wäre es tatsächlich weniger wichtig, allerdings dürfte das etwas Anpassung und letztlich auch Performance kosten.

Da aber Bookmarks wie auch URI wichtiger Teil der Kommunikation mit dem Besucher sind, kann gerade "Wie sie aussehen" sehr wichtig sein.

Grüsse

Cyx23

[at]

Hallo.
Wie passt ...

das was du meinst sind im einfachsten Fall keine 100 Zeichen, trotzdem erhöht JavaScript den Traffic nicht :o)

... zu ...

Es gibt serverseitige Methoden bei denen "normale" Adressen zu sehen sind, insofern wäre es tatsächlich weniger wichtig, allerdings dürfte das etwas Anpassung und letztlich auch Performance kosten.

, wenn ich einmal unterstellen darf, dass du von "mod_rewrite" etc. sprichst?
MfG, at

[Cyx23]

Hallo,

Wie passt ...
... zu ...
, wenn ich einmal unterstellen darf, dass du von "mod_rewrite" etc. sprichst?

mir ist nicht klar was du vergleichen möchtest oder was ich in Beziehung gesetzt haben sollte,
vielleicht 100 Byte Traffic einem "mod_rewrite" gegenüberstellen?

Die Technik JavaScript hat mit Traffic nichts zu tun, natürlich muss das Script irgendwie übertragen werden.
Wenn ein Script (bei mehreren HTML-Dateien) aus dem Browser-Cache geladen wird gibt es vielleicht noch eine
Serveranfrage mit der Antwort "unverändert".
Der vermutete Performanceverlust per Umleitung erstellter "normaler" Adressen, vorstellbar wäre vielleicht
auch ein Umweg über SSI, war aber sowieso nicht der wesentliche Punkt, hier ging es mir um den kommunikativen
oder ergonomischen Vorteil "normaler" Adressen mit der Feststellung dass es dazu auch (bei PHP) Lösungen gibt.

Bei client- oder serverseitig individualisierten Seiten dürfte das (eigentlich wohl langsame) JavaScript wegen der
fehlenden oder einfacheren Serveranfragen grundsätzlich Vorteile haben.
Und grundsätzlich würde ich mich auch trotz PHP und SSI aus Performancegründen erstmal für statische Seiten
auf dem Server entscheiden.

Grüsse

Cyx23

[at]

Hallo.

Der vermutete Performanceverlust per Umleitung erstellter "normaler" Adressen, vorstellbar wäre vielleicht
auch ein Umweg über SSI, war aber sowieso nicht der wesentliche Punkt, hier ging es mir um den kommunikativen
oder ergonomischen Vorteil "normaler" Adressen mit der Feststellung dass es dazu auch (bei PHP) Lösungen gibt.

Eben. Ich halte den den Geschwindigkeitsverlust durch etwa "mod_rewrite" für derart lächerlich, dass ich ihn an deiner Stelle außer Acht gelassen hätte -- zumal wenn man dazu rät, client-seitig, also auf einer Seite, die niemals im Einflussbereich des Seitenerstellers liegt, Skripte einzusetzen.

Bei client- oder serverseitig individualisierten Seiten dürfte das (eigentlich wohl langsame) JavaScript wegen der
fehlenden oder einfacheren Serveranfragen grundsätzlich Vorteile haben.

Ich kann nur dazu raten, möglichst viel auf dem Server machen zu lassen, da dessen Leistungsfähigkeit viel leichter zu beeinflussen ist. Und letztlich sind die server-seitigen Techniken ja in Bezug auf das Caching auch nicht per se schlechter.

Und grundsätzlich würde ich mich auch trotz PHP und SSI aus Performancegründen erstmal für statische Seiten
auf dem Server entscheiden.

Das hängt von den Kosten für Hardware und menschlicher Arbeit ab. Und da sich Moore's Law Gott sei Dank auf die Leistungsfähigkeit von Computern eher anwenden lässt als auf die menschliche Arbeitsleistung pro Geldeinheit, spare ich lieber ein paar Stunden redundante Arbeit und investiere sie in die Dynamisierung der Inhalte.
Allerdings gebe ich dir natürlich völlig darin Recht, dass es natürlich hinreichend viele Beispiele für überflüssige Dynamisierung gibt. Und da holt die server-seitige Dynamik tatsächlich in großen auf.
MfG, at

[Cyx23]

Hallo,

Eben. Ich halte den den Geschwindigkeitsverlust durch etwa "mod_rewrite" für derart lächerlich, dass ich ihn an deiner Stelle außer Acht gelassen hätte -- zumal wenn man dazu rät, client-seitig, also auf einer Seite, die niemals im Einflussbereich des Seitenerstellers liegt, Skripte einzusetzen.

ich halte solche Performanceverschlechterungen im Gesamtpaket grundsätzlich nicht für lächerlich, zumal sich die Verluste auf dem Server addieren, während das JavaScript selbst gar keinen Performanceverlust verursacht wenn es etwa nach dem Laden der Seite kurz das Frameset überpüft.

Ich kann nur dazu raten, möglichst viel auf dem Server machen zu lassen, da dessen Leistungsfähigkeit viel leichter zu beeinflussen ist. Und letztlich sind die server-seitigen Techniken ja in Bezug auf das Caching auch nicht per se schlechter.

Da kann ich hier und für übliche Projekte usw. nur zu anderen Strategien raten, denn schneller als eine statische Datei auszuliefern, je nach Grösse noch gzip(ed), geht es nicht, zumindest nicht bei einer üblichen eher geringen Menge an Files.

Das hängt von den Kosten für Hardware und menschlicher Arbeit ab. Und da sich Moore's Law Gott sei Dank auf die Leistungsfähigkeit von Computern eher anwenden lässt als auf die menschliche Arbeitsleistung pro Geldeinheit, spare ich lieber ein paar Stunden redundante Arbeit und investiere sie in die Dynamisierung der Inhalte.

Da ist mir nicht klar wo das Problem liegen soll, du kannst ja dein CMS statische Seiten erstellen lassen und deinen Server von überflüssiger Last verschonen.

Grüsse

Cyx23

[at]

Hallo.

ich halte solche Performanceverschlechterungen im Gesamtpaket grundsätzlich nicht für lächerlich, zumal sich die Verluste auf dem Server addieren, während das JavaScript selbst gar keinen Performanceverlust verursacht wenn es etwa nach dem Laden der Seite kurz das Frameset überpüft.

Es verschiebt die Verluste nur an eine nicht zu beeinflussende Stelle.

Da kann ich hier und für übliche Projekte usw. nur zu anderen Strategien raten, denn schneller als eine statische Datei auszuliefern, je nach Grösse noch gzip(ed), geht es nicht, zumindest nicht bei einer üblichen eher geringen Menge an Files.

Das Entpacken addierte sich in einem solchen Fall also zu den client-seitigen Skripten.

Das hängt von den Kosten für Hardware und menschlicher Arbeit ab. Und da sich Moore's Law Gott sei Dank auf die Leistungsfähigkeit von Computern eher anwenden lässt als auf die menschliche Arbeitsleistung pro Geldeinheit, spare ich lieber ein paar Stunden redundante Arbeit und investiere sie in die Dynamisierung der Inhalte.

Da ist mir nicht klar wo das Problem liegen soll, du kannst ja dein CMS statische Seiten erstellen lassen und deinen Server von überflüssiger Last verschonen.

Wozu? Das CMS soll mich entlasten, nicht umgekehrt.
MfG, at

[Cybaer]

Hi,

Es verschiebt die Verluste nur an eine nicht zu beeinflussende Stelle.

Du meinst, intensiver Gebrauch von JS könnte den User ärgern, weil er deswegen für das MPEG-Encoding im Hintergrund 1 sec länger braucht als sonst? ;-)

Da ist mir nicht klar wo das Problem liegen soll, du kannst ja dein CMS statische Seiten erstellen lassen und deinen Server von überflüssiger Last verschonen.
Wozu? Das CMS soll mich entlasten, nicht umgekehrt.

Das ist kein Widerspruch. Meine erste Site basierte auf einem solchen CMS. (Mehrfaches) Layout und Inhalt getrennt (das geht ja auch ohne CSS). Das CMS generierte sowohl statische Seiten, als auch die Datenbasis für Online-generierte (ebenfalls Suchmaschinen-freundliche) Seiten - und auf Wunsch auch letztere als statische Seiten für die Offline-Verwertung (jeweils mit Link zur entsprechenden Server-Seite für Online-Bestellungen und Updates), welche für Messen, Händler und Endkunden genutzt wurde.

Ein Klick, und die "Arbeit" war erledigt ... :)

Gruß, Cybaer

[at]

Hallo.

Du meinst, intensiver Gebrauch von JS könnte den User ärgern, weil er deswegen für das MPEG-Encoding im Hintergrund 1 sec länger braucht als sonst? ;-)

Nicht einmal das. Ich meine, dass ich keinen Einfluss darauf habe,

• welche Leistungsfähigkeit die Hardware-/Software-Kombination des Nutzers hat und
• welche Dinge der Nutzer gleichzeitig betreibt.
  Das überstrapazierte Argument des abgeschalteten Javascript lasse ich mal in der Mottenkiste.

Wozu? Das CMS soll mich entlasten, nicht umgekehrt.

Das ist kein Widerspruch.

Nein, natürlich nicht.

Meine erste Site basierte auf einem solchen CMS. (Mehrfaches) Layout und Inhalt getrennt (das geht ja auch ohne CSS). Das CMS generierte sowohl statische Seiten, als auch die Datenbasis für Online-generierte (ebenfalls Suchmaschinen-freundliche) Seiten - und auf Wunsch auch letztere als statische Seiten für die Offline-Verwertung (jeweils mit Link zur entsprechenden Server-Seite für Online-Bestellungen und Updates), welche für Messen, Händler und Endkunden genutzt wurde.

Und wenn es das CMS besonders gut meint, auch gern noch eine Druck-Version als PDF. Das wollte ich nicht in Frage gestellt haben. Am Impressum etwa oder am Kontaktformular ändert sich ja nicht täglich etwas -- hoffentlich.

Ein Klick, und die "Arbeit" war erledigt ... :)

So muss das sein.
MfG, at

[ShiNtoKu]

Hi,

Efchen und ich basteln gerade an einer Seite nach dem "Seybold-Prinzip" - http://frames.jan-andresen.de - Warum Layout mit Frames dumm ist

Hier http://frames.jan-andresen.de/08_nt_5_skal.php verweist der Link "Warum Seitenoptimierung für bestimmte Auflösungen keinen Sinn macht" lediglich auf ein Login-Formular (http://aufloesung.jan-andresen.de/)

Gruss
shin

[hook]

Moin,

Hier http://frames.jan-andresen.de/08_nt_5_skal.php verweist der Link "Warum Seitenoptimierung für bestimmte Auflösungen keinen Sinn macht" lediglich auf ein Login-Formular

Naja, ich sagte ja, daß wir noch am "basteln" sind, die Auflösungsseite ist noch nicht fertig. Ich werde aber demnächst mal ein Baustellenschild platzieren.

[ShiNtoKu]

Hi,

Naja, ich sagte ja, daß wir noch am "basteln" sind, die Auflösungsseite ist noch nicht fertig. Ich werde aber demnächst mal ein Baustellenschild platzieren.

Achso, sah so fertig aus ;)

Gruss
shin

[Detlef G.]

Hallo hook

Naja, ich sagte ja, daß wir noch am "basteln" sind, die Auflösungsseite ist noch nicht fertig. Ich werde aber demnächst mal ein Baustellenschild platzieren.

Besser wäre es den Link (noch) nicht anzubieten.

Auf Wiederlesen
Detlef

[molily]

Hallo,

Efchen und ich basteln gerade an einer Seite nach dem "Seybold-Prinzip" - http://frames.jan-andresen.de - Warum Layout mit Frames dumm ist

Wenn ein Artikel einen solchen Titel hat, ist man sehr geneigt, anzunehmen, dass die Auseinandersetzung auf ähnlich undifferenziertem Niveau abläuft und reines Idelogiegequatsche ist. Das Allerschwächste am Seybold-Artikel ist dieser belehrend-polemische Gestus, den ihr nicht auch noch übernehmen solltet, wenn ihr ernst genommen werden wollt.

Darüber hinaus: Was sagt der Artikel überhaupt?
Auf http://frames.jan-andresen.de/ weist ihr darauf hin, dass die Kompatibilität zu Browsern, die keine Frames unterstützen, vergleichsweise unproblematisch und schnell hergestellt werden kann. Das leuchtet ein. Ein paar Schritte später http://frames.jan-andresen.de/04_nt_1_such.php behauptet ihr das Gegenteil, indem ihr davon ausgeht, dass noframes sowieso unsachgemäß gefüllt wird. Wieso ist das nun ein Nachteil von Frames? Ich bitte euch, wenn ihr euch ernsthaft in dieser Debatte äußern wollt, dann solltet ihr diese simple Unterscheidung verstanden haben.
http://frames.jan-andresen.de/05_nt_2_nav.php fällt im Prinzip in dieselbe Kategorie.
http://frames.jan-andresen.de/06_nt_3_book.php - Der MSIE kann Frames als Zusammenhang bookmarken.
http://frames.jan-andresen.de/08_nt_5_skal.php verstehe ich schlichtweg nicht. »Die Definition des Framesets erfordert die Angabe von festen Fenstergrößen. Doch weder die Angabe in Pixel noch in Prozent nimmt Rücksicht auf die Inhalte der anzuzeigenden Seiten.« - Und bei CSS-Layout ist das anders? Da lassen sich Spaltenbreiten auch nicht flexibler festlegen, es sei denn, man verwirft das Spaltenkonzept. Aber dann würde das Argument wegfallen, weil Äpfel mit Birnen verglichen würden. Bei Zeilen habt ihr hingegen recht, hängt aber wieder mit der konkreten Verwendung zusammen.
http://frames.jan-andresen.de/10_framing.php - Ich habe nie verstanden, was das Thema mit Frames zu tun hat. Wieso ist das ein Nachteil von Frames? Niemand will ernsthaft externe Seiten im eigenen Frameset laden.
http://frames.jan-andresen.de/11_konzept.php beinhaltet keine Argumente und ist so abgeschrieben, ohne Substanz beizumengen.

Ansonsten: Nichts Neues, nicht einmal das Bekannte in herausragender Form präsentiert. Mit Verlaub, ich habe schon soviele mittelmäßige Abhandlung mit exakt dieser Form gelesen, die Welt braucht nicht eine weitere, die die bekannten Quellen dürftig zusammenfasst und zum Teil schlichtweg plagiiert. Verzeihung, so wird es nichts, es bedarf viel mehr.

Mathias

[MudGuard]

Hi,

http://frames.jan-andresen.de/08_nt_5_skal.php verstehe ich schlichtweg nicht. »Die Definition des Framesets erfordert die Angabe von festen Fenstergrößen. Doch weder die Angabe in Pixel noch in Prozent nimmt Rücksicht auf die Inhalte der anzuzeigenden Seiten.« - Und bei CSS-Layout ist das anders? Da lassen sich Spaltenbreiten auch nicht flexibler festlegen, es sei denn, man verwirft das Spaltenkonzept.

CSS bietet mehr als nur Pixel und Prozent als Einheiten - insbesondere die schriftgrößenabhängigen Einheiten em und ex erlauben m.E. doch etwas mehr Flexibilität, nämlich die Anpassung einer Spaltenbreite an den enthaltenen Text unabhängig von der Schriftgröße.

cu,
Andreas

[molily]

Hallo,

http://frames.jan-andresen.de/08_nt_5_skal.php verstehe ich schlichtweg nicht. »Die Definition des Framesets erfordert die Angabe von festen Fenstergrößen. Doch weder die Angabe in Pixel noch in Prozent nimmt Rücksicht auf die Inhalte der anzuzeigenden Seiten.« - Und bei CSS-Layout ist das anders? Da lassen sich Spaltenbreiten auch nicht flexibler festlegen, es sei denn, man verwirft das Spaltenkonzept.

CSS bietet mehr als nur Pixel und Prozent als Einheiten - insbesondere die schriftgrößenabhängigen Einheiten em und ex erlauben m.E. doch etwas mehr Flexibilität, nämlich die Anpassung einer Spaltenbreite an den enthaltenen Text unabhängig von der Schriftgröße.

Wenn ich ein Frameset mit zwei Spalten habe, also etwa das klassische Schema »Navigation links mit x Pixel, Inhalt rechts mit der verbleibenden Breite«, dann reagieren die Spaltenbreiten logischerweise nicht auf die Schriftgröße. Wenn ich die Schrift vergrößere und gleichzeitig unterschiedliche Fensterbreiten annehme, dann kommt es irgendwann dazu, dass die Zeilen extrem schmal werden. Beim längsten Wort hört das Gestauche auf und spätestens dann werden im linken Frame horizontale Scrollleisten angezeigt.
Der rechte Frame wäre noch besser dran, weil der linken Frame vielleicht eine vorgegebene Breite von 250-300 Pixel hätte. Damit wäre der rechte selbst bei extrem wirklichkeitsfremden 620 Pixeln Fenster(innen)breite geringfügig breiter. Insofern wäre eine kleine Fensterbreite an sich kein gravierendes Problem im Vergleich zur Textvergrößerung. Wenn man vorher nichts gequetscht hat und lange Wörter hat, kommt es schon vielleicht bei 150-prozentiger Vergrößerung zu einer horizontalen Scrollleiste im linken Frame. Da kann ein Frameset natürlich nicht mithalten. Allerdings besteht hier die Möglichkeit, die Framegrenzen beliebig zu verschieben und somit dem einen Frame vorübergehend die gesamte Breite zu geben und den anderen auszublenden.

Wenn dieses klassische Spaltenlayout nun mit float:left und bspw. width:12-15em bzw. margin-left:12-15em in CSS umgesetzt wird (im Prinzip kann aber höchstens geschätzt werden, wie breit ein bestimmter Text bei der Darstellung sein wird) und in der rechten Spalte nur frei fließender Text ist (dasselbe habe ich oben angenommen), dann ist es ebenfalls relativ unempfindlich gegenüber die gängigen Varianzen der Fenster(innen)breite. (Auf einem Mikrodisplay sind jegliche Layouts, die so arbeiten, hinfällig, das Argument zieht nicht.) Bei Schriftvergrößerung wächst die linke Spalte glücklicherweise mit, sodass bei entsprechender Breite Vergrößerungen bis zu 200% problemlos möglich sind. Wenn vergrößerte Schrift und schmale Fenster zusammentreffen, bleibt die linke Spalte mit fester em-Breite standhaft. Breite Worte bzw. Objekte daneben in der rechten Spalte fließen aus dem Container und erzeugen eine horizontale Scrollleiste. Letztendlich ist diese Zweispaltigkeit starrer als die des Framesets, deren Spaltenaufteilung sich wenigstens steuern und temporär außer Kraft setzen lässt (ob das nun gerade intuitiv ist, ist eine andere Frage).
Man könnte zwar Argumentieren, dass man CSS ja abschalten kann, was bei 200% Vergrößerung und mickrigem Display sowieso ratsam wäre, aber was zählt das? Dann könnte man auch mit abgeschalteten Frames surfen, das ist letztlich eine ähnliche Form, um erzwungene Mehrspaltigkeit, die sowohl beim beschriebenen Frames- als auch beim CSS-Layout vorliegt, zu verhindern.

Ich sehe, was solche extremen Situationen angeht, in denen Flexibilität wirklich eine Rolle spielt, keine großen Unterschiede zwischen einem Frames-Spaltenlayout und einem äquivalenten CSS-Layout. Der Frame-Verteidiger könnte argumentieren, dass er einfach den linken Frame verbreitert und somit die Schwelle, an der die Mehrspaltigkeit problematisch wird, nach oben setzt und sich somit der Schwelle des CSS-Layouts annähert.

Mathias

[Ingo Turski]

Hi,

Wenn man vorher nichts gequetscht hat und lange Wörter hat, kommt es schon vielleicht bei 150-prozentiger Vergrößerung zu einer horizontalen Scrollleiste im linken Frame. Da kann ein Frameset natürlich nicht mithalten. Allerdings besteht hier die Möglichkeit, die Framegrenzen beliebig zu verschieben und somit dem einen Frame vorübergehend die gesamte Breite zu geben und den anderen auszublenden.

die Möglichkeit schon, aber wo wird denn davon Gebrauch gemacht? Überwiegend werden die Frameborder doch deaktiviert. Dies mag zwar ein grundsätzlich zutreffendes Argument sein, aber völlig an der Praxis vorbei, in der Frames zu Layoutzwecken eingesetzt werden und Border stören würden.

Wenn dieses klassische Spaltenlayout nun mit float:left und bspw. width:12-15em bzw. margin-left:12-15em in CSS umgesetzt wird {...]
Wenn vergrößerte Schrift und schmale Fenster zusammentreffen, bleibt die linke Spalte mit fester em-Breite standhaft. Breite Worte bzw. Objekte daneben in der rechten Spalte fließen aus dem Container und erzeugen eine horizontale Scrollleiste. Letztendlich ist diese Zweispaltigkeit starrer als die des Framesets, deren Spaltenaufteilung sich wenigstens steuern und temporär außer Kraft setzen lässt (ob das nun gerade intuitiv ist, ist eine andere Frage).

Auch das wiederum geht an der Praxis vorbei. Denn ein Zusammentreffen von sehr kleiner Fensterbreite und extremer Schriftvergrößerung düfte kaum vorkommen; wer sehschwach ist und eine sehr große Schrift verwendet wird zumindest ein ausreichend großes Fenster haben - andernfalls hätte er bei den weitaus meisten Seiten Probleme.
Ein Menü mit relativ kurzen Linktexten läßt sich in aller Regel unproblematisch für den Inhaltsbereich auch 200% oder mehr vergrößern. Abgesehen davon kann man eine Seite auch so gestalten, daß sich der Inhaltsbereich in solchen Extremfällen unter das Menü setzt.

freundliche Grüße
Ingo

[molily]

Hallo,

(...) Allerdings besteht hier die Möglichkeit, die Framegrenzen beliebig zu verschieben und somit dem einen Frame vorübergehend die gesamte Breite zu geben und den anderen auszublenden.
die Möglichkeit schon, aber wo wird denn davon Gebrauch gemacht? Überwiegend werden die Frameborder doch deaktiviert. Dies mag zwar ein grundsätzlich zutreffendes Argument sein, aber völlig an der Praxis vorbei, in der Frames zu Layoutzwecken eingesetzt werden und Border stören würden

Mein wichtigster Kritikpunkt in [pref:t=84745&m=498144] war bereits, dass es auf der einen Seite die Technik Frames als Möglichkeit gibt, die ein Autor ergreifen kann. Auf der anderen Seite steht die gängige Praxis der Frameanwendung, bei denen Frames mehr als Lückenbüßer angesehen werden, obwohl eigentlich etwas anderes gefragt ist (etwa position:fixed). Dabei fragt sich niemand, was die Eigenheiten der Technik sind und dass es jenseits von »Frames als Layoutinstrument« eben diese Möglichkeiten der Raumaufteilung gibt. Wenn man darüber nachdenkt, was der Frameeinsatz unter bestimmten Umständen nach sich zieht, kann man durchaus darüber hinaus, was die gängige Praxis ist.

Wenn dieses klassische Spaltenlayout nun mit float:left und bspw. width:12-15em bzw. margin-left:12-15em in CSS umgesetzt wird {...]
Wenn vergrößerte Schrift und schmale Fenster zusammentreffen, bleibt die linke Spalte mit fester em-Breite standhaft. Breite Worte bzw. Objekte daneben in der rechten Spalte fließen aus dem Container und erzeugen eine horizontale Scrollleiste. Letztendlich ist diese Zweispaltigkeit starrer als die des Framesets, deren Spaltenaufteilung sich wenigstens steuern und temporär außer Kraft setzen lässt (ob das nun gerade intuitiv ist, ist eine andere Frage).
Auch das wiederum geht an der Praxis vorbei. Denn ein Zusammentreffen von sehr kleiner Fensterbreite und extremer Schriftvergrößerung düfte kaum vorkommen;

Ich halte diese Situation nicht für konstruiert. Dass im Vergleich zum besagten Frameset stärkere Abweichungen nötig sind, will ich nicht bestreiten. Der Punkt ist eben, dass ich in dem besagten Vorteil von CSS, ex/ex-Breiten einzusetzen und damit der Schriftvergrößerung zu begegnen, keinen absoluten, sondern nur einen relativen Vorteil sehe, der unter bestimmten Bedingungen zum tragen kommt, unter anderen nur undeutlich (insbesondere, wenn diese Situatinen betrachtet werden, in denen die Mehrspaltigkeit zum Problem wird).

Abgesehen davon kann man eine Seite auch so gestalten, daß sich der Inhaltsbereich in solchen Extremfällen unter das Menü setzt.

Dazu sagte ich schon: »Da lassen sich Spaltenbreiten auch nicht flexibler festlegen, es sei denn, man verwirft das Spaltenkonzept.« Und das float ohne margin wäre genau dies. »Aber dann würde das Argument wegfallen, weil Äpfel mit Birnen verglichen würden.« Die Frage, die ich mir stellte, war, inwiefern ein typisches Spaltenlayout mit Frames bzw. äquivalent CSS mit margin in der CSS-Variante flexibler ist. Dass man mit CSS grundlegend andersartige Layouts realisieren kann, die mit Frames undenkbar sind (und umgekehrt), ist unstrittig. Wenn man davon ausgeht, dann müsste das Argument gegen Frames aber eher lauten, dass CSS an sich flexiblere Layouts zulässt. Meine Kritik zielte darauf ab, aus den em/ex-Containerbreiten ein Hauptargument abzuleiten.

Mathias

[Cybaer]

Hi,

die Möglichkeit schon, aber wo wird denn davon Gebrauch gemacht? Überwiegend werden die Frameborder doch deaktiviert.

Mal vom Umstand abgesehen, daß ich niemandem zu einem schmalen, statischen Frame raten würde, wenn er anderes als eine schmale, statische Navigation unterbringen möchte (selbst nicht in DHTML):

Für Border und Resize gibt es getrennte Attribute. Es gibt folglich auch keinen Grund, einen Frame ohne Border nicht trotzdem in der Größe veränderbar zu machen, wenn der Autor dies so niedergeschrieben hat.

Gruß, Cybaer

[Ingo Turski]

Hi,

Für Border und Resize gibt es getrennte Attribute. Es gibt folglich auch keinen Grund, einen Frame ohne Border nicht trotzdem in der Größe veränderbar zu machen, wenn der Autor dies so niedergeschrieben hat.

Wäre dies denn wirklich nutzbar? Selbst wenn man im Design eine Trennlinie berücksichtigen würde, könnte man die Frameränder tatsächlich verschieben?

freundliche Grüße
Ingo

[Cybaer]

Hi,

Wäre dies denn wirklich nutzbar? Selbst wenn man im Design eine Trennlinie berücksichtigen würde, könnte man die Frameränder tatsächlich verschieben?

Praktisch: Ja, es geht.

Theoretisch: Kommt der User drauf? Na ja, "der User" käme wohl selbst dann nicht drauf, wenn man noch einen riesigen Pfeil hinmachen würde. ;-)

Ich denke, daß die wenigstens User überhaupt etwas an ihrem Browser verstellen (außer Bookmarks hinzuzufügen), und er einfach so funktioniert, wie er mal eingerichtet wurde ...

Gruß, Cybaer

[Cyx23]

Hallo,

Wäre dies denn wirklich nutzbar? Selbst wenn man im Design eine Trennlinie berücksichtigen würde, könnte man die Frameränder tatsächlich verschieben?

Praktisch: Ja, es geht.

Theoretisch: Kommt der User drauf? Na ja, "der User" käme wohl selbst dann nicht drauf, wenn man noch einen riesigen Pfeil hinmachen würde. ;-)

Ich denke, daß die wenigstens User überhaupt etwas an ihrem Browser verstellen (außer Bookmarks hinzuzufügen), und er einfach so funktioniert, wie er mal eingerichtet wurde ...

es geht um das Verschieben der Fenstergrenze? Ja warum sollte es denn bloß soviele unerfahrene oder uninteressierte User geben?

Selbst wenn bestimmte Dinge sich beim Browser etwas anders verhalten als bei übriger Software, eine deutliche Trennlinie die beim Überfahren mit der Maus aus dem Cursor ein Verschiebsymbol macht, <- || -> oder wenigstens <- ->, spricht doch schon eine recht deutliche und bekannte Sprache. Wenn das dann den sonstigen Erfahrungen widerspricht und beim ersten Mal nur 50% auf die Idee kommen, was solls, der Rest merkt es dann beim zweiten oder dritten Mal. Bei Seiten wie z.B. PHP-Handbuch ist sowas eigentlich ideal, aber sowas wird dann wohl irgendwann auch noch einem verschlimmbessernden Zeitgeist zum Opfer fallen.

Grüsse

Cyx23

[Cybaer]

Hi,

es geht um das Verschieben der Fenstergrenze?

Framegrenze.

Ja warum sollte es denn bloß soviele unerfahrene oder uninteressierte User geben?

Warum gibt es so viele User, die mit unsicherem IE surfen?

Selbst wenn bestimmte Dinge sich beim Browser etwas anders verhalten als bei übriger Software, eine deutliche Trennlinie die beim Überfahren mit der Maus aus dem Cursor ein Verschiebsymbol macht, <- || -> oder wenigstens <- ->, spricht doch schon eine recht deutliche und bekannte Sprache.

Das ist für mich jetzt keine Frage der Theorie, sondern eine Frage der Praxis!

Ich stimme Dir zu, wenn man eine sichtbare Trennlinie hat. Die wird bei Frames aus Gründen des Design ja, wie erwähnt, oft unterdrückt. Bleibt also noch eine "unsichtbare" Trennlinie zw. den Frames. Und an der wechselt zumindest der IE eben nicht den Mauszeiger wenn der Frame trotz Null-Border "resizeable" ist. Ändern kann man die Framegrößen gleichwohl.

Gruß, Cybaer

PS: Bringt mich aber auf eine Idee: Maus-Position abfragen und ggf. selbst den Curor ändern. :-)

[Cyx32]

Hallo Cybaer,

Ja warum sollte es denn bloß soviele unerfahrene oder uninteressierte User geben?

Warum gibt es so viele User, die mit unsicherem IE surfen?

normale Bequemlichkeit, Vernunft (never change a running system), schlechte Erfahrungen mit Installationen, best viewed @ie, oder die Feststellung dass der Mozilla nicht soviel besser, aber langsamer ist?

Ich stimme Dir zu, wenn man eine sichtbare Trennlinie hat. Die wird bei Frames aus Gründen des Design ja, wie erwähnt, oft unterdrückt. Bleibt also noch eine "unsichtbare" Trennlinie zw. den Frames. Und an der wechselt zumindest der IE eben nicht den Mauszeiger wenn der Frame trotz Null-Border "resizeable" ist. Ändern kann man die Framegrößen gleichwohl.

Bei einer unsichtbaren Tennung wird es allerdings sehr ärgerlich, zumal es Situationen gibt bei denen man solche Frames versehentlich verschiebt und u.U. nicht wieder zurückbekommt.

PS: Bringt mich aber auf eine Idee: Maus-Position abfragen und ggf. selbst den Curor ändern. :-)

Wenn da nicht soviel Unruhe aufkommt wäre u.U. ein onmouseover Sichtbarmachen oder eine Simulation der Framegrenze unterstützend, ansonsten ist der Idealfall eine vorher sichtbare Framgrenze.

Und bei den Fällen wo Frames besonders stimmig sind ist dürfte auch die sichtbare Framegrenze an ehesten ein richtiges Design ergeben.

Grüsse

Cyx23

[Cybaer]

Hi,

Warum gibt es so viele User, die mit unsicherem IE surfen?
normale Bequemlichkeit, Vernunft (never change a running system), schlechte Erfahrungen mit Installationen, best viewed @ie, oder die Feststellung dass der Mozilla nicht soviel besser, aber langsamer ist?

(grummel)  War natürlich'ne rhetorische Frage. :)

Bleibt IMHO die "normale Bequemlichkeit", auf die ich hinaus wollte. Alles andere ist i.d.R. unvernünftig (Betonung auf *unsicherem* IE) und hier wohl kaum umstritten. ;-)

Bei einer unsichtbaren Tennung wird es allerdings sehr ärgerlich, zumal es Situationen gibt bei denen man solche Frames versehentlich verschiebt und u.U. nicht wieder zurückbekommt.

Na ja, ein Reload sollte es tun.

Und bei den Fällen wo Frames besonders stimmig sind ist dürfte auch die sichtbare Framegrenze an ehesten ein richtiges Design ergeben.

Na ja, absolut kantige Übergänge sind nicht gerade das, was ich mir unter einer "schönen Optik" vorstelle.

Gruß, Cybaer

[hook]

Mahlzeit,

Auf http://frames.jan-andresen.de/ weist ihr darauf hin, dass die Kompatibilität zu Browsern, die keine Frames unterstützen, vergleichsweise unproblematisch und schnell hergestellt werden kann. Das leuchtet ein.

Ja, aber niemand tut das, weil ja immer vorrausgesetzt wird, das ein grafischer Browser oder noch schlimmer, der IE, benutzt werden. Hast du schon mal ein Frameset gesehen, in dem der noframe-Bereich sinnvoll gefüllt war? Ich nicht. Text- und Vorlesebrowser werden (fast) immer ignoriert.

Ein paar Schritte später http://frames.jan-andresen.de/04_nt_1_such.php behauptet ihr das Gegenteil, indem ihr davon ausgeht, dass noframes sowieso unsachgemäß gefüllt wird.

Tun wir das? Nö, es ist eine Tatsche.

Wieso ist das nun ein Nachteil von Frames?

Weil Suchmaschinen den Links einer Seite folgen. Eine Frameset-Datei enthält aber keine Links, jedenfalls nicht, wenn im noframe-Bereich keine angegeben sind, also ist es ein Nachteil.

http://frames.jan-andresen.de/06_nt_3_book.php - Der MSIE kann Frames als Zusammenhang bookmarken.

Na toll, und die anderen zig Browser werden mal wieder ignoriert.

http://frames.jan-andresen.de/08_nt_5_skal.php verstehe ich schlichtweg nicht. [...] Und bei CSS-Layout ist das anders?

Ja ist es, aber das wurde schon beantwortet.

http://frames.jan-andresen.de/10_framing.php - Ich habe nie verstanden, was das Thema mit Frames zu tun hat. Wieso ist das ein Nachteil von Frames?

Es ist kein Nachteil, es ist ein Problem, und zwar ein rechtliches.

Niemand will ernsthaft externe Seiten im eigenen Frameset laden.

Nee? Na aber sehr viele tun es, vor allem die Anfänger.

http://frames.jan-andresen.de/11_konzept.php beinhaltet keine Argumente und ist so abgeschrieben, ohne Substanz beizumengen.

Verzeihung, so wird es nichts, es bedarf viel mehr.

Verbesserungsvorschläge bitte.

[molily]

Hallo,

(...) aber niemand tut das, weil ja immer vorrausgesetzt wird, das ein grafischer Browser oder noch schlimmer, der IE, benutzt werden. Hast du schon mal ein Frameset gesehen, in dem der noframe-Bereich sinnvoll gefüllt war? Ich nicht. (...)

Wieso ist das nun ein Nachteil von Frames?

Weil Suchmaschinen den Links einer Seite folgen. Eine Frameset-Datei enthält aber keine Links, jedenfalls nicht, wenn im noframe-Bereich keine angegeben sind, also ist es ein Nachteil.

Abgesehen davon, dass es ein Mythos ist, dass aktuelle Suchmaschinen nicht die Unterseiten eines Framesets indizieren (also den URLs in <frame src="..."> folgen), hast du nicht verstanden, worauf ich doch im Kern hinauswollte: Dass eine Technik entgegen dem Sinn derselben gebraucht wird, ist kein Nachteil der Technik an sich. Daraus lässt sich kein Argument destillieren, das gegen die Verwendung von Frames spricht. Es spricht lediglich gegen die unsachgemäße Verwendung von Frames, ist also kein Beleg hinsichtlich euer These bzw. kein Argument hinsichtlich euer Frage.

http://frames.jan-andresen.de/06_nt_3_book.php - Der MSIE kann Frames als Zusammenhang bookmarken.

Na toll, und die anderen zig Browser werden mal wieder ignoriert.

Ich wollte damit sagen, dass eure Darstellung unvollständig ist, nicht das Argument an sich widerlegen.

Niemand will ernsthaft externe Seiten im eigenen Frameset laden.

Nee? Na aber sehr viele tun es, vor allem die Anfänger.

Siehe oben.

Verzeihung, so wird es nichts, es bedarf viel mehr.

Verbesserungsvorschläge bitte.

Ernsthaft? Ich weiß gar nicht, welchen Zweck der Artikel verfolgt. Das müsst ihr schon selbst entscheiden. Wollt ihr eine weiteres belehrendes Statement der Marke »Frames sind scheiße« abgeben? Wenn es so ist, dann ist mein ernsthafter Verbesserungsvorschlag, es sein zu lassen. (Dasselbe gälte für ein ebenso unreflektiertes »Frames sind doch gar nicht so schlecht, wie alle immer sagen!«) Damit tätet ihr der Sache den größten Gefallen. Wenn ihr hingegen daran interessiert seid, eine gehaltvolle Erörterung ohne die plumpe Rhetorik (»Frames sind out!«, »Frames sind dumm!«, »Nur Dumme benutzen Frames!«, »Benutzt auf keinen Fall Frames!«) zu erarbeiten, die Webautoren über die Möglichkeiten der Framenutzung und deren Nachteile aufklärt: Lest euch intensiv in das Thema ein, indem ihr euch die Diskussionen der letzten Jahre anschaut. Betreibt selbst Experimente. Schreibt die Argumente nicht einfach ab, sondern macht euch selbst Gedanken und versucht, die bestehenden Argumente von Grund auf zu rekonstruieren (»was ist denn überhaupt dran an den immer wieder ins Feld geführten Argumenten?«; dazu habt ihr ja schon Ansätze). Dann löst euch von irrelevanten Pseudoargumenten, die nichts mit der zu behandelnden Frage zu tun haben (»Frames werden meist unsachgemäß angewendet«).
Ich habe mich nie daran gewagt, eine solche Abhandlung zu schreiben, weil ich den nötigen Aufwand für gigantisch halte, wenn sie die Problematik halbwegs komplett umreißen will. Nachplappern der üblichen Vorurteile und Phrasen (à la »Probleme mit Suchmaschinen«) hingegen kann nicht der Sinn eines solchen Artikels sein. Die oft genannten existierenden Quellen werden auch eher verlinkt, weil sie zumindest ein wenig an der Oberfläche kratzen, nicht, weil sie sonderlich gehaltvoll und differenziert sind. Insofern steht das Schreiben eines brauchbaren Artikels zum Thema noch aus.

Mathias

[Cyx32]

Hallo Mathias,

Ich habe mich nie daran gewagt, eine solche Abhandlung zu schreiben, weil ich den nötigen Aufwand für gigantisch halte, wenn sie die Problematik halbwegs komplett umreißen will. Nachplappern der üblichen Vorurteile und Phrasen (à la »Probleme mit Suchmaschinen«) hingegen kann nicht der Sinn eines solchen Artikels sein.

mal ganz unabhängig vom konkreten Thema oder Anlass, irgendeine Qualität sollte einer Veröffentlichung natürlich schon zugrundeliegen. Und angesichts der manchmal etwas schlampigen Recherche einiger prominenter Seiten ist eine Forderung ganz klar: Es besser machen. Eine andere Forderung ist aber auch es nicht an übertriebener Perfektion scheitern zu lassen.

Da du ja eine Vorliebe für Allgemeinplätze hast, es geht mir dabei weniger um das gesunde Mittelmaß, sondern um die mögliche Vielfalt und die nötige Risikobereitschaft, ausgehend von der Voraussetzung dass ein Autor auch wirklich etwas mitzuteilen hat.

Grüsse

Cyx32

[at]

Hallo.

mal ganz unabhängig vom konkreten Thema oder Anlass, irgendeine Qualität sollte einer Veröffentlichung natürlich schon zugrundeliegen. Und angesichts der manchmal etwas schlampigen Recherche einiger prominenter Seiten ist eine Forderung ganz klar: Es besser machen. Eine andere Forderung ist aber auch es nicht an übertriebener Perfektion scheitern zu lassen.

Kurz: Nur wer nichts macht, macht keine Fehler.
MfG, at

[Gunnar Bittersmann]

Mal abgesehen von den Textbrowsern (z.B. unter Linux) sollte es heute doch jedem Browser möglich sein Frames korrekt anzuzeigen oder?

Ja, sogar Textbrowser können das.

Das Problem ist das Framekonzept an sich. Du hast nicht den URI der eigentlichen Seite(n) in der Adressleiste, kannst diese schlecht bookmarken oder verlinken. (Verlinkst du auf eine Seite des Framesets, fehlt z.B. die Navigation.)

An anderen Problem bereitet das Ausdrucken.

Frames schaffen mehr Nachteile als dass sie dem Nutzer Vorteile bringen. Des halb sollten sie vermieden werden.

Siehe http://www.subotnik.net/html/frames.html

Gunnar

[Markus]

Siehe http://www.subotnik.net/html/frames.html

Gunnar

Hallo!
Sehr guter Link! Vielen Dank - ich denke ich bleibe dann bei meiner "PHP-Include"-Umsetzung.

MfG

[Louis]

Hallo Markus

Ich will in nächster Zeit meine Homepage überarbeiten. Nun stellt sich mir die "Frames-Frage"! Man liest immer, dass Frames nicht von allen Browsern dargestellt werden können bzw. nicht richtig. Aber ist die Aussage noch haltbar?

Wer sagt denn, dass das die einzigen Probleme sind? Hast Du schon mal im </archiv/> gesucht? Da gibt's haufenweise Diskussionen zu dem Thema...

Gruss
Louis

[H2O]

Hallo.

Ich will in nächster Zeit meine Homepage überarbeiten. Nun stellt sich mir die "Frames-Frage"! Man liest immer, dass Frames nicht von allen Browsern dargestellt werden können bzw. nicht richtig. Aber ist die Aussage noch haltbar?

Nicht wirklich. Ich denke auch, dass so gut wie jeder Browser Frames anzeigt.

Mal abgesehen von den Textbrowsern (z.B. unter Linux) sollte es heute doch jedem Browser möglich sein Frames korrekt anzuzeigen oder?

Ja.

Also kann man heute Frames ohne Bedenken verwenden oder nicht? Die wenigen Leute, die mit Textbrowsern die Seite besuchen, klammere ich mal aus, da das mit Sicherheit nicht mal 1% ist.

Ohne Bedenken verwenden? - Nein.

Sie bereiten wirklich mehr Nach- als Vorteile.
Benutze lieber einfache Seiten.
Diese sind leichter zu velinken und mittlerweile gibt es Includes, so dass es auch kein Problem mehr ist Inhalte schnell zu ändern.

Ich hoffe ich konnte helfen, H2O

[Cyx23]

Hallo,

zu der "Frames-Frage" sollten eher andere Aussagen als von dir vermutet zu finden sein. Und "Textbrowsern (z.B. unter Linux)" ?

Du kannst ja nochmal hier im Archiv nachschauen, es ging wohl z.B. darum ob ein Verzicht auf Frames Vorteile bei Suchmaschinen haben kann.

Da es noframe-Ergänzungen gibt sollte dich eigentlich die nötige Zugänglichkeit nicht zwangsläufig an Frames hindern, Seiten mit Frames können sogar klarer strukturiert sein wenn die Navigation getrennt ist.

Interessant wäre aber was die Frames bei dir für Vorteile bringen sollen.

Grüsse

Cyx23

[Cheatah]

Hi,

Man liest immer, dass Frames nicht von allen Browsern dargestellt werden können bzw. nicht richtig. Aber ist die Aussage noch haltbar?

wieso beschränkst Du diese Frage nur auf Browser?

Cheatah

[Markus]

wieso beschränkst Du diese Frage nur auf Browser?

Cheatah

Weil ich die Seite nur für Browser schreibe? Für was soll ich sie noch schreiben? WAP?

MfG

[Cheatah]

Hi,

wieso beschränkst Du diese Frage nur auf Browser?
Weil ich die Seite nur für Browser schreibe? Für was soll ich sie noch schreiben? WAP?

nein, aber eine handvoll Leute meinen doch tatsächlich, sowas wie Suchmaschinen wäre auch gar nicht übel zu beachten. Oder um es deutlicher zu sagen:

Du schreibst Deine Seiten für _Clients_, nicht für die Untergruppe der (graphischen) Browser.

Cheatah

[Markus]

nein, aber eine handvoll Leute meinen doch tatsächlich, sowas wie Suchmaschinen wäre auch gar nicht übel zu beachten. Oder um es deutlicher zu sagen:

Du schreibst Deine Seiten für _Clients_, nicht für die Untergruppe der (graphischen) Browser.

Cheatah

Ach auf das wolltest Du raus! War mir nicht ganz klar. Dank dem Link von Gunnar bin ich inzwischen auch auf die Problematik gestossen. Danke!

MfG

[zoidberg]

Hi,

wieso beschränkst Du diese Frage nur auf Browser?

Cheatah

Weil ich die Seite nur für Browser schreibe? Für was soll ich sie noch schreiben? WAP?

Schade, besser wäre, dü würdest diene Seiten für Menschen schreiben, den denen ist es viel wichtiger als den Browsern, wie eine Seite aussieht. Für die Browser musst du "einfach" nur valides HTML schreiben, für die Menschen aber ... da musst du wirklich arbeiten, damit die Seite gut wird.

mfg - zoidberg

[Markus]

Schade, besser wäre, dü würdest diene Seiten für Menschen schreiben, den denen ist es viel wichtiger als den Browsern, wie eine Seite aussieht. Für die Browser musst du "einfach" nur valides HTML schreiben, für die Menschen aber ... da musst du wirklich arbeiten, damit die Seite gut wird.

mfg - zoidberg

Wir wollen mal nicht zu kleinlich sein oder? Ich dachte, dass es jedem normal denkenden Menschen klar sein sollte, dass am anderen Ende ein Mensch sitzt, der sich die Sache im Browser ansieht! Ein PC wird sich wohl nicht von alleine hochfahren und der Browser dann aus Langeweile mal selbstständig eine Seite aufrufen...

Und wie Du schon schreibst: Dem Menschen ist es wichtig, wie eine Seite aussieht. Also muss ich doch die Seite so schreiben, dass sie ein Browser optimal anzeigt. Sehe da keinen Widerspruch im Gegensatz zu Dir.

MfG

[zoidberg]

Hi,

Und wie Du schon schreibst: Dem Menschen ist es wichtig, wie eine Seite aussieht. Also muss ich doch die Seite so schreiben, dass sie ein Browser optimal anzeigt. Sehe da keinen Widerspruch im Gegensatz zu Dir.

Wiso, der Browser bracuh - wie gesagt - nur valides HTML. Das kann auch eine Seite mit 46 Frames, grünem Hintergrund und hellgrüner Schrift, 200 animierten gif's und sonstigen sperenzchen sein. Vorher natürlich noch 73 alert-Meldungen von JavaSript und so weiter. Ein guter Browser kann sowas optimal anzeigen, ein Mensch bekommt hingegen spontan Ausschlag auf den Augen.

Ok, ein "bisschen" kleinlich ist es schon gewesen, dennoch habe ich Recht, ;-)

mfg - zoidberg

P.S.: Nicht böse gemeint.

[Michael Jendryschik]

Hallo,

Ok, ein "bisschen" kleinlich ist es schon gewesen

Das denke ich gar nicht. Ich halte es für sehr wichtig, sich bewusst zu machen, dass es nicht um »den Browser« oder »die Suchmaschine« geht, sondern um den Nutzer, an den eine Website schließlich adressiert ist und der »den Browser« oder »die Suchmaschine« verwendet. Daraus ergeben sich ganz andere Aspekte. Usability steht dann schnell im Vordergrund und man denkt einige Schritte weiter.

Gruß,

MI

[Efchen]

Moin,

Mal abgesehen von den Textbrowsern (z.B. unter Linux)

Ich verstehe nicht, warum Du Textbrowser unbedingt mit Linux verbindest.  Der bekannteste (okay, der mir als einziger bekannte) Textbrowser, lynx, läuft sowohl unter Unix als auch unter Windows. Du stellst Linux gerade so hin, als wäre das ein rein textbasiertes System. Das stimmt weder für Linux, noch für alle anderen Unixe. Schon in den 80er Jahren gab es XWindows für Unix, ein derartiges Fenstersystem wurde nicht von Bill Gates erfunden! Der kann auch nur nachmachen...

Gruß,
-Efchen

[Markus]

Moin,

Mal abgesehen von den Textbrowsern (z.B. unter Linux)

Ich verstehe nicht, warum Du Textbrowser unbedingt mit Linux verbindest.  Der bekannteste (okay, der mir als einziger bekannte) Textbrowser, lynx, läuft sowohl unter Unix als auch unter Windows. Du stellst Linux gerade so hin, als wäre das ein rein textbasiertes System. Das stimmt weder für Linux, noch für alle anderen Unixe. Schon in den 80er Jahren gab es XWindows für Unix, ein derartiges Fenstersystem wurde nicht von Bill Gates erfunden! Der kann auch nur nachmachen...

Gruß,
-Efchen

Da ich selbst auch Linux nutze, erzählst Du mir nichts Neues! Aber ich kenne keinen Windows-Nutzer, der mit einem Textbrowser surft... Die meisten wissen nicht mal, was das ist, geschweige denn, dass es sowas gibt.
Alle die ich kenne, die einen Textbrowser verwenden, machen das unter Linux. Daher mein Bezug zu Linux.

MfG

[Efchen]

Moin,

Aber ich kenne keinen Windows-Nutzer, der mit einem Textbrowser surft...
Alle die ich kenne, die einen Textbrowser verwenden, machen das unter Linux. Daher mein Bezug zu Linux.

Es wirft nur so ein negatives Licht auf Unixe.

Schönes Wochenende,
-Efchen

[Michael Jendryschik]

Hallo,

Ich will in nächster Zeit meine Homepage überarbeiten. Nun stellt sich mir die "Frames-Frage"!

Die wurde hier schon Hunderte Male gestellt und beantwortet. Bitte verwende das Archiv, lies http://www.subotnik.net/html/frames.html und stelle dann ggf. konkrete Fragen zu dem einen odern anderen Punkt, bei dem du nachhaken möchtest.

Gruß,

MI