HTML-Tag zum Nachladen von HTML-Blöcken

[Unwissend]

Weis jemand ob und wann das kommen wird? Und ich meine nicht SSI-Tags.
Das würde einige meiner Seiten stark vereinfachen und dem Klient unnötige Laderei ersparen. Soweit ich weis war das schonmal in Gespräch, aber ob es nun umgesetzt worden ist weis ich nicht.

Unwissend

[Jeena Paradies]

Hallo,

Weis jemand ob und wann das kommen wird? Und ich meine nicht SSI-Tags.
Das würde einige meiner Seiten stark vereinfachen und dem Klient unnötige Laderei ersparen. Soweit ich weis war das schonmal in Gespräch, aber ob es nun umgesetzt worden ist weis ich nicht.

Das wäre nicht sinnvoll, denn HTML ist eine Auszeichnungssprache.

Das wurde schon mal probiert und setzte sich nicht durch siehe http://selfhtml.teamone.de/html/layer/index.htm

Grüße
Jeena Paradies

[Unwissend]

Hallo auch

Das wäre nicht sinnvoll, denn HTML ist eine Auszeichnungssprache.

Hm? VErsteh ich jetzt nicht so ganz. Es wären doch keine Aktieven Elemnet enthalten, wie Javasript oder ähnliches. Es sollte sowas sein wie CSS nur daß man keine CSS dateien einfügt sondern HTML-Dateien.

Das wurde schon mal probiert und setzte sich nicht durch siehe
http://selfhtml.teamone.de/html/layer/index.htm

Nunja Layer wurden durch DIVs und ähnliches abgelöst. Es waren Netscape spezifische Elemente zur grafischen Gestaltung. So weit ich weis ist es ohne Javasript nicht möglich dort Seitenfremde Inhalte ein zu fügen.

Unwissend

[SabineP]

Nunja Layer wurden durch DIVs und ähnliches abgelöst. Es waren Netscape spezifische Elemente zur grafischen Gestaltung. So weit ich weis ist es ohne Javasript nicht möglich dort Seitenfremde Inhalte ein zu fügen.

Unwissend

Selbstverständlich lassen sich seitenfremde Inhalte einfügen (nur Netscape 4):
<layer top="10" left="10" src="http://www.example.com/index.html"></layer>

Gruß Sabine

[Unwissend]

<layer ... src=... ></layer>

Es wäre fast das was ich suche, man kann damit aber nur in sich geschlossenen Elemente in der HTML-Seite unterbringen. Die Verwendung ist nur begrenzt möglich. (Sowohl vom Browser her als auch vom Inhalt)

gruß
Unwissend

[dbenzhuser]

N'Obend

Weis jemand ob und wann das kommen wird? Und ich meine nicht SSI-Tags.

Frames? iFrames? (wie auch immer man letztere jetzt cool schreibt...)
Die können das.
X-Frames werden das (falls sie denn wirklich kommen) in Zukunft, auch mit neueren Standards, valide machen können.
Ob Frames allerdings wirklich etwas vereinfachen, wage ich zu bezweifeln.

Weitere derartige Methoden sind mir nicht bekannt.

Für was auch? Nimm PHP, nimm SSI, nimm Phase5 (oder einen anderen Editor mit derartigen Funktionen) und lass die Seiten automatisch zusammenstellen.
Mir fällt momentan kein Szenario ein, das sich mit PHP (und vielleicht noch iFrames) nicht lösen lassen würde.

Nacht,
dbenzhuser

(PS: Nein ich hab Perl nicht vergessen :) )

[Unwissend]

N'Obend

dito

Frames? iFrames? (wie auch immer man letztere jetzt cool schreibt...)
Die können das.

Das macht jedoch größere Probleme Bei Bookmarks. Vor allem Dokumentationen sollten daher ohne Frames aufgebaut sein. Allso muß in jede Seite gleiche und Ähnliche Elemente eigebaut werden, die bei jeder neuen Seite wieder geladen werden. Die Auslagerung von CSS und Javasript ist ja schon eine Erleichterung, aber aufwändige Menustrukturen oder anderere komplizierte Konstrukte (Chemische fpormeln, Mathematische Umschreibungen, Grafische Konstrukte) sind so kaum aus zu lagern (außer durch Javasript, aber das ist eine Krücke).

