Frames durch CSS ersetzen

[Matthias]

Hallo!

Ich arbeite gerade daran, das alte, Frames- und Tabellenbasierte Layout meiner Website auf CSS umzustellen. Ich habe unter anderem http://de.selfhtml.org/css/layouts/fixbereiche.htm und http://de.selfhtml.org/css/layouts/mehrspaltige.htm gelesen, aber eine Sache ist mir nach wie vor unklar:

Der eigentliche Vorteil von Frames war für mich immer, dass ich das Navigationsmenü nur ein einziges Mal als HTML-Datei anlegen und pflegen musste. Bei allen CSS-Beispielen hingegen ist der Menütext immer im jeweiligen HTML-Dokument enthalten.. Muss ich das Menü wirklich in jede einzelne HTML-Datei einfügen, und bei einer Änderung (umbenennen oder hinzufügen eines Menüpunktes zum Beispiel), jede einzelne Datei anpassen?

Oder gibt es irgendeine Möglichkeit, per CSS (oder mit anderen adäquaten Mitteln, aber ohne cgi-Scripte) ein an EINER Stelle definiertes Menü einzubinden?

Vielen Dank für eure Hilfe!

Matthias

[Cheatah]

Hi,

Der eigentliche Vorteil von Frames war für mich immer, dass ich das Navigationsmenü nur ein einziges Mal als HTML-Datei anlegen und pflegen musste.

der daraus resultierende Nachteil ist, dass das Navigationsmenü in aller Regel nicht vorhanden ist, weil nur die wenigsten Besucher tatsächlich das Frameset sehen.

Bei allen CSS-Beispielen hingegen ist der Menütext immer im jeweiligen HTML-Dokument enthalten..

So, wie es sein muss.

Muss ich das Menü wirklich in jede einzelne HTML-Datei einfügen, und bei einer Änderung (umbenennen oder hinzufügen eines Menüpunktes zum Beispiel), jede einzelne Datei anpassen?

Nein. Beschäftige Dich mit serverseitigen Mechanismen.

Oder gibt es irgendeine Möglichkeit, per CSS (oder mit anderen adäquaten Mitteln, aber ohne cgi-Scripte) ein an EINER Stelle definiertes Menü einzubinden?

CSS beeinflusst nicht die Inhalte - diese werden per HTML transportiert. CGI ist _eine_ serverseitige Technik, aber längst nicht die einzige. Für Deine Zwecke dürfte SSI hinreichen.

Cheatah

[Klawischnigg]

Hi there,

der daraus resultierende Nachteil ist, dass das Navigationsmenü in aller Regel nicht vorhanden ist, weil nur die wenigsten Besucher tatsächlich das Frameset sehen.

Hää? Warum sollten sie das Frameset respektive die in ihm enthaltenen Seiten nicht sehen ???

[Ashura]

Hallo Klawischnigg.

der daraus resultierende Nachteil ist, dass das Navigationsmenü in aller Regel nicht vorhanden ist, weil nur die wenigsten Besucher tatsächlich das Frameset sehen.

Hää? Warum sollten sie das Frameset respektive die in ihm enthaltenen Seiten nicht sehen ???

Weil Google auch einzelne Frames indiziert.

Einen schönen Mittwoch noch.

Gruß, Ashura

[Klawischnigg]

Hi there,

Hää? Warum sollten sie das Frameset respektive die in ihm enthaltenen Seiten nicht sehen ???

Weil Google auch einzelne Frames indiziert.

Ja, tut er, ebenso wie man Frameset on the fly generieren kann. Und - um einem zu erwartendem Einwand zuvorzukommen: Lt. Statistik der Anbieter von Onlinemarketingsystemen haben 2% aller User javascript abgedreht. Ich konzidiere jetzt einmal ein gesteigertes Interesse dieser Anbieter, diesen Prozentsatz gut aussehen zu lassen. Dieses berücksichtigend, gepaart mit eigenen Beobachtungen würd ich sagen, sind es halt 5 Prozent. Und?

Ich meine, egal wie man zu frames stehen mag oder nicht, eine serverseitige Lösung ist einfach nicht in jedem Falle möglich. Ich denke einfach, die Behauptung, daß die meisten user eine Navigation, die in einem Frame untergebracht ist, nie zu Gesicht bekommen, ist einfach eine masslose Übertreibung. Doch selbst in den seltenen Fällen, in denen das tatsächlich der Fall ist muß der Umstand einer fehlenden Navigation nicht notwendigerweise einen Minderwert für den User bedeuten, schliesslich ist er ja direkt auf der Seite mit jenem Content gelandet, nach dem er über Google gesucht hat...

