Tree-Layout in HTML5

[Jochen_D_rr]

Hallo zusammen,

ich habe da eine Seite mit zwei Frames, einem Tree links und dem Content rechts. Die Links im Tree schalten den rechten Frame um. Ich überlege gerade, wie man so etwas wohl in HTML5 lösen könnte. Frames sind ja nicht mehr erlaubt. Voraussetzung ist das keinerlei serverseitige Sprachen zur verfügung stehen.

Man könnte IFrames verwenden, die sind meines wissens noch erlaubt, skalieren aber natürlich nicht so schön.

Ein anderer Ansatz ist es, die Content-Seiten via Ajax zu laden und ein ein DIV einzufügen. Das ist aber dann doch ziemlich umständlich.

Wer ist schon einmal auf diese Problem gestoßen und wie habt ihr es gelöst?

Gruß
Jochen

[TechPech]

mal ganz doof , wie es halt die html erzeuger programme so machen .

pro ding eine seite … links dein tree rechts der content und dann halt verlinkt zu den einzelnen seiten.

anonsten iframe , wie auch sonst ?
was nun das problem mit ajax angeht … schon doof wenn kein javascript im browser läuft, dann ist deine seite quasi tot .

[Efchen]

Moin,

ich habe da eine Seite mit zwei Frames, einem Tree links und
dem Content rechts. Ich überlege gerade, wie man so etwas wohl
in HTML5 lösen könnte.

Genauso wie in HTML 4.
Semantik/logische Struktur in HTML, Layout in CSS.

Frames sind ja nicht mehr erlaubt.

Das ist so auch nicht ganz richtig. Aber sich von den Frames zu verabschieden ist sicherlich richtig und ich möchte nicht den Eindruck erwecken, Frames wären grundsätzlich was Gutes.

Voraussetzung
ist das keinerlei serverseitige Sprachen zur verfügung stehen.

Wenn Du damit auf die Funktionalität der Frames ansprichst, dass gleichbleibende Elemente nicht in jeder Seite gepflegt werden müssen, dann gibt es nur eine serverseitige Lösung, die Spaß macht. Alternativen sind Frames und ein Editor, der Deine Seiten erzeugt, indem er das Menü selbst in alle Seiten einbaut. Sowas solls geben.

Man könnte IFrames verwenden, die sind meines wissens noch
erlaubt, skalieren aber natürlich nicht so schön.

Ob da ein „i“ davor steht oder nicht, macht absolut keinen Unterschied - im Gegenteil, von den ganz alten Browsern verstehen mehr Frames als iFrames. Wenn Du von den Frames weg willst, um hin zu iFrames zu gehen - das bringt Dir rein gar nichts. Dann lass es. Besser ist es, serverseitige Techniken zu besorgen. Webspace damit ist ja nicht teuer.

Ein anderer Ansatz ist es, die Content-Seiten via Ajax zu
laden und ein ein DIV einzufügen. Das ist aber dann doch
ziemlich umständlich.

Und es sind serverseitige Techniken, die hast Du ja kategorisch ausgeschlossen. Außerdem sind Ajax noch schlimmer als Frames in der Beziehung, weswegen auch Frames schon schlecht sind. Während man bei Frames noch Links auf Unterseiten setzen kann, wo dann allerdings das Menü fehlt, geht das bei Ajax-erzeugten Seiten gar nicht mehr. Außerdem muss da auch clientseitig noch JavaScript aktiviert sein, was noch mehr Barrieren aufbaut als Frames.

Wer ist schon einmal auf diese Problem gestoßen und wie habt
ihr es gelöst?

Mit serverseitigen include-Möglichkeiten.

Wenn Du die weiterhin strikt ausschließt (obwohl sie die einzigen anständigen Mittel für Webmaster sind), dann hast Du eigentlich keine Wahl und solltest bei Deinen Frames bleiben - wenn Du (wie es eigentlich Pflicht ist!) Alternativen für den noFrames-Bereich anbietest, dann steht Deinen Frames auch generell nichts im Wege.

Liebe Grüße,
-Efchen

[Efchen]