X-Frames werden das (falls sie denn wirklich kommen) in Zukunft, auch mit neueren Standards, valide machen können.

Kenne ich nicht, was sollen die denn genau können?

Ich stelle mir die Ideallösung (für mich) ungefährso vor:
<htmlelement src="http://was.weis.ich/seite.html">Hier sollte eigendlich viel mehr stehen!</htmlelement> aus "seite.html" wird alles zwischen den Bodytags an der Stelle eingefügt. Relative Referenzen werden angepasst. (Das das auch zu Problemen führen kann sehe ich, doch ich meine, daß die Vorteile überwiegen würden.)

Ob Frames allerdings wirklich etwas vereinfachen, wage ich zu bezweifeln.

Wie oben schon geschrieben, sie können helfen, aber nicht immer.

Für was auch? Nimm PHP, nimm SSI, nimm Phase5 (oder einen anderen Editor mit derartigen Funktionen) und lass die Seiten automatisch zusammenstellen.

Klar, aber wie schon gesagt, Große immer gleiche Blöcke müssen übertragen und gespeichert werden, und bei statischen Seiten auch Verwaltet werden.

Eine Erfahrung meinerseits. Eine HTML-Dokumentation, mit SSI Ausgestattet verbrauchte 10MB, die gleiche statisch zum Download hatte 30MB. OK Komprimiert waren das dann nurnoch 2MB. Aber nicht immer kann man komprimieren.

Mir fällt momentan kein Szenario ein, das sich mit PHP (und vielleicht noch iFrames) nicht lösen lassen würde.

Es geht mir um eine optimale Lösung nicht um irgendeine. Natürlich sind das machbare Lösungen, doch haben sie alle das Problem mit der Datenübertragung oder Speicherung. Das mag einem nicht so viel anhören, wenn man aber schmale Kommunikationswege oder wenig Speicherplatz hat, dann muß man darauf achten.

(PS: Nein ich hab Perl nicht vergessen :) )

und Phyton und C und Pascal und VBasic und ... und ... und ... :)

nacht
Unwissend

[Cybaer]

Hi,

Das macht jedoch größere Probleme Bei Bookmarks.

? Nicht daß ich wüßte. =8-o Es hindert dich *niemand* daran, zu jedem Inhalt ein eigenes Frameset zu machen (und sei es automatisch).

Eine Erfahrung meinerseits. Eine HTML-Dokumentation, mit SSI Ausgestattet verbrauchte 10MB, die gleiche statisch zum Download hatte 30MB. OK Komprimiert waren das dann nurnoch 2MB. Aber nicht immer kann man komprimieren.

HTTP 1.1 unterstützt Datenkompression. Ggf. müssen aber alte Browser abgefangen und mit unkomprimierten Daten versorgt werden. Wenn nicht, dann sparst Du auch Platz auf dem Server.

Gruß, Cybaer

[Unwissend]

Morgen.

? Nicht daß ich wüßte. =8-o Es hindert dich *niemand* daran, zu jedem Inhalt ein eigenes Frameset zu machen (und sei es automatisch).

Klar und wieder habe ich das Probem mit den Doppelten daten, die ich verwalten und übertragen muß. Zudem Arbeitet Javascript nicht so einfach Seitenübergreifend. Javasript gesteurete Hilfen sind auch nicht gerade einfach so zu lösen.

Eine Erfahrung meinerseits. Eine HTML-Dokumentation, mit SSI Ausgestattet verbrauchte 10MB, die gleiche statisch zum Download hatte 30MB. OK Komprimiert waren das dann nurnoch 2MB. Aber nicht immer kann man komprimieren.

HTTP 1.1 unterstützt Datenkompression. Ggf. müssen aber alte Browser abgefangen und mit unkomprimierten Daten versorgt werden. Wenn nicht, dann sparst Du auch Platz auf dem Server.

Ja das ist schön und gut aber wie sieht es auf dem Klient aus? Wenn die  Daten lokal gespeichert sind, und einsehbar sein sollen, dann dürfen sie nicht komprmiert sein, und die Datenmanege steigt umpropotional zum Informationsinhalt, das gild vor allem für Dokumentationen.

Eine, wie von mir gedachte Lösung scheint es ja zu geben:
http://forum.de.selfhtml.org/?t=80504&m=467405
Nur ist sie nicht Implementiert.

gruß
Unwissend

[Swen Wacker]

Moin,

HTTP 1.1 unterstützt Datenkompression. Ggf. müssen aber alte Browser abgefangen und mit unkomprimierten Daten versorgt werden. Wenn nicht, dann sparst Du auch Platz auf dem Server.
Ja das ist schön und gut aber wie sieht es auf dem Klient aus?

http://www.schroepl.net/projekte/mod_gzip/browser.htm

Gruß

Swen

[Unwissend]

Moin,

dito

Ja das ist schön und gut aber wie sieht es auf dem Klient aus?
http://www.schroepl.net/projekte/mod_gzip/browser.htm

Wenn alle Brwoser Offline auf Komprimierte HTML-Dokumentene zugreifen könnten, wäre es ideal, doch was nützt es eine Komprimirte übertragung zu haben, wenn alles auf dem Klient unkomprimirt gespeichert wird. Sollte kein Internetzugang zur Verfügung stehen, so muß man die daten auf entsprechenden Datenträgern zur Verfügung stellen. Und es kann sehr schwirig sein unwilligen Leuten zu erklären wie sie die HTML-Dukumentationen zu entpacken haben. Könnte das ein Browser von sich aus, wäre das ein Argument für mich. Dem ist, so weit sich weiß nicht so.

gruß
Unwissend

[Jeena Paradies]

Hallo,

Und es kann sehr schwirig sein unwilligen Leuten zu erklären wie sie die HTML-Dukumentationen zu entpacken haben.

Nun ich denke dass wenn jemand unwillig ist dann hat er auch gar kein Interesse an dieser Dokumentation. Du könntest auch ein selbstentpackendes Archiv anbieten. Dann ist das nur ein Doppelklick und man muss noch angeben wohin es entpackt werden soll. IMHO ist es ziemlich komfortabel. Natürlich must du bedenken dass es vielleicht Leute gibt die mit diesen selbstentpackenden Archiven nichts anfangen können und es eventuell auch als tarball abieten.

Grüße
Jeena Paradies

[Unwissend]

Hallo,

dito

Nun ich denke dass wenn jemand unwillig ist dann hat er auch gar
kein Interesse an dieser Dokumentation.

Damit hast du leider recht, was mich aber nicht von gewissen Plichten erlöst. :(

Du könntest auch ein selbstentpackendes Archiv anbieten.
...
und es eventuell auch als tarball abieten.

So ist es zur Zeit geplant, was mich aber nicht daran hindert nach einer in meinen Augen besseren Lösung zu suchen :)

gruß
Unwissend

[Cybaer]

Hi,

Du könntest auch ein selbstentpackendes Archiv anbieten.

Und zumindest für Windows gibt es Programme, die aus einer Website ein kleines, handliches Programm (inkl. Browser) erstellen können.

Gruß, Cybaer

[Swen Wacker]

Moin,

Wenn alle Brwoser Offline auf Komprimierte HTML-Dokumentene zugreifen könnten, wäre es ideal, doch was nützt es eine Komprimirte übertragung zu haben, wenn alles auf dem Klient unkomprimirt gespeichert wird.

Was interessiert _Dich_ das? Warum führst Du jetzt solche "Probleme" in die Diskussion ein? Sie haben mit Deinem bisherigen Wünschen nichts zu tun.

Wenn Dein Werk auf dem Rechner des Besuchers angelangt ist, dann gibt in der Regel es weder Platzprobleme noch Traffikprobleme. Ob es es auf einem lokalen Rechner komprimiert abgelegt ist oder nicht, ist praktisch ohne Belang.