[frankx]

Hallo Klawischnigg,

vielleicht ist es ja eine Glaubensrichtung oder so, bei so recht emsigem Halbwahrheiten verbreiten.

vernünftige Grüße aus Berlin,

Frankx

[Struppi]

vielleicht ist es ja eine Glaubensrichtung oder so, bei so recht emsigem Halbwahrheiten verbreiten.

Damit meinst du:

a. Google zeigt auf den Ergebnissseiten nach einer Suche, den Link auf den kompletten evtuellen Frameset an und nach dem Klick landet der Suchende auf der Frameseite mit dem von ihm gewünschten Inhalt?

b. Die wenigsten User kommen über Google (oder andere Suchmaschinen) auf die Seite?

c. Die meisten Frameseiten benutzen ein intelligentes JS, um das Frameset nachzuladen?

d. Du hängst dem Glauben an Frames nach und möchtest Halbwahrheiten darüber verbreiten?

Struppi.

[frankx]

Hallo Struppi,

damit meine ich die von Klawitschnigg hinterfragte Äußerung Cheatahs:
"der daraus resultierende Nachteil ist, dass das Navigationsmenü in aller Regel nicht vorhanden ist, weil nur die wenigsten Besucher tatsächlich das Frameset sehen." sowie Gunnars vormals geäußerte Pauschal-Ansicht, Framesets seien "schwach" mit dem Hinweis auf subotnik, wo zumindest in Bezug auf Suchmaschinen der Sachverhalt allenfalls halbwahr dargestellt wird.

Nicht meinen tue ich damit zB. Ingo Turskis differnezierteren Äußerungen zu evtl. GooglePageRankSchwächen (durch die Schaffung einer weitern Ebene), seinen Hinweis auf die häufigeren HTTP-Requests sowie Nachteile in Bezug auf Barrierefreiheit. Und schon garnicht die Ansicht von SELFHTML dazu: "Durch den Einsatz von Frames wachsen die Gestaltungsmöglichkeiten außerordentlich. Frames stellen an das Design von HTML-Seiten aber auch besonders hohe Ansprüche und haben einige nicht zu bestreitende Nachteile. Einige Tips, die Sie beachten sollten, finden Sie im Abschnitt..." http://de.selfhtml.org/html/frames/definieren.htm.

unpauschalen und differenzierten Gruß, Frankx

[at]

Hallo.

Und schon garnicht die Ansicht von SELFHTML dazu: "Durch den Einsatz von Frames wachsen die Gestaltungsmöglichkeiten außerordentlich. Frames stellen an das Design von HTML-Seiten aber auch besonders hohe Ansprüche und haben einige nicht zu bestreitende Nachteile. Einige Tips, die Sie beachten sollten, finden Sie im Abschnitt..." http://de.selfhtml.org/html/frames/definieren.htm.

Inwiefern wachsen denn die "Gestaltungsmöglichkeiten"? In Bezug auf überlappenden Naviagtionselemente und eigebettete Objekte, geteilte Bildlaufleisten und nicht abzuschätzende Dimensionen der Frame-Inhalte kann ich nur gestalterische Nachteile erkennen. Den einzigen -- und damit noch nicht einmal einen Plural rechtfertigenden -- positiven Aspekt sehe ich in der Verschiebbarkeit der Frame-Grenze ohne den Einsatz von Skripten oder spezieller Browser-Erweiterungen.
MfG, at

[frankx]

Hallo at,

Inwiefern wachsen denn die "Gestaltungsmöglichkeiten"?

War ja nur ein Zitat aus SELFHTML, da wohl am besten Stefan Münz oder wen auch immer fragen.

"Verschiebbarkeit der Frame-Grenze ohne den Einsatz von Skripten oder spezieller Browser-Erweiterungen...". Das verstehe ich nicht ganz.

Meinst Du von Nutzerseite oder von Programmiererseite?