Nachtrag zu HTML5
Ach ja, mit HTML5 hat Deine Frage bislang gar nichts zu tun. XFrames oder wie die heißen sollten, sind IIRC wieder verworfen worden (wären die nicht eh Teil von CSS gewesen?).

[osmodius]

Frames sind ja nicht mehr erlaubt.

Das ist so auch nicht ganz richtig.

Doch, das ist sogar völlig richtig.

http://www.w3.org/TR/html5/obsolete.html#non-conform…

Oder wolltest Du darauf hinaus, daß „veraltet“ nicht mit „nicht mehr erlaubt“ gleichzusetzen ist? Für valides HTML5 sind sie jedenfalls nicht erlaubt.

Man könnte IFrames verwenden, die sind meines wissens noch
erlaubt, skalieren aber natürlich nicht so schön.

Ob da ein „i“ davor steht oder nicht, macht absolut keinen
Unterschied - im Gegenteil, von den ganz alten Browsern
verstehen mehr Frames als iFrames.

Iframes gehören zum Standard von HTML 4, wer Browser benutzt, die älter sind, dem kann auch durch weglassen von iframe nicht geholfen werden.
http://www.w3.org/TR/html4/index/elements.html

Gruß

osmodius

[osmodius]

Ach ja, mit HTML5 hat Deine Frage bislang gar nichts zu tun.

???

Du hast doch selber auf diese Überlegung geantwortet:

Ich überlege gerade, wie man so etwas wohl in HTML5 lösen könnte. ::Frames sind ja nicht mehr erlaubt.

[Efchen]

Frames sind ja nicht mehr erlaubt.

Das ist so auch nicht ganz richtig.

Doch, das ist sogar völlig richtig.

Mein Fehler, ich habe das nicht in Beziehung zu HTML5 gesetzt.
Frames benutzt man ja nicht erst mit HTML5 nicht mehr, sondern schln viel früher, genaugenommen braucht man unter Verwendung von serverseitigen Techniken in keiner HTML-Variante Frames.

Iframes gehören zum Standard von HTML 4

Frames auch.

wer Browser benutzt,
die älter sind, dem kann auch durch weglassen von iframe nicht
geholfen werden.

Doch.

-Efchen

[osmodius]

wer Browser benutzt,
die älter sind, dem kann auch durch weglassen von iframe nicht
geholfen werden.

Doch.

Ach, so, ich wusste nicht, daß Du mit Exploits für die ungezählten Sicherheitslücken der nicht mehr supporteten Dinosaurier handelst.
Mein Fahler.

osmodius

[Jochen_D_rr]

Hey danke für die ganzen Antworten. Streitet euch mal nicht

Seiten nachladen hat nicht unbedingt was mit serverseitig zu tun. Ich kann z.B. mit jQuery einfach eine HTML-Datei (oder auch nur ein Element daraus) in ein DIV laden.

Ich seh schon, es gibt keine wirklich einfache Lösung für die Sache.

Das soll keine Seite für die breite Masse sein sondern es handelt sich um Informationsseiten auf einem embedded Webserver. Daher steht auch keinerlei serverseitige logik zur Verfügung.

Das heißt alte Browser sind kein Thema (HTML5 ist Voraussetzung), Javascript ist ebenso Vorraussetzung.

Stellt euch vor ihr habt links einen Tree mit einigen Unterpunkten und mit einem Klick auf einen Unterpunkt wird rechts ein entsprechendes Diagramm in einem HTML5 canvas dargestellt. Eigentlich ganz einfach. Aber da es sich um ein canvas handelt brauche ich HTML5. Da ich HTML5 brauche darf ich keine Frames verwenden. Doch nicht so einfach. Was ich mir jetzt auf jeden Fall noch ansehe ist backbone.js, da gibt es irgendwie einen Paging-Mechanismus (evtl. ähnlich wie bei jQuery mobile). Mal sehen…

Gruß
Jochen

[Efchen]

Moin,

Seiten nachladen hat nicht unbedingt was mit serverseitig zu
tun. Ich kann z.B. mit jQuery einfach eine HTML-Datei (oder
auch nur ein Element daraus) in ein DIV laden.

Dabei wird doch auch nur die AJAX-Technik benutzt und das ist nicht nur eine client- sondern auch eine serverseitige Lösung. Oder nicht?