Du solltest bei Deinem Wunschkatalog bleiben anstatt bei jedem Lösungshinweis, der dir hier gegeben wird, eine neue Bedingung einzuführen. Du erweckst sonst den Eindruck, dass Du an einer Lösung nicht interessiert bist.

Gruß

Swen

[Cybaer]

Hi,

? Nicht daß ich wüßte. =8-o Es hindert dich *niemand* daran, zu jedem Inhalt ein eigenes Frameset zu machen (und sei es automatisch).
Klar und wieder habe ich das Probem mit den Doppelten daten,

Dann ist wohl deine Lösung suboptimal, was Du aber nicht Frames/Framesets in die Schuhe schieben darfst =;-) ...

Zudem Arbeitet Javascript nicht so einfach Seitenübergreifend.

... und auch nicht JavaScript. Das habe ich nicht erwähnt und nicht gemeint (warum sollten Frames auch JavaScript bedingen), und falls *Du* bereits jetzt JavaScript verwendest: Natürlich arbeitet JavaScript einfach Frameübergreifend.

Aber auch Seitenübergreifend ist es nicht gerade problematisch ...

Ja das ist schön und gut aber wie sieht es auf dem Klient aus?

Der muß sie, nach dem kurzen Ladevorgang, halt entpacken bevor er sie darstellt.

Wenn die  Daten lokal gespeichert sind, und einsehbar sein sollen, dann dürfen sie nicht komprmiert sein,

Schon klar, aber eben war nur der Platz auf deinem Server knapp bemessen, jetzt ist es schon der beim Anwender. Was denn nun? =:-o

und die Datenmanege steigt umpropotional zum Informationsinhalt, das gild vor allem für Dokumentationen.

Wieso?

Gruß, Cybaer

PS: Also wenn mich eine Doku interessiert, die 30 MByte auf meiner Festlatte verbrät, dann tut sie es halt. Meine erste Festplatte hatte 20 MByte - seitdem sind die Dinger aber etwas größer geworden ... ;-)

[Unsicher]

Hi,

Hallo auch

Also gut will ich mal zusammenfassen was meine Problem nun konkret sind. Es soll ein umfassendes Mathematisches Lehrbuch/Vorlesungssript in HTML geschrieben werden. Wenn es mal fertig ist, soll es Über Internet, per Diskette(Vom Prof erwünst, kann er sich aber wohl Grundsätzlich knicken) oder ausgedruckt verteilt werden. (andere zur veröffentlichung bestimmte Dokumentationsformen scheiden aus den verschiedensten Gründen vorläufig aus) In einem von mir Testweise aus den Rohdaten erstellten Dokumentationsauschnitt haben sich mehrere Probleme gezeigt. Einerseits sind die meisten Konverter kaum für solche Datenmengen und Kompexitäten zu gebrauchen, zum anderen tauchen vielfache Wiederholungen auf (die zum Teil grausam umgesetzt wurden). In einem Teil des Dokumentas habe ich duch setzen von Inkludes und Auslagern von Teilen Ordnung und Sauberkeit geschaffen, die starke Größenreduktion war erwünscht. Nun bin ich auf der Suche nach Möglichkeiten diese Auslagerungen zu erhalten. Selbstverständlich ist es möglich bei der Generierung der finalen Version alle Elemente wieder an die Entspechenden Stellen ein zu fügen, das ganze geeignet zu komprimieren und zu verteilen, doch Suche ich halt nach einer eleganteren Lösung, die es wie es scheint zwar vom HTML-Standart vorgesehen, aber nicht umgesetzt ist. Da ich zur Zeit noch für alle Voschläge offen sein kann, Suche ich nach Altenativen oder anderen Ansätzen, die ich nicht bedacht habe.

PS: Also wenn mich eine Doku interessiert, die 30 MByte auf meiner
Festlatte verbrät, dann tut sie es halt. Meine erste Festplatte
hatte 20 MByte - seitdem sind die Dinger aber etwas größer
geworden ... ;-)