Für mich liegt der Vorteil nach wie vor in der zugegeben Bildschirmgrößen festgelegten einfachen Möglichkeit der Bildschirm-Aufteilung, sowie der Möglichkeit, beliebige Bildschirmbereiche festzuschreiben (position fixed kennt ja der IE leider nicht, und der Workarround von Dennis Riehle erreicht mit nicht unerheblicher CSS-Logik nicht wirklich das, was Frames ganz simpel können: Titel, Navilinks, Newsrechts,Fussbereich, Content-in-der-Mitte und Navi, News, Content unabhängig scrollbar bzw. nach bedarf). Und für nur-HTMLer (Anfänger), die Möglichkeit, öfter zu änderende Seitenteile (Navi, News) zu "includen".

Gruß, Frankx

[at]

Hallo.

Inwiefern wachsen denn die "Gestaltungsmöglichkeiten"?

War ja nur ein Zitat aus SELFHTML, da wohl am besten Stefan Münz oder wen auch immer fragen.

Naja, innerhalb deines kritischen und differenzierten Beitrags wäre eine inhaltliche AUseinandersetzung mit dem Zitat aber wohl angebracht gewesen. Ansonsten ruft man in diesem Zusammenhang eben die Wirkung einer Zustimmung hervor.

"Verschiebbarkeit der Frame-Grenze ohne den Einsatz von Skripten oder spezieller Browser-Erweiterungen...". Das verstehe ich nicht ganz.

Meinst Du von Nutzerseite oder von Programmiererseite?

Von Nutzerseite -- wenn es von Autorenseite nicht anderweitig definiert wird. Diese Möglichkeit der freien Einteilung erlaubt mir CSS allein jedenfalls nicht.

Für mich liegt der Vorteil nach wie vor in der zugegeben Bildschirmgrößen festgelegten einfachen Möglichkeit der Bildschirm-Aufteilung, sowie der Möglichkeit, beliebige Bildschirmbereiche festzuschreiben (position fixed kennt ja der IE leider nicht, und der Workarround von Dennis Riehle erreicht mit nicht unerheblicher CSS-Logik nicht wirklich das, was Frames ganz simpel können: Titel, Navilinks, Newsrechts,Fussbereich, Content-in-der-Mitte und Navi, News, Content unabhängig scrollbar bzw. nach bedarf).

Abgesehen vom hier ja hinreichend häufig diskutierten Sinn und Unsinn solcher Einsatzmöglichkeiten kann die genannten Schwierigkeiten nicht nachvollziehen. Und nicht unerheblich ist der Aufwand von Nachlade-Skripten, unterschiedlichen Framesets etc. ja ebenfalls. Wer den Aufwand scheut, muss eben auf den Effekt verzichten, zumindest im IE.

Und für nur-HTMLer (Anfänger), die Möglichkeit, öfter zu änderende Seitenteile (Navi, News) zu "includen".

Hätte es Frames niemals gegeben, hätten die Anfänder sie niemals vermisst stattdessen gleich SSI etc. eingesetzt -- oder eben Kopieren/Einfügen bemüht. Wie Layout-Tabellen auch gehören Frames eben zu den "Geistern, die ich rief".
MfG, at

[frankx]

Hallo at,

Naja, innerhalb deines kritischen und differenzierten Beitrags wäre eine inhaltliche AUseinandersetzung mit dem Zitat aber wohl angebracht gewesen. Ansonsten ruft man in diesem Zusammenhang eben die Wirkung einer Zustimmung hervor.

Das sehe ich auch so. Meine Zustimmung ist geteilt, die gestalterischen Möglichkeiten sind ja irgendwie vorhanden. Zustimmung findet aber auch der Respekt vor SELFHTML und einer etwas "emotionslosen" Darstellung.

Von Nutzerseite -- wenn es von Autorenseite nicht anderweitig definiert wird. Diese Möglichkeit der freien Einteilung erlaubt mir CSS allein jedenfalls nicht.

Magst Du das noch etwas erläutern. Die Framegrenzen kann ich als Nutzer doch ohne Skript grade nicht verschieben, oder hab ich das eine Wissenslücke?

Abgesehen vom hier ja hinreichend häufig diskutierten Sinn und Unsinn solcher Einsatzmöglichkeiten

klar, Viewport/AusgabeMedium und Barriere, sind im allg. ja auch schlagende Argumente.

kann die genannten Schwierigkeiten nicht nachvollziehen.

Mmh, ich habe mich durch Dennis Rieles Skript mal versucht durchzuarbeiten. Wie ich einen inneren Div scrollbar (und zwar nur im div selbst) umgeben von 4 äußeren herstellen kann, war für mich Fazit: gehtnicht. Lasse mir da gerne auf die Sprünge helfen.

Hätte es Frames niemals gegeben, hätten die Anfänder sie niemals vermisst stattdessen gleich SSI etc. eingesetzt -- oder eben Kopieren/Einfügen bemüht. Wie Layout-Tabellen auch gehören Frames eben zu den "Geistern, die ich rief".

Naja, das stimmt zwar, aber wenn es Internet nicht gäbe, dann säßen wir jetzt beim Bier am Kneipentisch oder eben nicht (;-); und html grundsäztlich die Möglichkeit zum "includen" zu geben, warum nicht?

Dank und Gruß, Frankx

[at]

Hallo.

Meine Zustimmung ist geteilt, die gestalterischen Möglichkeiten sind ja irgendwie vorhanden.

Aber eben nur in einem Umfang, der weit unterhalb der eigentlich zur Gestaltung gedachten Techniken liegt.

Zustimmung findet aber auch der Respekt vor SELFHTML und einer etwas "emotionslosen" Darstellung.

Yep. Das betrifft allerdings fast jeden Bereich von SelfHTML. Bei einer Schritt-für-Schritt-Anleitung wäre das kaum der Motivation förderlich, aber für eine Nachschlagewerk halte ich das für sehr angebracht.

Die Framegrenzen kann ich als Nutzer doch ohne Skript grade nicht verschieben, oder hab ich das eine Wissenslücke?

Vermutlich.

Mmh, ich habe mich durch Dennis Rieles Skript mal versucht durchzuarbeiten. Wie ich einen inneren Div scrollbar (und zwar nur im div selbst) umgeben von 4 äußeren herstellen kann, war für mich Fazit: gehtnicht. Lasse mir da gerne auf die Sprünge helfen.

Wenn das Layout so kompliziert ist -- was häufig genug nicht notwendig ist, aber das ist ein anderes Thema --, würde ich mit den Überlauffunktionen für den beweglichen Inhalt und fester Positionierung für die übrigen Bereiche arbeiten.

Hätte es Frames niemals gegeben, hätten die Anfänder sie niemals vermisst stattdessen gleich SSI etc. eingesetzt -- oder eben Kopieren/Einfügen bemüht. Wie Layout-Tabellen auch gehören Frames eben zu den "Geistern, die ich rief".

Naja, das stimmt zwar, aber wenn es Internet nicht gäbe, dann säßen wir jetzt beim Bier am Kneipentisch oder eben nicht (;-);

Auch kein schlechter Gedanke.

und html grundsäztlich die Möglichkeit zum "includen" zu geben, warum nicht?

Sicher, die gibt es ja auch anderweitig: <object> und <img> machen ja genau das -- naja, sie referenzieren natürlich nur, aber mehr tun Frames ja auch nicht. Daher vermutlich auch deine Anführungenszeichen. Aber bei all diesen Techniken geht ja nicht in erster Linie darum, dem unerfahrenen Autoren ein möglichst einfach zu handhabendes Werkzeug für das Einbinden wiederkehrender Inhalte zur Verfügung zu stellen, sondern darum, externe Inhalte in das Dokument aufzunehmen und in dessen sematischen Kontext auszuzeichnen. Wem das zu kompliziert ist, sollte einen Editor verwenden, der seine "Includes" verwaltet oder auf deine Idee mit dem Bier zurückkommen.
MfG, at

[frankx]

Hallo at

Vermutlich.

Sehr Dank. <bierausgeb=yes> Da bringst du mich ja gleich auf schlimme Gedanken. Damit ist das HardewareInkompatibelArgument ja eingentlich vom Tisch, weil das erleichter doch alles enorm. Kann ich die Newsleiste wegschieben, wenn sie mich nicht interessiert, die Titelgrafik oben auch, wenn mein MiniPC so miniklein ist.

Wenn das Layout so kompliziert ist -- was häufig genug nicht notwendig ist, aber das ist ein anderes Thema --,

na, ich weiß schon, aber: TitelGrafik oben fixed, ImpressumUnten fixed, NaviRechts, NewsLinks, ContentmitvielPlatzinnneMitte ist doch eigentlich ganz simpel?

Dank und Gruß,

Frankx

[at]

Hallo.

Sehr Dank.

Geschehen gern.

<bierausgeb=yes> Da bringst du mich ja gleich auf schlimme Gedanken.

Macht nix, in der Kneipe ist mir das sowas von egal.

