CSS-Design

Hallo mal so ne Frage die mich schon seit längerem beschäftigt!
Wie kann man das realisieren das man in einem Css design auf einen Link klick das dann die an-
geforderte Seite im Content angezeigt wird?
Also Anschauungsmaterieal Um das son bissel zu erklären wie ich das meine habe ich angehängt!

hallo das ganze geht mit php

hier is ein wunderschönes tutorial:

http://tut.php-quake.net/frames.html

alles erklärt wie es geht =)

mfg
paul

Das kannst du aber auch mit einem “iframe” realisieren.

Stimmt da habe ich noch garnicht drann gedacht!
THX

Wennschon würde ich das ganze mit divs (container) realisieren. Frames sind irgendwie veraltet und hässlich.

de.selfhtml.org/html/text/bereiche.htm
mediaevent.de/xhtml/div.html

Normalerweise wird bei einem solchen Layout gar nichts ausgetauscht, sondern die komplette Seite (mit Navigation und header) neu geladen.
In aller Regel ist das auch kein Problem, da sich zumindest der Header gar nicht und die Navigation nur unwesrentlich ändert - die Grafiken liegen dann schon im Cache des Browsers und werden nicht neu vom Server geladen (was sich positiv auf die Ladezeit der Seite auswirkt).

Wenn es unbedingt sein muss, würde ich dieses Thema mit PHP und include lösen.
Dazu gibst Du dem Link einen Parameter mit, den Du später per GET wieder ausliest (beachte dabei aber bitte die Sicherheitsthematik - sonst könnte Deine Seite schneller gehackt sein, als Du :bp: sagen kannst :astonished: )

Iframes werden nie veraltet sein, hingegen normale Frames schon.
Und er möchte ja bei klick eine Seite einbinden, dies ist mit DIV’s alleine nicht zu realisieren. Das Thema hatte ich auch schon gehabt und musste aufgrund dessen auch auf iframes umsteigen. Sihe meine Homepage.

iframe und framesets gehören beide zu den Sachen, die in
HTML4 als veraltet gekennzeichnet sind, also in den
strict-Varianten nicht mehr verfügbar. iframes sind eher noch
problematischer als framesets, weil zumindest der vor 10 Jahren
noch sehr gebräuchliche netscape4 zwar frames interpretiert,
nicht aber iframes, die also schon von der Kompatibilität her noch
nie eine sinnvolle Wahl waren.
Externe Dokumente kann man stattdessen per object
integrieren, da ist aber nicht vorgesehen, daß man den Inhalt
wie in framesets oder beim iframe einfach so austauschen
kann, also zumindest nicht von außerhalb des Dokumentes,
welches mit object referenziert wird.
Sowohl bei object als auch iframe kann man im Element selbst
eine Alternative anbieten, etwa für den inzwischen kaum noch
genutzten netscape4 und alle andere, die mit den Elementen oder
den referenzierten Dokumentformaten nichts anfangen können.

Von daher wird das inzwischen meist so gemacht, daß die
Inhalte einfach dynamisch mit PHP, perl oder sonstwas
zu einem Dokument zusammengebastelt werden, was dann
so ausgeliefert wird. Das macht dann frames in der Tat für
die allermeisten Anwendungen überflüssig, für die sie zuvor
auch an sich schon nicht tauglich waren.
Dort, wo frames sinnvoll sind, kann man dann in der Regel
stattdessen auch object verwenden. Das ist meist der Fall, wenn
man ein anderes Dateiformat integrieren will, etwa SVG, XHTML,
MathML etc in HTML.

Mir wurde mal vor nicht all zu langer Zeit erklärt, das iframes auch zum neuen HTML5 standard gehöre und auch in naher Zukunft aktuell bleiben solle.
Das das auch mit der “objekt” basierenden Einfassung gelinge, ist mir auch neu. So kann man immer wieder etwas neues lernen.
Ich habe mich auch schon immer gefragt, warum man diese Art nicht einfach in die DIV’s Container einfügen könne.
Bsp:

Das wäre doch eigendlich eine Lücke in der DIV’s komplexität, wenn ich mich nicht ganz irre.

Zum Thema iframe:

de.selfhtml.org/navigation/suche … age=iframe

Daraus folgt, dass in XHTML1.1 (der “höchste” mir bekannte Standard) dieses Element nicht zulässig ist.

Ein anderer Nachteil, der für mich als User wesentlich schwerer wiegt, liegt aber in der Zuänglichkeit: wenn Inhalte in einen IFRAME gesetzt werden, kann ich keine Bookmarks auf bestimmte Inhalte setzen.
Bei Links in der Art seite.html?pid=12&action=view funktioniert das prächtig…