Ich seh schon, es gibt keine wirklich einfache Lösung für die
Sache.

Doch, ein serverseitiges Include.
Bei Dir mit Deinem abgespeckten Webserver aber gibts vermutlich keine einfache Lösung. Aber wenns nicht für die breite Masse ist, sehe ich auch nicht wirklich einen Hinderungsgrund, Frames zu benutzen.

Das heißt alte Browser sind kein Thema (HTML5 ist
Voraussetzung), Javascript ist ebenso Vorraussetzung.

Alte Browser können kein HTML5. Aber HTML5 gibt es ja eigentlich auch nich nicht. Theoretisch kann sich da noch viel ändern gegenüber dem, was die einzelnen Browser bisher umsetzen.

Stellt euch vor ihr habt links einen Tree mit einigen
Unterpunkten und mit einem Klick auf einen Unterpunkt wird
rechts ein entsprechendes Diagramm in einem HTML5 canvas
dargestellt. Eigentlich ganz einfach. Aber da es sich um ein
canvas handelt brauche ich HTML5. Da ich HTML5 brauche darf
ich keine Frames verwenden.

Da sehe ich nicht wirklich einen Hinderungsgrund.
Abgesehen davon ist das auch syntaktisch schon jetzt lösbar. Die Frameset-Seite schreibst Du als HTML 4.01 Frameset, und die Hauptseite, die Du da nachlädst, ist halt in HTML5 - syntaktisch keinerlei Einwände.

Doch nicht so einfach.

Doch.

Was ich mir
jetzt auf jeden Fall noch ansehe ist backbone.js, da gibt es
irgendwie einen Paging-Mechanismus (evtl. ähnlich wie bei
jQuery mobile). Mal sehen…

Wenn ich eine Web-Anwendung für einen ausgewählten Benutzerkreis, z.B. für Mitarbeiter einer Firma, schreiben würde, und wenn ich dabei auf solche Probleme stoßen, dann würde ich auch ungültige Tags in den Quellcode schreiben (sofern der Browser dasmitmacht), wenn die Alternative wäre, aufwändige Programmierlösungen zu schreiben.

Liebe Grüße,
-Efchen

[TechPech]

Moin,

Seiten nachladen hat nicht unbedingt was mit serverseitig zu
tun. Ich kann z.B. mit jQuery einfach eine HTML-Datei (oder
auch nur ein Element daraus) in ein DIV laden.

Dabei wird doch auch nur die AJAX-Technik benutzt und das ist
nicht nur eine client- sondern auch eine serverseitige Lösung.
Oder nicht?

Nein , ich mach einen HTTP Request, was ich mir hole ob html textdatei oder oder ist wurst Solange es der Server als antwort ausliefert ist alles roger und nur client seite .

[Jochen_D_rr]

Hallo,

…Aber da es sich um ein
canvas handelt brauche ich HTML5. Da ich HTML5 brauche darf
ich keine Frames verwenden.

Da sehe ich nicht wirklich einen Hinderungsgrund.
Abgesehen davon ist das auch syntaktisch schon jetzt lösbar.
Die Frameset-Seite schreibst Du als HTML 4.01 Frameset, und
die Hauptseite, die Du da nachlädst, ist halt in HTML5 -
syntaktisch keinerlei Einwände.

Ganz so einfach ist es leider nicht. Die Idee hatte ich auch schon, wenn aber die Seite mit dem Frameset HTML4 ist dann lässt zumindest der IE9 (andere hab ich noch nicht probiert) auch in den Frames kein HTML5 zu.

Gruß
Jochen

[Efchen]

Moin,

Ganz so einfach ist es leider nicht. Die Idee hatte ich auch
schon, wenn aber die Seite mit dem Frameset HTML4 ist dann
lässt zumindest der IE9 (andere hab ich noch nicht probiert)
auch in den Frames kein HTML5 zu.

Wie äußert sich das? Ich kann mich nicht erinnern, dass ein Browser irgendwas in HTML, ob mit oder ohne Doctype, ob gültige Tags oder nicht, nicht angezeigt hätte.

Gruß,
-Efchen