Damit ist das HardewareInkompatibelArgument ja eingentlich vom Tisch, weil das erleichter doch alles enorm. Kann ich die Newsleiste wegschieben, wenn sie mich nicht interessiert, die Titelgrafik oben auch, wenn mein MiniPC so miniklein ist.

Das ist aber doch das Dilemma. Denn entweder die Inhalte lassen sich wegschieben, weil der Autor dies nicht einschränkt und damit zugibt, dass sie zumindest zeitweilig entbehrlich sind, oder er beschränkt diese Funktion, weil er die Inhalte permanent anzeigen zu müssen meint. In ersterem Fall könnte er also auf Frames verzichten, da bei normaler Darstellung ebenso zeitweilig auf diese Inhalte verzichtet werden muss, nämlich wenn sie aus dem Viewport ragen, während er andernfalls das Problem nicht entschärft. Die Schwierigkeit ist und bleibt eben keine technische, sondern eine der Selbstbeschränkung des Autors.

Wenn das Layout so kompliziert ist -- was häufig genug nicht notwendig ist, aber das ist ein anderes Thema --,

na, ich weiß schon, aber: TitelGrafik oben fixed, ImpressumUnten fixed, NaviRechts, NewsLinks, ContentmitvielPlatzinnneMitte ist doch eigentlich ganz simpel?

Simpel nicht, aber leider üblich. Mir persönlich ist das schon deutlich zuviel. Und weshalb ausgerechnet die Titelgrafik und die Fußzeile fixiert werden sollen, kann ich nicht nachvollziehen, denn auf die kann ich doch am ehesten verzichten. Mit Frames hätte man darüber hinaus natürlich die Schwierigkeit, das Impressum auch für Geräte oder Programme ohne Unterstützung für Frames dennoch von überall aus zugänglich zu machen, weshalb der Ansatz, hier stattdessen CSS einzusetzen, natürlich sehr sinnvoll ist.
MfG, at

[scherzkeks]

Hallo,

Damit ist das HardewareInkompatibelArgument ja eingentlich vom Tisch, weil das erleichter doch alles enorm. Kann ich die Newsleiste wegschieben, wenn sie mich nicht interessiert, die Titelgrafik oben auch, wenn mein MiniPC so miniklein ist.

[...]und damit zugibt, dass sie zumindest zeitweilig entbehrlich sind

Naja....
Das würde ich nicht so sagen!
Ich weiß nicht, ob ich mir dabei wirklich soviel denken würde geschweige denn ausdrücken wollen oder müssen würde, mein Inhalt, oder der in den Frames sei unwichtig oder entbehrlich!

Wenn das Layout so kompliziert ist -- was häufig genug nicht notwendig ist, aber das ist ein anderes Thema --,

na, ich weiß schon, aber: TitelGrafik oben fixed, ImpressumUnten fixed, NaviRechts, NewsLinks, ContentmitvielPlatzinnneMitte ist doch eigentlich ganz simpel?

Simpel nicht,

Find ich schon!
5 Teile, dsvon 4 "Ränder" und "1 Mitte".
Noch etwas zur einbindung: SelfHTML stellt ja auch eine Möglichkeit von Datenanbindung von Microsoft vor.
Diese und die Möglichkeiten mit object und img stellen für mich aber keinen Vorteil gegenüber Frames dar.

MfG, at

FG zurück und schönen Freitagnachmittag noch,
scherzkeks

[at]

Hallo.

Das würde ich nicht so sagen!

Eben, deshalb habe ich es ja gesagt.

Ich weiß nicht, ob ich mir dabei wirklich soviel denken würde geschweige denn ausdrücken wollen oder müssen würde, mein Inhalt, oder der in den Frames sei unwichtig oder entbehrlich!

Dass insbesondere der Einsatz von Frames zu einem guten Teil auf Gedankenlosigkeit zurückzuführen ist, ist dem Archiv ja bestens bekannt.

na, ich weiß schon, aber: TitelGrafik oben fixed, ImpressumUnten fixed, NaviRechts, NewsLinks, ContentmitvielPlatzinnneMitte ist doch eigentlich ganz simpel?

Simpel nicht,
Find ich schon!
5 Teile, dsvon 4 "Ränder" und "1 Mitte".

Die "Ränder" transportieren aber Inhalte und tragen damit zur Überfrachtung der Seite bei.

Noch etwas zur einbindung: SelfHTML stellt ja auch eine Möglichkeit von Datenanbindung von Microsoft vor.
Diese und die Möglichkeiten mit object und img stellen für mich aber keinen Vorteil gegenüber Frames dar.