Im Arbeitsentwurf für ‘HTML5’ steht vorrangig drin, wie browser
fehlerhafte Seiten zu interpretieren haben. Daraus läßt sich nicht
ableiten, daß Autoren die Seiten auch fehlerhaft anbieten sollten.
In Folge dieses Ansatzes steht in dem Arbeitsentwurf für 'HTML5’
vieles drin, was Autoren niemals tun sollen. Es stehen auch
veraltete Elemente drin oder wie solcher Unfug wie embed
interpretiert werden sollte.
So wie das derzeit aussieht, ist dieser Entwurf eher eine
Kuriosität, die für Autoren nur schwer verständlich ist und im
derzeitigen Entwicklungsstand noch einige Lücken und
Widersprüche aufweist, Widersprüche teilweise auch zu den
schriftlich niedergelegten Ansprüchen der Arbeitsgruppe.
Widersprüche und Inkompatibilitäten auch zu anderen Standards
und früheren HTML-Versionen, obgleich es das zentrale Ziel der
Arbeitsgruppe ist, das rückwärtskompatibel zu spezifizieren.
Man kann also eher sagen, daß man in ‘HTML5’ eher finden, was
in den letzten 10 bis 15 Jahren so in den browsern
zusammengebastelt wurde, auch um auf teilweise gruselig
unsinnige Dokumente von Autoren zu reagieren, um sie dennoch
anzeigen zu können.

‘HTML5’ enthält auch ein paar gute neue Ideen, die wiegen aber
derzeit den Schaden nicht auf, der damit angerichtet wird, denn
letztlich fördert dieser Entwurf geradezu die Gleichgültigkeit der
Autoren gegenüber dem, was sinnvoll oder richtig ist, was sich
daher aus dem Entwurf sicher nicht ableiten läßt.
Es gibt da auch Mitglieder der Arbeitsgruppe, die wollen deswegen
eine Version/Übersetzung für Autoren verfassen, in der dann
drinstehen soll, wie man es als Autor eigentlich machen sollte.
Da sich andererseits aber die Arbeitsgruppe dagegen sperrt,
zahlreiche vorgeschlagene Neuerungen so durchzuführen, daß sie
wirklich den Stil von Autoren und ihr Verständnis für
Textauszeichnung uns Sprache verbessern könnten und die
Zugänglichkeit von solchen Dokumenten zu verbessern, kann man
aus meiner Sicht nicht so viel von ‘HTML5’ erwarten…
Was inhaltlich in XHTML1.1 fehlt, wird man auch in ‘HTML5’ nicht
finden, das ist (auch nur teilweise) im Entwurf von XHTML2 zu
finden, wo aber nicht klar ist, ob oder wann das umgesetzt wird,
weil die browser-Hersteller doch an ihrem ‘Liebling’ 'HTML5’
hängen, zumal da ja auch nur drinsteht, was sie ohnehin schon
machen (samt historischer Fehlerliste).

[size=150]Ob “xhtml1.1/2” oder “html5”. Ich sehe in den neuen Standards so und so nicht ganz durch. Da müsste man sich mal zeit nehmen und sich intensiv darüber erkundigen.[/size]

Durchlesen und staunen ;o)

HTML5:
w3.org/html/wg/html5/
w3.org/TR/2007/WD-html-desig … -20071126/
w3.org/html/wg/

XHTML2:
w3.org/TR/xhtml2/

XHTML1.1 ist ja bereits seit langem fertiggestellt, gibt dazu auch
auch abgespeckte Versionen für Mobiltelephone, das ist von daher
ein etabliertes, altes Format, nicht ganz so alt wie HTML4, gibt
allerdings derzeit eine kleinere Aufarbeitung (Korrektur kleinerer
Fehler):
w3.org/TR/xhtml11/

Das ist die Version von 2001:
w3.org/TR/2001/REC-xhtml11-20010531/

Oder in der Übersicht:
w3.org/MarkUp/

Danke @Hoffmann für die zahlreichen Links. Da werde ich mich auf jeden Fall mal durcharbeiten.

Nochmal zur ursprünglichen Frage:

Es wäre natürlich auch möglich, JS und PHP zu kombinieren:
Benutzer klickt auf Link -> Client löst eine AJAX-Anfrage an den Server aus -> Server gibt Content zurück -> Client ersetzt Content. Vorteil dabei wäre, dass man eine “bitte-warten-anzeige” implementieren kann.

Eine andere Möglichkeit wäre auch noch, XSLT und JS auf der Clientseite einzusetzen: http://www.w3schools.com/xsl/xsl_client.asp. Vorteil (?) hier: Man kommt ohne PHP aus.

Beides hat natürlich den Nachteil, dass ältere Browser dann bei der Seite aufgeschmissen sind.

MfG jw

Möglich wäre es.

Sinnvoll…?

JavaScript- erzeugte Inhalte (also auch Ajax) existieren für Suchmaschinen nicht.
Und wer will schon eine Seite erstellen, die niemand findet?
:ps: :astonished:

iFrames empfehlen, ist das nicht schon ein verbrechen? :ps:

Dann solltest du aber drauf achten, dass sich Clients ohne JavaScript auch zurechtfinden, sprich: