nicht angemeldet
mehrspaltig so korrekt?
0
mehrspaltig so korrekt?
Hellihello
das Thema kommt immer wieder, ich weiß, ich hab auch immer wieder was dazu gelesen. Kurze Frage deshalb, ob drei Spalten, die im IE, FF und Opera ganz gut so aussehen, so korrekt per CSS eingerichtet sind. HTML-syntaktisch sollte es wohl o.k. sein, oder?
im Netz
css:
body{
background-color:red;
overflow:hidden;
}
#menue, #inhalt, #rechts {
position:absolute;
top:0px;
overflow:auto;
height:100%;
padding:0em 0.5em;
}
#menue {
background-color:yellow;
left:0px;
height:100%;
width:10em;
}
#inhalt {
background-color:blue;
position:absolute;
left:11em;
right:11em;
}
#rechts {
background-color:green;
position:absolute;
top:0px;
right:0px;
width:10em;
}
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>mehrspaltiges Layout</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" type="text/css" href="mehrspaltiges_layout.css">
</head>
<body>
<div id="inhalt">
<h1>Inhalt</h1>
asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf etc.pp. </div>
<div id="menue">
<h3>Menüliste</h3>
<ul>
<li>Listeneintrag</li>
<li>etc. pp.</li>
</ul>
</div>
<div id="rechts">
<h3>Rechts</h3>
<h4>Überschrift Grad 4</h4>
<p> Absatz Absatz Absatz Absatz Absatz Absatz Absatz Absatz Absatz Absatz Absatz Absatz</p>
<p> etc. pp</p>
</div>
</body>
</html>
Nicht kapieren tu ich, warum es ohne "position:relative" im body geht, ich hatte gedacht, dass die absolute Positionierung nur funktioniert, wenn ein Elternelement relative oder absolut positioniert sei.
Dank und Gruß,
frankx
-
Hi,
ob drei Spalten, die im IE, FF und Opera ganz gut so aussehen, so korrekt per CSS eingerichtet sind.
Kurze Antwort: Nein.
Etwas ausführlicher:
Overflow-Bereiche dieser Art sind unschön.
Absolute Positionierung ist in diesem Fall zwar nicht problematisch, aber ich sehe auch aum eine sinnvolle Anwendung für ein solches Layout mit zwei seiteninternen Scrollbalken.height:100%;
das funktioniert nur dann zuverläsig, wenn auch alle Elternelemente eine definierte Höhe haben.
<h1>Inhalt</h1>
asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf etc.pp. </div>
<div id="menue">
<h3>Menüliste</h3>dazwischen fehlt eine h2. Überschriften haben nicht umsonst eine _logische_ Ordnungsnummerierung. Lass das also eine h2 sein.
freundliche Grüße
Ingo-
Hellihello Ingo,
Etwas ausführlicher:
Overflow-Bereiche dieser Art sind unschön.Ich weiß, die meisten Seiten haben nur eine Scrollbar, auch wenn sie dreigeteilt sind. Links Menü u.ä. zB., mitte dann Inhalt, rechts dann weitere Infos, News, sonstwas. Ich persönlich mag es nicht so, wenn ich im Menü scrollen will, der Inhalt aber mitscrollt oder umgekehrt, dass Menü dann weg ist, wenn die Seite (Inhalt) länger ist als der Bildschirm. Da mag ich aber wohl zur Minderheit der "User" gehören.
Absolute Positionierung ist in diesem Fall zwar nicht problematisch, aber ich sehe auch aum eine sinnvolle Anwendung für ein solches Layout mit zwei seiteninternen Scrollbalken.
Sorry, "drei" seiteninternen Scrollbalken, oder? (;-).
height:100%;
das funktioniert nur dann zuverläsig, wenn auch alle Elternelemente eine definierte Höhe haben.Aha, danke, dann sind die neuesten Versionen der genannten Browser da wohl eher tolerant. Gut zu wissen.
<h1>Inhalt</h1>
asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf etc.pp. </div>
<div id="menue">
<h3>Menüliste</h3>
dazwischen fehlt eine h2. Überschriften haben nicht umsonst eine _logische_ Ordnungsnummerierung. Lass das also eine h2 sein.Auch ein feiner Tipp, leuchtet ein. Wie schaut es dann mit den weiteren Überschriften im Inhalt aus. Da auch erst zweiter Ordnung vermutlich. Also Inhalt_Abschnitt1/2/3 wären dann gleicher Ordnung wie Menü und News?
Dank und Gruß,
frankx
-
Hi,
Ich persönlich mag es nicht so, wenn ich im Menü scrollen will, der Inhalt aber mitscrollt oder umgekehrt, dass Menü dann weg ist, wenn die Seite (Inhalt) länger ist als der Bildschirm. Da mag ich aber wohl zur Minderheit der "User" gehören.
Du nutzt sicherlich auch keinen Firefox 1.0.x, in dem das Scrollrad bei Overflow-Bereichen versagt. ;-)
Sorry, "drei" seiteninternen Scrollbalken, oder? (;-).
oops, ich hatte den rechten als normalen angesehen.
Wie schaut es dann mit den weiteren Überschriften im Inhalt aus. Da auch erst zweiter Ordnung vermutlich. Also Inhalt_Abschnitt1/2/3 wären dann gleicher Ordnung wie Menü und News?
das entscheidest Du bzw. der Inhalt. Es sollte halt nur _logisch_ sein, was insb. beinhaltet, dass in der Anordnung im Quelltext kein "Grad" fehlen darf. Dieses Problem hatte ich z.B. hier auch und konnte "Info-Box" nicht als Überschrift auszeichnen.
freundliche Grüße
Ingo-
Hellihello Ingo,
Ich persönlich mag es nicht so, wenn ich im Menü scrollen will, der Inhalt aber mitscrollt oder umgekehrt, dass Menü dann weg ist, wenn die Seite (Inhalt) länger ist als der Bildschirm. Da mag ich aber wohl zur Minderheit der "User" gehören.
Du nutzt sicherlich auch keinen Firefox 1.0.x, in dem das Scrollrad bei Overflow-Bereichen versagt. ;-)Nein, aber hier denke ich mittlerweile - mit verlaub und ohne diskreditierlich sein zu wollen - dass es jedem Nutzer überlassen bleibt, wie alt seine Technologie ist. Als ich letzlich per Netinstall auf einem Uraltrechner debian installierte, war FF 1.5 gleich mit dabei.
das entscheidest Du bzw. der Inhalt. Es sollte halt nur _logisch_ sein, was insb. beinhaltet, dass in der Anordnung im Quelltext kein "Grad" fehlen darf. Dieses Problem hatte ich z.B. hier auch und konnte "Info-Box" nicht als Überschrift auszeichnen.
Nur mal ganz allgemein-syntaktisch: Diese Infobox wie auch das Menü wären bei einem Buch oder ähnlichem vielleicht vergleichbar mit einem ausklappbaren Inhaltsverzeichnis oder einem allgmeinen Glossar oder sowas. Ich möchte hier nicht die altbekannten Argumente bezüglich Barrierefreiheit austauschen sondern lediglich meinen Gedanken bezüglich Syntax mitteilen: wären (!) es drei Frames, machte es aus meiner Sicht syntaktisch aus zweierlei Hinsicht Sinn - zum einen, wie beim Buchbeispiel- da es wirklich der inhaltlich komplett abgegrenzte Bereiche sind, und zum zweiten, folgt dann wohl aus erstem, könnten sie dann auch unabhängige Überschriftsordnungen haben. Denn die "Inhaltsangabe" (Menü) steht ja ordnungstechnisch eher auf der selben Ebene wie das 1.Kapitel, oder die Einleitung, oder auch das Glossar, oder? Auch eine "Newsseite" oder "Newsspalte" dürfte ja eigentlich mit <h1>Neues</h1> und <h2>1. Neugikeit</h2> <h2>2. Neuigkeit</h2> ausgezeichnet sein.
Was ich mich in dem Zusammenhang manchmal fragte ist warum denn die Abschnitte nicht quasi kennzeichnungspflichtig sind. Dafür wären dann wohl die divs zuständig, um zu kennzeichen, das jetzt die Absätze nicht mehr zur 1. Neuigkeit gehören sondern die 2. Neuigkeit anfängt.
Dank und Gruß,
frankx
-
Hi,
Du nutzt sicherlich auch keinen Firefox 1.0.x, in dem das Scrollrad bei Overflow-Bereichen versagt. ;-)
Nein, aber hier denke ich mittlerweile - mit verlaub und ohne diskreditierlich sein zu wollen - dass es jedem Nutzer überlassen bleibt, wie alt seine Technologie ist. Als ich letzlich per Netinstall auf einem Uraltrechner debian installierte, war FF 1.5 gleich mit dabei.
Ich habe gerade mal meine Statistik für Januar 2007 erstellt. Demnach nutzen von 15436 Firefox-Usern noch 11417 (wie ich) eine Version vor 1.5. Insgesamt waren das fast 29% meiner Besucher. Hätte ich scrollbare Bereiche, dann wären also fast 1/3 meiner Besucher verärgert. Firefox-User sind wirklich nicht so update-freudig wie z.B. Opera-User. Checke doch mal Deine Logs...
Zu den Überschriften:
wären (!) es drei Frames, machte es aus meiner Sicht syntaktisch aus zweierlei Hinsicht Sinn - zum einen, wie beim Buchbeispiel- da es wirklich der inhaltlich komplett abgegrenzte Bereiche sind, und zum zweiten, folgt dann wohl aus erstem, könnten sie dann auch unabhängige Überschriftsordnungen haben.
Ja. Frames sind eigenständige Seiten und verhindern damit auch eine wirklich sinnvolle Nutzung der Überschriften.
Was ich mich in dem Zusammenhang manchmal fragte ist warum denn die Abschnitte nicht quasi kennzeichnungspflichtig sind. Dafür wären dann wohl die divs zuständig, um zu kennzeichen, das jetzt die Absätze nicht mehr zur 1. Neuigkeit gehören sondern die 2. Neuigkeit anfängt.
DIV ist ein Element ohne loische Bedeutung. Du denkst aber auch zu sehr in Boxen. Alles im Quelltext unter einer h2 gehört bis zur nächsten h2 oder h1 logisch zu dieser Überschrift. Und weil dies so ist, ist eine korrekte Nummerierung auch so wichtig.
freundliche Grüße
Ingo-
Hellihello Ingo,
Ich habe gerade mal meine Statistik für Januar 2007 erstellt. Demnach nutzen von 15436 Firefox-Usern noch 11417 (wie ich) eine Version vor 1.5. Insgesamt waren das fast 29% meiner Besucher. Hätte ich scrollbare Bereiche, dann wären also fast 1/3 meiner Besucher verärgert. Firefox-User sind wirklich nicht so update-freudig wie z.B. Opera-User. Checke doch mal Deine Logs...
Klingt überzeugend und hätt ich in dem Ausmaß nicht gedacht. Ich hab hier Firefox 2.0. Jetzt könnte man ja denken, dass das vielleicht an einer mangelnden schnellen Internetverbindung liegt. Aber selbst Du hast ja nicht geupgradet.
Ja. Frames sind eigenständige Seiten und verhindern damit auch eine wirklich sinnvolle Nutzung der Überschriften.
So allgemein mag das stimmen. Ich weiß auch, dass diese Diskussionen schnell in unfruchtbare Bereich abdriften kann. Dennoch bleibt für mich das Argument (unter anderen), dass ein Menü oder eine Info-box, mit eigener Überschriftenstruktur, eigentlich kein logischer Bestandteil einer Inhaltsseite wie zum Beispiel "AGs unserer Schule" ist. "AGs unserer Schule" wäre für mich die Überschrift erster Ordnung, die einzelne AGs wären die zweiter Ordnung, die Beschreibungen dann Absätze. Wären die AGs zB. noch geteilt, gäbe es dann evtl. noch Überschriften dritter Ordnung. Infobox und Menü gehören in diese Struktur aber nicht rein - weil sie "auf einem anderen Blatt" stehen.
DIV ist ein Element ohne loische Bedeutung. Du denkst aber auch zu sehr in Boxen.
(;-) --- könntest Du meine Gedanken lesen, wäre das ausgesprochen überraschend. Es ging mir hier nur um die Tatsache, dass ansonsten alle logischen Einheiten durch einen Beginn und ein Ende markiert bzw. eingefasst werden. Ganz abstrakt und rein logisch würde ich bei einem XML-Dokument doch vermutlich so strukturieren:
<kapitel nummer="1"> <h1>erstes Kapitel - Einleitung</h1> <p>etc... pp.</p> </kapitel>Das "fehlt" mir quasi beim Html, auch wenn natürlich klar ist, dass diese Struktur sich auch ohne einfassendes/umfassendes Element darstellen lässt. Weiß nicht, ob ich diese Überlegung so deutlicher machen konnte.
Dank und Gruß,
frankx
-
Hi,
Infobox und Menü gehören in diese Struktur aber nicht rein - weil sie "auf einem anderen Blatt" stehen.
Ha - erwischt. ;-)
Eine framelose Seite hat nur ein Blatt - mit Frames werden jedoch verschiedene "Blätter" in einem Fenster dargestellt. Die Konsequenz für die Infobox in einer framelosen Seite ist die Berücksichtigung der anderen Überschriften; alternativ müsste die Infobox wirklich auf einem anderen Blatt (Frame, Seite) untergebracht werden.<kapitel nummer="1">
<h1>erstes Kapitel - Einleitung</h1>
<p>etc... pp.</p>
</kapitel>> > Das "fehlt" mir quasi beim Html, auch wenn natürlich klar ist, dass diese Struktur sich auch ohne einfassendes/umfassendes Element darstellen lässt. Weiß nicht, ob ich diese Überlegung so deutlicher machen konnte. doch, sicher. Aber weil es eben so etwas in HTML nicht gibt, kann die Struktur nur über die Überschriften abgebildet werden. Wenn diese in einer logischen Reihengolge gesetzt sind, kann ein (logisch arbeitendes) Programm die Inhalte eindeutig den Überschriften zuordnen: - alles nach einer h1 bis zur evtl. nächsten h1 ist dessen Inhalt - alles nach einer h2 bis zur evtl. nächsten h2 oder h1 ist dessen Inhalt - ... Im angegebenen Beispiel steht die Infobox im Quelltext vor dem Inhalt und kann daher nicht Teil dessen sein und zur hier angegebenen Seitenüberschrift h1 gehören. Dies verhindert leider die zum Inhalt passende h2 für die Überschrift der Infobox. Eine h1 würde sie zwar in korrekter logischer Reihenfolge, aber nicht sinnvoll auszeichnen. Da blieb dann leider nur der Verzicht auf eine Überschrift und eben <strong>. 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)]-
Hellihello Ingo,
Ha - erwischt. ;-)
Genau! ;-) - denn eben wie unten geschrieben, gehört es nicht unter die Hauptüberschrift. Das Beispiel mit einem ausklappbaren Inhaltsverzeichnis in einem Buch gefällt mir da ganz gut.
Eine framelose Seite hat nur ein Blatt - mit Frames werden jedoch verschiedene "Blätter" in einem Fenster dargestellt. Die Konsequenz für die Infobox in einer framelosen Seite ist die Berücksichtigung der anderen Überschriften; alternativ müsste die Infobox wirklich auf einem anderen Blatt (Frame, Seite) untergebracht werden.
Ja, und Frames sind nun mal nicht barrierefrei und alle mit kleinen Bildschirmen heulen dann und und und.
Im angegebenen Beispiel steht die Infobox im Quelltext vor dem Inhalt und kann daher nicht Teil dessen sein und zur hier angegebenen Seitenüberschrift h1 gehören. Dies verhindert leider die zum Inhalt passende h2 für die Überschrift der Infobox. Eine h1 würde sie zwar in korrekter logischer Reihenfolge, aber nicht sinnvoll auszeichnen. Da blieb dann leider nur der Verzicht auf eine Überschrift und eben <strong>.
Und ganz befriedigend finde ich das nicht. Denn das Menü muss ja über der h1 stehen, weil es sonst drunter stünde und das wäre noch falscher. Aber im strengen Sinne ließe sich wohl auch argumentieren, dass über h1 nix stehen kann, denn h1 ist ja die oberste Ordnung. Wäre so, wie wenn in einem Buch erste ein Absatz oder eine Liste käme, und dann die Kapitelüberschrift. Weißt Du denn, ob "das" W3C oder ähnliche Gremien sich mit solchen syntaktisdchen Überlegungen auseinandersetzen? Gibt es dazu auch sowas wie einen Gelehrtenstreit und Html-Linguisten?
Dank und Gruß,
frankx
-
Hellihello Ingo,
von http://www.w3.org/QA/Tips/Use_h1_for_Title beginnt der Quelltext im Body mit:
<div id="banner"> <h1 id="title"> <a href="http://www.w3.org/"><img height="48" alt="W3C" id="logo" src="http://www.w3.org/Icons/WWW/w3c_home_nb" /></a> <a href="http://www.w3.org/QA/"><img src="http://www.w3.org/QA/2002/12/qa.png" alt="Quality Assurance" /></a> Tips for Webmasters </h1> </div> <ul class="navbar" id="menu"> ~~~. Das Menü also unter der ersten Überschrift, ohne Sub-Überschrift. Auf der Seite steht sonst noch: "Unlike the title, this element can include links, emphasis and other HTML phrase elements." Der Titel erster Ordnung sollte also kein Link enthalten? Hab ich da was falsch verstanden? Denn in selbigem Quelltext findet sich doch dort ein Link. Dank und Gruß, frankx -
Hi,
und Frames sind nun mal nicht barrierefrei
das würde ich so generell nicht sagen.
Aber im strengen Sinne ließe sich wohl auch argumentieren, dass über h1 nix stehen kann, denn h1 ist ja die oberste Ordnung.
genau so sehe ich das auch. Aber leider muss man bei einer sinnvollem Verwendung von float je nach Layout halt Zugeständnisse machen. Insofern ist die angestrebte Trennung von Inhalt und Layout nicht immer optimal zu realisieren.
Weißt Du denn, ob "das" W3C oder ähnliche Gremien sich mit solchen syntaktisdchen Überlegungen auseinandersetzen? Gibt es dazu auch sowas wie einen Gelehrtenstreit und Html-Linguisten?
sorry, das wäre sicherlich sehr interessant, ich habe aber noch nichts darüber gelesen. Aber vielleicht jemand anderes hier?
freundliche Grüße
Ingo-
Hellihello Ingo,
und Frames sind nun mal nicht barrierefrei
das würde ich so generell nicht sagen.Von einem Berliner Lehrer weiß ich, dass die öffentlichen Einrichtungen (Landesbildungsserver) keine Frames benutzen dürfen. Von einer blinden Person weiß ich, dass Lesegeräte mit vernünftigen Framesets durchaus umgehen können. Vernünftig zum Beispiel was die Betitelung angeht.
Aber im strengen Sinne ließe sich wohl auch argumentieren, dass über h1 nix stehen kann, denn h1 ist ja die oberste Ordnung.
genau so sehe ich das auch. Aber leider muss man bei einer sinnvollem Verwendung von float je nach Layout halt Zugeständnisse machen. Insofern ist die angestrebte Trennung von Inhalt und Layout nicht immer optimal zu realisieren.Genau da käme dann die Überlegung der "verschiednen Blätter" (;-) zum tragen. http://forum.de.selfhtml.org?t=145595&m=945744t=145595&m=945744: das W3C setzt die Überschrift ja ganz oben an.
Dank und Gruß,
frankx
-
Hi,
Von einem Berliner Lehrer weiß ich, dass die öffentlichen Einrichtungen (Landesbildungsserver) keine Frames benutzen dürfen. Von einer blinden Person weiß ich, dass Lesegeräte mit vernünftigen Framesets durchaus umgehen können. Vernünftig zum Beispiel was die Betitelung angeht.
Ersteres dient wohl dazu, altmodischen/nicht semantischen/Hobbybastler-Code von vornherein auszuschließen. Und ja - Nutzer von Screenreadern können eine Frame-Navigation u.U. sogar besser nutzen, als eine in den Seiten integrierte Navigation jedesmal aufs neue zu suchen. Natürlich erfordern barrierefeie Frameseiten einige Zusätze wie serverseitig realisiertes Nachladen des Framesets bzw. Links auf dieses in jeder Inhaltsseite und eine alternative Nutzungsmöglichkeit über noframes.
freundliche Grüße
Ingo-
Hellihello Ingo,
Ersteres dient wohl dazu, altmodischen/nicht semantischen/Hobbybastler-Code von vornherein auszuschließen.
Wie ich das vom Fachbereichsleiter verstanden habe, sind die da beim Berliner Landesbidlungsserver mit einem Barriere-Profi direkt zugange gewesen, der u.a. auch darauf geachtet, dass Überschriften und Absätze im logischen Zusammenhang stehen (und nicht nur im fürs Auge sichtbaren). Und das Nein zu Frames war kategorisch. Vielleicht aber die von Dir vermuteten Gründe dahinter?
Und ja - Nutzer von Screenreadern können eine Frame-Navigation u.U. sogar besser nutzen, als eine in den Seiten integrierte Navigation jedesmal aufs neue zu suchen.
Mmh, das hatte ich irgendwie manchmal auch schon gedacht (passt zur "verschieden Blätter"-These). Eine Navigation ist ja wie eine Fernbedienung. Ist ja einfacher, sie an einem festen Platz zu haben statt sie nach einem Programmwechsel immer wieder aus dem Fernsehr holen zu müssen (das hinkt ein bisschen, ich weiß).
Natürlich erfordern barrierefeie Frameseiten einige Zusätze wie serverseitig realisiertes Nachladen des Framesets
Wie ist denn da der Ansatz. Das hör ich zum ersten Mal. Wie "geht" das? Mache ich in die Navi links a-la
<a href="meineseite.htm?frameset=schonvorhanden>meineseite</a>oder und Frage auf Serverseite mit PHP zB., ob$_GET['frameset']=="schonvorhanden", und wenn nicht, liefer ich statt der meineseite.htm das komplette Set aus. Oder geht das anders oder "eleganter"?bzw. Links auf dieses in jeder Inhaltsseite
Das "bzw." heißt, entweder serverseitiges Nachladen _oder_ ein Link aufs Frameset?
und eine alternative Nutzungsmöglichkeit über noframes.
Frameset ohne noframes ist ja nun eh grauslig. [scherz] Du meinst diesen Satz: "ihr Browser unterstützt keine Frames", gelle (;-)[/scherz].
Dank und Gruß,
frankx
-
Hellihello Ingo,
Wie ist denn da der Ansatz. Das hör ich zum ersten Mal. Wie "geht" das? Mache ich in die Navi links a-la
<a href="meineseite.htm?frameset=schonvorhanden">meineseite</a>oder und Frage auf Serverseite mit PHP zB., ob$_GET['frameset']=="schonvorhanden", und wenn nicht, liefer ich statt der meineseite.htm das komplette Set aus. Oder geht das anders oder "eleganter"?Mmh, dann schnappt sich google den kompletten Link und das funktioniert dann so also nicht.
Gruß,
frankx
-
-
Hellihello Ingo,
wie serverseitig realisiertes Nachladen des Framesets
da hatte ich jetzt ein bisschen rumgeschaut. Der Beitrag hier in SELFHTML hat mich irgendwie nicht wirklich überzeugt. Ich habe probiert, eine Session im Frameset zu starten, auf den jeweiligen Unterseiten auch und festgestellt, dass die später nachgeladene Seite die ergänzten Session-Variablen der vorher geladenen Seiten "kennt". Wenn also navi.php vor inhalt.php eingebunden wird, und in navi.php noch $_SESSION["navi"]="navi" gesetz wird, taucht diese im var_dump bei inhalt.php auf. So kann ich also bei inhalt.php fragen, ob eine Sessionvariable "navi" existiert und negativenfalls das komplette Frameset nachladen.
Frage, ob das bei allen Browsern (Session-Varianten) funktioniert. Frage auch, ob die Suchmaschinen dann überhaupt zur Inhaltsseite vordringen. Denn wenn sie keine Session mitbringen, kriegten sie ja immer nur das Frameset (;-).
Dank und Gruß,
frankx
-
Hi,
Ich habe probiert, eine Session im Frameset zu starten, auf den jeweiligen Unterseiten auch und festgestellt, dass die später nachgeladene Seite die ergänzten Session-Variablen der vorher geladenen Seiten "kennt". Wenn also navi.php vor inhalt.php eingebunden wird, und in navi.php noch $_SESSION["navi"]="navi" gesetz wird, taucht diese im var_dump bei inhalt.php auf. So kann ich also bei inhalt.php fragen, ob eine Sessionvariable "navi" existiert und negativenfalls das komplette Frameset nachladen.
Da Du weder weisst, ob das Navigationsframe vor dem Inhaltsframe geladen wurde, noch ob beide im Frameset angezeigt werden, würde ich im Framset ein Cookie setzen und dieses in den Inhaltsseiten auslesen. Da Cookies auch nicht 100% zuverlässig sind, sollte auf jeder Inhaltsseite ein Link zum Frameset vorhanden sein.
Frage, ob das bei allen Browsern (Session-Varianten) funktioniert. Frage auch, ob die Suchmaschinen dann überhaupt zur Inhaltsseite vordringen. Denn wenn sie keine Session mitbringen, kriegten sie ja immer nur das Frameset (;-).
Es kann schon Probleme mit Sessions geben, weshalb ich diese hierfür nicht ganz so gut für geeignet halte. Suchmaschinen können auch im Frameset angegebenen Frames folgen, dessen Inhalte indizieren und den Links im Navgationsframe folgen. Erfahrungsgemäß dauert das allerdings länger.
freundliche Grüße
Ingo-
Hellihello Ingo,
dank für die Antwort.
Da Du weder weisst, ob das Navigationsframe vor dem Inhaltsframe geladen wurde, noch ob beide im Frameset angezeigt werden, würde ich im Framset ein Cookie setzen und dieses in den Inhaltsseiten auslesen. Da Cookies auch nicht 100% zuverlässig sind, sollte auf jeder Inhaltsseite ein Link zum Frameset vorhanden sein.
Mh, irgendwie hab ich vielleicht ein Brett vorm Kopf. Gesetzt den Fall, der User akzeptiert keine Cookies, dann lass ich zB. von der Inhaltsseite fragen, "gibt es Cookie?". Und jetzt kommts: wenn da keiner ist, möchte ich ja eigentlich dann stattdessen das Frameset ausgeben. Aber es könnte ja sein, dass es am Nichtzulassen des Clients liegt. Würde dann nicht das Frameset verschachtelt immer wieder und wieder geladen?
Dank und Gruß,
frankx
-
Hi,
wenn da keiner ist, möchte ich ja eigentlich dann stattdessen das Frameset ausgeben. Aber es könnte ja sein, dass es am Nichtzulassen des Clients liegt. Würde dann nicht das Frameset verschachtelt immer wieder und wieder geladen?
stimmt. So könnte man diese Methode nur anwenden zum Einfügen eines Links zum Frameset mit target="_top" und evtl zusätzlich eines Javascripts, das auf die Anzeige im Frameset prüft.
freundliche Grüße
Ingo
-
-
-
-
-
-
-
-
-
-
-
-
-
-