Kein Problem, die überragende Mehrzahl der Autoren sieht das ja glücklicherweise anders und bindet etwa Bilder nicht in Form von iFrames ein.

MfG, at
FG zurück

Wie, "zurück"? Unverschämtheit!
MfG, at

[scherzkeks]

Hallo.

Das würde ich nicht so sagen!

Eben, deshalb habe ich es ja gesagt.

Gut so!

Ich weiß nicht, ob ich mir dabei wirklich soviel denken würde geschweige denn ausdrücken wollen oder müssen würde, mein Inhalt, oder der in den Frames sei unwichtig oder entbehrlich!

Dass insbesondere der Einsatz von Frames zu einem guten Teil auf Gedankenlosigkeit zurückzuführen ist, ist dem Archiv ja bestens bekannt.

na, ich weiß schon, aber: TitelGrafik oben fixed, ImpressumUnten fixed, NaviRechts, NewsLinks, ContentmitvielPlatzinnneMitte ist doch eigentlich ganz simpel?

Simpel nicht,
Find ich schon!
5 Teile, dsvon 4 "Ränder" und "1 Mitte".

Die "Ränder" transportieren aber Inhalte und tragen damit zur Überfrachtung der Seite bei.

Ich glaube, wir verstehen nicht das selbe unter "simpel".
Ich meine damit, es ist nicht kompliziert zu verstehen, bzw. das Konzept oder die Idee ist simpel. Von Umsetzung oder gar Menge von transportierten Daten oder allgemein der Durchführung in der Praxis wollte ich gar nicht reden.

Noch etwas zur einbindung: SelfHTML stellt ja auch eine Möglichkeit von Datenanbindung von Microsoft vor.
Diese und die Möglichkeiten mit object und img stellen für mich aber keinen Vorteil gegenüber Frames dar.

Kein Problem, die überragende Mehrzahl der Autoren sieht das ja glücklicherweise anders und bindet etwa Bilder nicht in Form von iFrames ein.

Du verstehst mich falsch!
Ich sehe keine kleinere Barriere darin HTML-Seiten mit object, img, oder der Datenanbindung "von Microsoft" zu "includen", wie hier ja schon so schön gesagt wurde, als darin, Frames zu benutzen. Ich finde Frames auch nicht gut oder toll, wenn auch trotzdem oft praktisch, deshalb finde ich das einbinden mit object anstatt iframe kein bisschen besser oder klüger, da es auch sicherlich von weniger Browsern unterstützt wird.
So wie es auch schon frankx aufgefallen ist.

MfG, at
FG zurück

Wie, "zurück"? Unverschämtheit!

Kriegst sogar noch einen eigenen von mir dazu: schönen Samstagvor(- und nach)mittag noch,
scherzkeks

MfG, at

scho wieder?
Gleich wieder zurück!
:P

[at]

Hallo.

5 Teile, dsvon 4 "Ränder" und "1 Mitte".

Die "Ränder" transportieren aber Inhalte und tragen damit zur Überfrachtung der Seite bei.
Ich glaube, wir verstehen nicht das selbe unter "simpel".
Ich meine damit, es ist nicht kompliziert zu verstehen, bzw. das Konzept oder die Idee ist simpel. Von Umsetzung oder gar Menge von transportierten Daten oder allgemein der Durchführung in der Praxis wollte ich gar nicht reden.

Diese Dinge hängen ja zusammen. Denn gäbe es die Inhalte nicht, wären die Frames vollkommen überflüssig und könnten mittels CSS als Ränder definiert werden. Dass der Inhalt auch ohne Frames zur visuellen Überfrachtung beiträgt, ist ja eine andere Frage.

Ich sehe keine kleinere Barriere darin HTML-Seiten mit object, img, oder der Datenanbindung "von Microsoft" zu "includen", wie hier ja schon so schön gesagt wurde, als darin, Frames zu benutzen.

Dem stimme ich gern zu.
MfG, at

[Matthias]

Auch Dir nochmal danke. Aber was nehme ich nun, <a href="http://www.w3.org/TR/WCAG10-HTML-TECHS/#alt-frames> Object-Tags </a> oder SSI? Gibt es irgendwelche Vor- und Nachteile? Was wird von mehr Browsern verstanden?

[Ashura]

Hallo Matthias.