Klar Auf normalen HeimPCs ist das keine Problem aber ehrklär bitte mal einem 60 jährigen Professor, der seine Arbeit noch mit einem ATARI macht, das seine Dokumetaion zwar in Signum3! locker auf seine Festplatte passt aber nicht in HTML. Abgesehen davon bin ich Grundsätzlich auch dafür die Datenmenge so klein wie möglich zu halten. Wenn ich meinem Prof. Eine fünfseitige Erklärung vorlegen kann, was ich alles getan habe um die Datenmenge zu verringen, ohne den Visualisierung und Benutzungskompfort zu beeinträchtigen, dann wird er zu frieden sein.

gruß
Unwissend

[Cybaer]

Hi,

Selbstverständlich ist es möglich bei der Generierung der finalen Version alle Elemente wieder an die Entspechenden Stellen ein zu fügen,

Also spontan würde ich dann die DHTML-Variante favorisieren.

Man könnte dann sinnvollerweise die "Doppler" in eine HTML-Datei auslagern, diese in einen (ggf. versteckten) (I)Frame oder eine zweite HTML-Seite packen und dort zur Laufzeit auslesen und in den eigentlich HTML-Text einfügen, wo entweder nur ein Platzhalter ist, oder aber ein Link auf besagten Doppler (der wäre dann auch für User ohne JavaScript nutzbar).

aber ehrklär bitte mal einem 60 jährigen Professor, der seine Arbeit noch mit einem ATARI macht, das seine Dokumetaion zwar in Signum3! locker auf seine Festplatte passt aber nicht in HTML.

Och, das würde ich wohl hinkriegen, wenn er nicht "beratungsresistent" ist. ;-)

Und bedenke dann, daß die üblichen Atari-Browser kein JavaScript beherrschen! 8-)
<img src="http://www.vampirehost.de/gruft/coding/gfabas/img/fujigraf.gif" border="0" alt="">

Gruß, Cybaer

[Ingo Turski]

Hi,

aufwändige Menustrukturen

und welche wären das? Ein sinnvolles Menü hat weniger als 10 Punkte. Diese z.B. in UL/LI kodiert und mit ausgelagertem CSS formatiert nehmen nun wirklich keinen nennenswerten Platz ein.

oder anderere komplizierte Konstrukte (Chemische fpormeln, Mathematische Umschreibungen, Grafische Konstrukte)

das sind doch typische Inhalte von neu zu ladenden Seiten. Ich verstehe nicht, was die mit einer (i)frames-Problematik zu tun haben sollen.

Ich stelle mir die Ideallösung (für mich) ungefährso vor:
<htmlelement src="http://was.weis.ich/seite.html">Hier sollte eigendlich viel mehr stehen!</htmlelement>

und genau das gibt es heute schon: Includes - serverseitig oder über entsprechende Editorfunktionen realisiert. Mit dem Vorteil, daß der Client einwe vollständige Seite erhält und zusätzliche Requests vermieden werden.

Eine Erfahrung meinerseits. Eine HTML-Dokumentation, mit SSI Ausgestattet verbrauchte 10MB, die gleiche statisch zum Download hatte 30MB. OK Komprimiert waren das dann nurnoch 2MB. Aber nicht immer kann man komprimieren.

lass mich raten: ein typisches Tabellenmonster ala GoLive oder gar Frontpage?

freundliche Grüße
Ingo

[Unwissend]

und welche wären das? Ein sinnvolles Menü hat weniger als 10
Punkte.

Und dann muß man sich durch, lass mich überlegen, im besten Fall durch 5 Seiten klicken im schlechtesten durch 30. Da halte ich ein eingrücktes uns Grafisch unterstütztes Menu für besser, auch wenn es groß wird.

oder anderere komplizierte Konstrukte (Chemische fpormeln, Mathematische Umschreibungen, Grafische Konstrukte)
das sind doch typische Inhalte von neu zu ladenden Seiten.

Klar, dann steht die halbe Formel auf einer neuen Seite, weil er Teil bei der Transformation nicht einbezogen ist. Das unterstützt nicht gerade die Lesbarkeit. Und mit Sternschen und sowas zu Arbeiten ist auch nicht das wahre, da kann man alles gleich in Word schreiben!