Auch Dir nochmal danke. Aber was nehme ich nun, Object-Tags oder SSI? Gibt es irgendwelche Vor- und Nachteile? Was wird von mehr Browsern verstanden?

Du vermischt hier zwei Techniken, die auf völlig verschiedenen Seiten ablaufen.
Das object-Element ist eine Möglichkeit, externe Ressourcen in HTML-Dokumente einzubinden, jegliche Aktionen sind hierbei also auf die Clientseite beschränkt.

http://de.selfhtml.org/servercgi/server/ssi.htm@title=SSI dagegen ist eine serverseitige Technik, Dokumente einzubinden und andere Informationen zu (S)HTML-Dokumenten zusammenzufassen.
SSI ist damit von jeglichem Client unabhängig gleich verfügbar, die Umsetzung geschieht auf der Serverseite.

Einen schönen Samstag noch.

Gruß, Ashura

[Matthias]

Du vermischt hier zwei Techniken, die auf völlig verschiedenen Seiten ablaufen.
Das object-Element ist eine Möglichkeit, externe Ressourcen in HTML-Dokumente einzubinden, jegliche Aktionen sind hierbei also auf die Clientseite beschränkt.

http://de.selfhtml.org/servercgi/server/ssi.htm@title=SSI dagegen ist eine serverseitige Technik, Dokumente einzubinden und andere Informationen zu (S)HTML-Dokumenten zusammenzufassen.
SSI ist damit von jeglichem Client unabhängig gleich verfügbar, die Umsetzung geschieht auf der Serverseite.

Mir ist schon klar, dass es sich um zwei unterschiedliche Techniken handelt. Aber beide führen zu meinem Ziel: Ich kann meine Navigation in einer einzelnen Datei definieren, und dann in alle Dokumente einbinden. Wenn ich mir (z.B.) irgendwann ein Forum zulege, dann muss ich diesen neuen Link nur an einer einzigen Stelle eintragen.

So weit, so gut. Welche der beiden Techniken nutze ich nun, um mein Ziel zu erreichen? SSI habe ich mitlerweile probiert, klappt prima, und hat als serverseitige Technik sicher den Vorteil, dass es vom Client nicht unterstützt werden muss... der kriegt ja davon garnichts mit. Wie sieht es mit dem object-tag aus? Wird das von allen gängigen, (auch älteren) Browsern unterstützt? Kommen auch Textbrowser damit zurecht? Screenreader? Hat es vielleicht (zur Einbindung eines externen Dokumentes) andere Vor- oder Nachteile gegenüber der Verwendung von SSI, die man kennen sollte? Das war es, worauf meine Frage zielte.

[MudGuard]

Hi,

So weit, so gut. Welche der beiden Techniken nutze ich nun, um mein Ziel zu erreichen? SSI habe ich mitlerweile probiert, klappt prima, und hat als serverseitige Technik sicher den Vorteil, dass es vom Client nicht unterstützt werden muss...

Das reicht doch als Vorteil schon aus.

Solange Du nicht auf clientseitige Technologie angewiesen bist, ist das viel besser.
Denn Du weißt nie, was der Client tatsächlich unterstützt.

Wie sieht es mit dem object-tag aus? Wird das von allen gängigen, (auch älteren) Browsern unterstützt?

Vermutlich nicht.

Kommen auch Textbrowser damit zurecht? Screenreader?

Vermutlich nicht alle.

Suchmaschinenrobots vermutlich auch nicht alle ==> evtl. kommen die Besucher gar nicht erst, weil die Suchmaschine die Seiten nicht findet ...

Hat es vielleicht (zur Einbindung eines externen Dokumentes) andere Vor- oder Nachteile gegenüber der Verwendung von SSI, die man kennen sollte? Das war es, worauf meine Frage zielte.

Das Caching-Verhalten ist etwas anders, da bei object die Navigation als eigene Ressource vorliegt, also auch getrennt vom eigentlichen Dokument gecached werden kann.
cu,
Andreas

[Matthias]

ok, ich betrachte mein Problem damit als gelöst. Nochmal vielen Dank an alle, die sich zum Thema geäussert haben.

[Ingo Turski]

Hi,

Wie sieht es mit dem object-tag aus? Wird das von allen gängigen, (auch älteren) Browsern unterstützt?

Vermutlich nicht.

Ich habe bei meiner Hommingberger Gepardenforelle eine HTML-Seite (unten links) so eingebunden und sie wird im IE6 leider nicht angezeigt. Falls jemand eine funktionierende Möglichkeit kennt... Grundsätzlich kann der IE6 ja object nutzen, so daß z.B. auch das Beispiel http://de.selfhtml.org/html/multimedia/anzeige/object_border.htm funktioniert, wenn ActiveX (warum auch immer) zugelassen wird. Bei type="text/html" streikt er jedenfalls. :-(

Suchmaschinenrobots vermutlich auch nicht alle ==> evtl. kommen die Besucher gar nicht erst, weil die Suchmaschine die Seiten nicht findet ...

Wen's interessiert: Google hat die über object eingebundene Seite nicht angefordert, weshalb ich einen normalen HTML-Link hierauf setzen mußte.

freundliche Grüße
Ingo

[Ashura]

Hallo Matthias.

So weit, so gut. Welche der beiden Techniken nutze ich nun, um mein Ziel zu erreichen? SSI habe ich mitlerweile probiert, klappt prima, und hat als serverseitige Technik sicher den Vorteil, dass es vom Client nicht unterstützt werden muss...

Ein Client kann auch kein SSI umsetzen, für ihn sind dies ganz normale Kommentare im Dokument.

Wie sieht es mit dem object-tag aus? Wird das von allen gängigen, (auch älteren) Browsern unterstützt? Kommen auch Textbrowser damit zurecht? Screenreader? Hat es vielleicht (zur Einbindung eines externen Dokumentes) andere Vor- oder Nachteile gegenüber der Verwendung von SSI, die man kennen sollte? Das war es, worauf meine Frage zielte.

Ich persönlich habe bisher keine guten Erfahrungen mit dem object-Element gemacht, die Unterstützung ist teilweise eher mangelhaft bis nicht funktionstüchtig.
Meiner Meinung nach stellt der Einsatz des object-Elementes eine potentielle Barriere dar, welche du mit SSI gar nicht erst entstehen lässt.

Ich rate dir daher in jedem Fall zu SSI.

Einen schönen Sonntag noch.

Gruß, Ashura

[frankx]

Hallo Matthias,

meine Vermutung ist auch, dass das einbinden von html-seiten über object die selbe "Barriere" aufbauen müsste, wie ein Frameset, denn die Funktionsweise ist ja ident, in einem Browserfenster sind die Inhalte nicht mehr Zusammenhängen, sondern auf zwei "Ebenen" verteilt.

Gruß, Frankx

[MudGuard]

Hi,

meine Vermutung ist auch, dass das einbinden von html-seiten über object die selbe "Barriere" aufbauen müsste, wie ein Frameset,

m.E. dürfte die Barriere noch höher sein, denn object wird vermutlich von noch weniger Clients unterstützt als Frames.

cu,
Andreas

[Gunnar Bittersmann]

Oder gibt es irgendeine Möglichkeit, per CSS (oder mit anderen adäquaten Mitteln, aber ohne cgi-Scripte) ein an EINER Stelle definiertes Menü einzubinden?

Matthias,
Nein, nicht mit CSS.

Aber mit serverseitigen Techniken wie Server Side Includes oder PHP.

Live long and prosper,
Gunnar

[Matthias]

Matthias,
Nein, nicht mit CSS.

Aber mit serverseitigen Techniken wie Server Side Includes oder PHP.

Auch nicht übel. Danke! Aber was ist nun besser: object-tags (http://www.w3.org/TR/WCAG10-HTML-TECHS/#alt-frames), oder SSI?
Bzw. was sind die Vor- und Nachteile?

[frankx]

Hallo Matthias,

W3C hält das object-tag für die entsprechende alternative:

http://www.w3.org/TR/WCAG10-HTML-TECHS/#alt-frames. Aber mindestens das musste dann auf jeder Seite einbauen.

Warum willste denn umstellen ((;-) au, jetz gibts Kloppe...)?

Gruß, Frankx

[Matthias]

Hallo Matthias,

W3C hält das object-tag für die entsprechende alternative:

http://www.w3.org/TR/WCAG10-HTML-TECHS/#alt-frames. Aber mindestens das musste dann auf jeder Seite einbauen.

Warum willste denn umstellen ((;-) au, jetz gibts Kloppe...)?

Gruß, Frankx

Das sieht sehr vielversprechend aus, Danke! Werd ich gleich mal probieren...
Warum ich umstellen will? Weil ich bis jetzt ein Frameset voller Tabellen hatte :-P Ausserdem aus Spass an der Freud.