Ich verstehe nicht, was die mit einer (i)frames-Problematik zu tun haben sollen.

Es ging mir nie um IFrames, davon habe ich garnicht gesprochen. Ich will nur sich immer wiederholende HTML-Blöcke, die in sich nicht umbedingt abegschlossen sein müssen, in das Dokument einfügen, ohne einen Server bemühen zu müssen, oder sie Mithilfe von Programmen an die entsprechende Stelle zu setzen. Mir ging es um die Vorteile. Und ich wollte wissen, ob es das schon gibt. Es gibt es wie ich oben erfahren habe (http://forum.de.selfhtml.org/?t=80504&m=467405). Das es nicht umgesetzt ist, ist etwas anderes, das kann man ja ändern.

und genau das gibt es heute schon: Includes - serverseitig oder über entsprechende Editorfunktionen realisiert. Mit dem Vorteil, daß der Client einwe vollständige Seite erhält und zusätzliche Requests vermieden werden.

Es ist ein unterschid, ob er sich eine HTML-Seite nur einmal zieht oder ständig. Moderne Browser Fragen erst nach ob sich der Inhalt einer Seite geändert hat, bevor sie ihn sich holen. Wenn man allso häufig verwendete HTML-Blöcke auslagern kann, do kann man die effektiv übertragene Datenmenge drastisch reduzieren.

lass mich raten: ein typisches Tabellenmonster ala GoLive oder gar Frontpage?

Nein tut mir leid. Das war/ist ein mathematisches Lehrbuch. Die HTML-kodierten (mit Bildelementen) Formeln sind die Speicherfresser. Viele Teilemente wiederholen sich. Das ist in einer Formel nicht viel aber das Läppert sich, wenn man so 3000 Formeln hat, und sich ein Großteil der Formelstrukturen wiederholen. Man ist sich garnicht bewußt wie Häfig man immer gleiche Strukturen in einem HTML-Dokument verwendet. Ich habe über meine Homepage (handkodiert) ein Prorämmchen laufen lassen, daß doppelte Inhalte rausfiltern sollte. Es waren eine Menge. Meine Seite wäre glatt halb so groß geworden. Und nicht alles läst sich da mit Iframes oder Frames lösen.

gruß
Unwissend

[Swen Wacker]

Moin,

Nein tut mir leid. Das war/ist ein mathematisches Lehrbuch. Die HTML-kodierten (mit Bildelementen) Formeln sind die Speicherfresser. Viele Teilemente wiederholen sich.

Was willst Du jetzt eigentlich? Speicher auf deinem "webspace" einsparen? Oder die Ladezeit der HTML-Seite durch den Besucher verringern? Sich wiederholende Bildelemente (auf die also mehrfach verwiesen wird) sollten trotz des summierten Größe kein praktisches Probleme darstellen, da das Bild in der Regel flugs im Cache des Besuchers ist und so das wiederholte Darstellen so beschleunigt.

Man ist sich garnicht bewußt wie Häfig man immer gleiche Strukturen in einem HTML-Dokument verwendet.

Das liegt in der Natur von HTML. Das Darstellen von Markup (sofern nicht irgendwelche gigantischen Tabellenmonster oder von Word/Excel erstelltes HTML verwandt wird) geht in der Regel so schnell, dass man mit Redundanzen vernachlässigen kann.

Gruß

Swen

[Uwissend]

Moin,

Was willst Du jetzt eigentlich? Speicher auf deinem "webspace" einsparen? Oder die Ladezeit der HTML-Seite durch den Besucher verringern?

Beides. Ich suche die eirelegende Wollmilchsau. :)
Die Dokumentationen sollen ja auch lokal vorligen können ohne einem gleich die Festplatte zu zu müllen. Verwendet man Datenträger mit geringer Kapazität wie USB-Stick oder Diskette, so macht das schon ein Unterschid, ob man drei Dokus oder nur eine Halbe da drauf bekommt. Kompression ist zwar möglich aber erschwehrt den Zugriff.

Sich wiederholende Bildelemente ... sollten trotz des summierten Größe kein praktisches Probleme darstellen ...

Es sind ja Bilder in Verbindung mit aufwendigen Formatierungen zu deren Anordnung. Die Formatierungen wiederholen sich hundertfach, Sie sind verwendet wie eigene HTML-Tags.

Das liegt in der Natur von HTML. Das Darstellen von Markup (sofern nicht irgendwelche gigantischen Tabellenmonster oder von Word/Excel erstelltes HTML verwandt wird) geht in der Regel so schnell, dass man mit Redundanzen vernachlässigen kann.

Es mag ja schnell gehen und im allgemeinen nicht auffallen. Mir ist es aufgefallen und darum suche ich nach einer Lösung, doch wie es scheint gibt es sie nur Theoretisch umgsetzt scheint sie nicht zu sein.
Siehe:
http://forum.de.selfhtml.org/?t=80504&m=467405

gruß
Unwissend

[Cybaer]

Hi,

Beides. Ich suche die eirelegende Wollmilchsau. :)

Wenn Dir komprimiertes HTML nicht genügt, dann laß HTML in Ruhe und versuch dein Glück mit XML (inkl. MathML). :-)

Gruß, Cybaer

[Unwissend]

Hi,

(WO?! :)
Hallo auch

Wenn Dir komprimiertes HTML nicht genügt, dann laß HTML in Ruhe und versuch dein Glück mit XML (inkl. MathML). :-)

Wenn du mir jetzt auch einen Platformunabhängigen kostenlosen leicht zu bedinenden Betrachter bieten kannst, würde ich es gerne verwenden. Ich habe mich schon damit auseinander gesetzt, doch leider scheint es nur Konverter und keine Betrachter zu geben.

gruß
Unwissend

[Cybaer]

Hi,

doch leider scheint es nur Konverter und keine Betrachter zu geben.

Was ich damit (durch die Blume ;-)) sagen will: Du mußt nunmal mit dem Leben, was es gibt. Der Surfer muß es auch und die Platten sind groß ... ;-)

... und HTML halt nicht für das gedacht, was Du möchtest. :-)

Gruß, Cybaer

PS: Du kannst höchstens noch JavaScript zur Bedingung machen - denn mit DHTML klappt es natürlich ...

[Unwissend]

Hallo

Was ich damit (durch die Blume ;-)) sagen will: Du mußt nunmal mit
dem Leben, was es gibt. Der Surfer muß es auch und die Platten sind
groß ... ;-)

Klar, an sich sind das alles keine eklatanten Probelme. Doch für so eine Doktorarbeit muß man sich etwas ins Zeug legen. :) Da müssen alle noch so unmöglichen Richtungen erforscht und ausgeschlossen werden.

... und HTML halt nicht für das gedacht, was Du möchtest. :-)

Jo, doch das muß ich erstmal darlegen, und begründen. Warum ich was gemacht habe, wieseo ich etwas so und nicht anders mache.

PS: Du kannst höchstens noch JavaScript zur Bedingung machen - denn
mit DHTML klappt es natürlich ...

Klar das ist noch etwas was genuer Untersuchung bedarf. ;)

gruß
Unwissend

[Cybaer]

Hi,

Doch für so eine Doktorarbeit muß man sich etwas ins Zeug legen. :)

Du hast mein Verständnis, mein Mitgefühl und alle Wünsche für ein gutes Gelingen! :-))

Gruß, Cybaer

[Ingo Turski]

Hi,

Und dann muß man sich durch, lass mich überlegen, im besten Fall durch 5 Seiten klicken im schlechtesten durch 30. Da halte ich ein eingrücktes uns Grafisch unterstütztes Menu für besser, auch wenn es groß wird.

hier übertreibst Du aber ziemlich. Eine aus meiner Sicht wesentlich übersichtlichere Menülösung mit Brückenseiten erfordert soviele zusätzliche Klicks wie Menüebenen vorhanden sind. Hast Du 5 oder gar 30 Menüebenen? Und selbst wenn: übersichtlich ließe sich das innerhalb eines Menüs wohl nicht gestalten.

Was die Problematik mit den Formeln betrifft: ich kann mich an einen Thread erinnern, wo hierüber diskutiert wurde. Und die Möglichkeit, Formeln zu benennen und hierauf Bezug zu nehmen, anstatt sie immer komplett neu einzufügen, fand ich eigentlich recht sinnvoll.

freundliche Grüße
Ingo

[dbenzhuser]

N'Obend

X-Frames werden das (falls sie denn wirklich kommen) in Zukunft, auch mit neueren Standards, valide machen können.
Kenne ich nicht, was sollen die denn genau können?

http://www.jendryschik.de/TR/xframes/ (dt)
http://www.w3.org/TR/xframes/ (eng)

Im Prinzip nix anderes als Frames, jetzt als XHTML-Modul. Es wird nur versucht ein paar der klassischen Nachteile von Frames zu entfernen. Ich persönlich sehe für mich momentan dennoch keinen Nutzen darin.

(PS: Nein ich hab Perl nicht vergessen :) )
und Phyton und C und Pascal und VBasic und ... und ... und ... :)

Die aber im Web recht selten eingesetzt werden.
Die Perl-Fans bekommen nur recht schnell einen Herzkasper wenn man sie vergisst, um ihnen das absichtlich anzutun sind sie einfach zu süß...

Unwissend

Den Nick halte ich für nicht uneingeschrenkt zutreffend.

Tschö,
dbenzhuser

[Unwissend]

Hallo

http://www.jendryschik.de/TR/xframes/ (dt)
http://www.w3.org/TR/xframes/ (eng)

Danke das hilft mir schon.

Ich persönlich sehe für mich momentan dennoch keinen Nutzen darin.

Mir kommen durchaus Ideen wo man so etwas einsetzen könnte. Und manchmal kann es soweit ich das sehe durchaus brauchbar und Praktisch sein.

und Phyton und C und Pascal und VBasic ...
Die aber im Web recht selten eingesetzt werden.

Python ist garneicht mehr so selten und es würde dich überraschen wie häufg c eingesetzt wird. (Vorallem zeitkritische oder auswendige Aplikationen werden gerne darin geschrieben.)

Die Perl-Fans bekommen nur recht schnell einen Herzkasper wenn man
sie vergisst.

Nichts gegen Perlfans ich bin auch einer. Eine wunderbare Sprache um mal eben schnell etwas zu machen. Python ist auch nicht schlecht und C mit PHP habe ich so meine Probleme. Ähnlich wie bei Java hat man eine Durchmischung von einer Sprach mit einem Dokumentaonsform. Ich bin da eher für saubere Trennungen.

Unwissend
Den Nick halte ich für nicht uneingeschrenkt zutreffend.

Danke, danke :-)

bis dann
Unwissend

[Swen Wacker]

Moin,

Weis jemand ob und wann das kommen wird? Und ich meine nicht SSI-Tags.

Das ist eingentlich schon immer da :-)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY kapitel.1 SYSTEM "kapitel1.sgml">
<!ENTITY kapitel.2 SYSTEM "kapitel2.sgml">
<!ENTITY kapitel.3 SYSTEM "kapitel3.sgml">
]>

<html>
  <!-- Jetzt werden die Kapitel über die Entitäten eingebunden -->
  &kapitel.1;
  &kapitel.2;
  &kapitel.3;
</html>

Pferdefuß: Ich kenne keine Browser, der das unterstützt :-)

Gruß

Swen
(Das Beispiel habe ich aus der Free-BSD-Fibel kopiert)

[Unwissend]

Moin,

Dito

Das ist eingentlich schon immer da :-)

Kann ja sein aber ich wußte es nicht.

Pferdefuß: Ich kenne keine Browser, der das unterstützt :-)

Das wäre genau das was ich suche! Zu ärgerlich, daß es nicht unterstützt wird.
Obwohl ... Mozilla (und kompatible) mßte man doch zu sowas überreden können. Da sind doch alle HTML-Elemente und deren Verhalten in extra Dateien kodiert. Da sollte es doch möglich sein, etwas hin zu bekommen.

Danke
Unwissend