nicht angemeldet
Doctype selfhtml
0 XHTML auch falsch
1 0 Sogar in Strict
1 0 0
0 Eine Frage habe ich noch
Doctype selfhtml
Hallo,
laut Selfhtml gibt es nur eine Doctypeangabe für normale HTML Seiten,
wenn man die Strict-Variante ablehnt.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Dabei ist es laut Selfhtml egal ob mit oder ohne URL-Angabe der Dokumenttyp-Definition (DTD), mit der Bemerkung, die meissten Browser würden eh diese URL eh nicht beachten.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
Das ist schon mal nicht richtig.
Je nachdem was dem folgende Code vorgestzt wird, entsteht etwas völlig anderes.
#################################################
<html>
<head>
<title>test</title>
<meta http-equiv="pragma" content="no-cache">
<style type="text/css">
<!--
body{margin:0px;background-color:#00AFFF;border:10px solid red;}
-->
</style>
</head>
<body>
<p>xxxxxxxxxxxxx </p>
</body>
</html>
####################################################
Gut jetzt habe ich natürlich etwas über den Quirksmode gelesen, bringt mich aber auch nicht wirklich weiter. Ich möchte doch nur eine Möglichkeit haben, ohne die Strict-Restrictionen eine HTML Datei zu erzeugen die ohne diesen Quirksmode läuft.
Genauer gesagt läuft bei diesem Beispiel die Seite nur sauber ohne die DTD-URL und das kann es ja nicht wirklich sein. Wäre mir zu unzuverlässig diese Methode.
Was mache ich da?
Pete
* IE6 SP2
-
Ich habe in der Zwischenzeit mal die XHTML-Variante probiert.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">Es entsteht auch hier die fehlerhafte Ausgabe.
Pete
-
Hallo,
Ich habe in der Zwischenzeit mal die XHTML-Variante probiert.
Es entsteht auch hier die fehlerhafte Ausgabe.Nein, es entsteht eine Ausgabe, die von dir nicht gewünscht ist. Versuche dein Ziel mithilfe der definierten Standards zu erreichen, dann werden deine Dokumente auch browserunabhängig.
Zu XHTML: Wenn du XHTML-Quelltext als text/html versendest wird es ganz normal als HTML verarbeitet, inklusive Dokumenttypweiche.
Nur XHTML, das als XML, also application/xhtml+xml versendet wird, wird immer im standardkonformen Modus des browsers verarbeitet.
Gruß
-
-
Hallo,
laut Selfhtml gibt es nur eine Doctypeangabe für normale HTML Seiten,
wenn man die Strict-Variante ablehnt.Jain. In welcher Variante bzw. mit den Regeln welcher Variante du ein Dokument schreiben möchtest, bestimmst du über die Dokumenttypangabe.
Die Dokumenttypangaben der HTML-Varianten kannst du mit und ohne URI-Angabe (sog. System-Identifier) einfügen.
Dabei ist es laut Selfhtml egal ob mit oder ohne URL-Angabe der Dokumenttyp-Definition (DTD), mit der Bemerkung, die meissten Browser würden eh diese URL eh nicht beachten.
Richtig. Ein Browser kennt keine HTML-Strict- oder -Transitional-Dokumente. Er kennt nur HTML-Dokumente. Daher ist die Angabe des Dokumenttyps erstmal ohne Bedeutung.
Es stimmt auch, dass die Browser die URI-Angabe nicht auswerten, in dem Sinn, dass die DTD geladen und verarbeitet wird.
Je nachdem was dem folgende Code vorgestzt wird, entsteht etwas völlig anderes.
Ja, und da spielt folgendes durchaus eine Rolle:
Gut jetzt habe ich natürlich etwas über den Quirksmode gelesen, bringt mich aber auch nicht wirklich weiter. Ich möchte doch nur eine Möglichkeit haben, ohne die Strict-Restrictionen eine HTML Datei zu erzeugen die ohne diesen Quirksmode läuft.
Vor langer Zeit hat man sich dazu entschlossen, anhand der Beschaffenheit der Dokumenttypangabe verschiedene Verarbeitungsmodi im Browser zu aktivieren.
Transitional-Doctypes mit URI-Angabe aktivieren dabei einen Modus, der zwar standardnah ist, aber ein paar Ausgewählte Fehler dennoch erlaubt.
Ohne URI-Angabe verwenden die Browser ihren Fehlermodus (Quirksmode).Wenn du dich mehr über die verschiedenen Verarbeitungsmodi der Browser informieren möchtest, empfehle ich dir den Artikel „Der DOCTYPE-Switch und seine Auswirkungen“.
Genauer gesagt läuft bei diesem Beispiel die Seite nur sauber ohne die DTD-URL und das kann es ja nicht wirklich sein. Wäre mir zu unzuverlässig diese Methode.
Richtig, denn die Quirksmodi sind unzuverlässig und können keine Browserweit ähnliche Verabreitung garantieren.
Was mache ich da?
Arbeite immer in einem standardkonformen Modus. Versuche, deine Ziele mit Hilfe der definierten Standards zu erreichen.
Gruß.
-
Hallo Daniel,
Arbeite immer in einem standardkonformen Modus. Versuche, deine Ziele mit Hilfe der definierten Standards zu erreichen.
Danke für die Infos, aber helfen wird mir das wohl nicht.
Der Fehler der entsteht [wenn ich die URL-Angebe mache] ist, dass der eigentliche Bereich(BODY) nicht bis zum Fensterende unten reicht. Seltsam daran, dass dieser Fehler ausgrechnet auftaucht wenn ich dem Browser durch die URL sage wo er die Infos für die richtige Darstellung findet.
Wenn ich nun aber mal (trotz Widerwillen) die Striktvariante nehme, dann
sehe ich den gleichen Fehler. Fehler? Sag mal mache ich hier einen Denkfehler oder was?Was ist richtig, wenn in meinem Code der rote Rahmen bis Unterkante Browserfenster reicht oder nicht?
Pete
-
Hallo,
Der Fehler der entsteht [wenn ich die URL-Angebe mache] ist, dass der eigentliche Bereich(BODY) nicht bis zum Fensterende unten reicht. Seltsam daran, dass dieser Fehler ausgrechnet auftaucht wenn ich dem Browser durch die URL sage wo er die Infos für die richtige Darstellung findet.
body ist auch nur so groß wie sein Inhalt. Das ist wie bei jedem anderen Blockelement auch.
Was dich verwirrt ist vermutlich die „magische“ Eigenschaft des body-Elements (Hintergrundfarbe und -bild werden auf das html-Element angewendet, anstatt auf das body-Element, für die die Eigenschaften definiert sind).
Definiere für das html- und body-Element verschiedene Hintergrundfarben, das könnte dir die Sache klarer machen.
Wenn ich nun aber mal (trotz Widerwillen) die Striktvariante nehme
Wieso wiederwillig?
dann sehe ich den gleichen Fehler. Fehler? Sag mal mache ich hier einen Denkfehler oder was?
Was ist richtig, wenn in meinem Code der rote Rahmen bis Unterkante Browserfenster reicht oder nicht?Wenn er das nicht tut.
Gruß
-
Hallo Daniel,
diese Antwort war sehr interessant, danke.body ist auch nur so groß wie sein Inhalt. Das ist wie bei jedem anderen Blockelement auch.
Bin eigentlich kein Anfänger, aber das wusste ich echt nicht.
Was dich verwirrt ist vermutlich die „magische“ Eigenschaft des body-Elements (Hintergrundfarbe und -bild werden auf das html-Element angewendet, anstatt auf das body-Element, für die die Eigenschaften definiert sind).
Definiere für das html- und body-Element verschiedene Hintergrundfarben, das könnte dir die Sache klarer machen.
Ebenso wenig wusste ich demzufolge, dass man dem HTML-Element auch Eigenschaften zuweisen kann. Ich glaube das wissen viele nicht, weil wir am Anfang alle lernen: Hintergrundfarbe=Bodyanweisung.
Wenn ich nun aber mal (trotz Widerwillen) die Striktvariante nehme
Wieso wiederwillig?
Weil ich nicht einsehen kann, dass IFRAMES verboten sind, während Ajax-Anwendungen sich so grosser Beleibtheit erfreuen, welche sich wesentlich resourceschonender, schneller und barrierefreier mit einem Iframe realisieren lassen.
Und wegen diese Ignoranz der Entscheidungsträger in Sachen Strict, hasse ich die Variante Strict.
Nochmals, vielen Dank
Pete-
Hallo,
diese Antwort war sehr interessant, danke.
Freut mich :)
Ebenso wenig wusste ich demzufolge, dass man dem HTML-Element auch Eigenschaften zuweisen kann. Ich glaube das wissen viele nicht, weil wir am Anfang alle lernen: Hintergrundfarbe=Bodyanweisung.
Leider gibts nicht nur gute Lehrer auf der Welt.
Weil ich nicht einsehen kann, dass IFRAMES verboten sind, während Ajax-Anwendungen sich so grosser Beleibtheit erfreuen, welche sich wesentlich resourceschonender, schneller und barrierefreier mit einem Iframe realisieren lassen.
Nun, kaum einer, der heute etwas in Ajax erstellt würde lieber Iframes nehmen. Könnte man nämlich, weil diese Seiten meist Transitional-Doctypes verwenden. Die Browserhersteller reagieren darauf ja auch, so wird sich in allen kommenden Browserversionen (von IE bis Safari) die Performance verbessern, Speicherverbrauch reduzieren usw.
Und wegen diese Ignoranz der Entscheidungsträger in Sachen Strict, hasse ich die Variante Strict.
Naja, 1997/98 konnte man wirklich nicht wissen, dass in 10 Jahren JavaScript eine so große Bedeutung gewinnen würde.
Falls es dich interessiert. Der aktuelle Entwurf für HTML5 enthält iframe als erlaubtes Element und erlaubt es auch, Ajax-Seiten über die Vor- und Zurückhistory des Browsers bedienbar zu machen.
Gruß
-
Daniel,
Leider gibts nicht nur gute Lehrer auf der Welt.
scheint so ;-)
Nun, kaum einer, der heute etwas in Ajax erstellt würde lieber Iframes nehmen. »»
In den meissten Fällen, weil ihnen diese Option gar nicht in den Sinn kommt.
Naja, 1997/98 konnte man wirklich nicht wissen, dass in 10 Jahren JavaScript eine so große Bedeutung gewinnen würde.
Es geht ja auch nicht um JS, sondern schon damals gab es die Frameliebhaber und die Framehasser. Und gerade damals war ein wesentlicher Vorteil von Frames/IFRAMES, dass eben nicht eine ganze Seite erneut geladen werden muss und dem Besucher ein wesentlich schnellerer Seitenaufbau gewährleistet wurde. Das mag zwar heute nicht mehr so im vordergrund stehen aufgrund DSL, usw, aber die Beleibtheit von Ajax zeigt eben, das es Viele eben schöner finden wenn sich lediglich kleine Bereiche
einer Seite ändern anstatt Komplett.Falls es dich interessiert. Der aktuelle Entwurf für HTML5 enthält iframe als erlaubtes Element und erlaubt es auch, Ajax-Seiten über die Vor- und Zurückhistory des Browsers bedienbar zu machen.
Du meinst für die Variante Strict? Dann würde ich sofort diese Variante bevorzugen.
Gruss
Pete-
Hallo,
Es geht ja auch nicht um JS, sondern schon damals gab es die Frameliebhaber und die Framehasser. Und gerade damals war ein wesentlicher Vorteil von Frames/IFRAMES, dass eben nicht eine ganze Seite erneut geladen werden muss und dem Besucher ein wesentlich schnellerer Seitenaufbau gewährleistet wurde. Das mag zwar heute nicht mehr so im vordergrund stehen aufgrund DSL, usw, aber die Beleibtheit von Ajax zeigt eben, das es Viele eben schöner finden wenn sich lediglich kleine Bereiche
einer Seite ändern anstatt Komplett.Naja, Frames haben schon einige Nachteile und falsche Vorteile, das sollte man bei allem nicht vergessen. Trifft auch auf Ajax zu, falls dichd as beruhigt. Ich will darüber aber keine Diskussion starten.
Du meinst für die Variante Strict? Dann würde ich sofort diese Variante bevorzugen.
Nein, es wird nur ein HTML5 geben (ok, auch als XML-Variante, aber das istw as ganz anderes). Wie ich sagte kennt der Browser keine HTML-Strict- oder -Transitional-Dokumenet. HTML5 ist so definiert, dass jedes HTML-Dokument automatisch zu einem HTML5-Dokument wird und, falls es das mal gibt, automatisch zu einem HTML6-Dokument werden würde.
Das macht manchen Leuten zwar zu schaffen, auch mir, da bestimmte Teile der Strict-Variante aufgehoben werden und ein bisschen älterer Ballast wieder hinzukommt, aber vermutlich braucht man im Web einfach iframes. Es gibt ja zum Glück auch sehr gute Neuerungen.
Gruß
-
-
-
-
-
-
-
Hallo Daniel,
eine Sache noch.
Das ich dem Element <HTML> die Eigenschaft "background-color" zuweisen kann weiss ich nun, dank dir, und es klappt auch. Jetzt habe ich mir mal die Mühe gemacht und versucht etwas darüber im Netz zu finden. Ich finde leider immer nur die Hinweise auf den "body" auch im selfhtml. http://de.selfhtml.org/css/eigenschaften/hintergrund.htm#background_color.
Dabei macht das HTML-Element doch wesentlich mehr Sinn. Nur in der Regel fällt es ja auch nicht auf, wegen "magisch", aber mir war es aufgefallen, weil etwas eben nicht klappte.
Da den meissten beim Thema "Hintergrund" ein komplettes Einfärben des Fensterhintergrundes vorschwebt und "body" das fälschlicherweise auch so macht, ist es doch definitiv falsch den body-tag dafür zu nutzen.
Kennst du einige Links die auf auf diesen Umstand hinweisen?
Selfhtml zumindest ist da ausnahmsweise keine erste Wahl.Gruss
Pete-
Hallo,
Kennst du einige Links die auf auf diesen Umstand hinweisen?
Gute Frage. CSS 2.1 weist momentan kurz darauf im Abschnitt 14.2 hin.
Dort wird empfohlen, dass man Hintergrundfarbe für body definiert. Ich finde das keine gute Empfehlung, da es den Übergang zu XHTML erschwert.
Wie man im selben Absatz lesen kann gibt es diese Regelung nicht für XHTML. Daran halten sich momentan aber Firefox und neure Safari. CSS 2.1 überlegt daher, ob man XHTMLs body-Element nicht auch magisch macht.
Das macht Firefox 3 sogar, im Gegensatz zu Opera, die das vermeintlich endlich richtig gemacht haben. Da gibts also durchaus Verarbeitungsunterschiede. Daher ist man mit der Definition von Hintergründen für das html-Element immer auf der sicheren Seite. Und CSS 2.1 ist ja auch noch nicht ganz fertig.
Schade nur, dass auch viele sogenanne XHTML-Experten wie Michael Jendryschik das nicht Wissen. In seinem Buch „Einführung in XHTML, CSS und Webdesign“ definiert er im Abschnitt „Farben und Hintergründe“ seine Angaben auch nur für das body-Element.
Daher gibts je nach Browser Anzeigeunterschiede, wenn man sich das entsprechende Beispiel als HTML verarbeitet und als XML verarbeitet ansieht.
Wahrscheinlich wissen es nur diejenigen, die die CSS-Spezifikation auch gelesen haben, falls überhaupt.
Gruß
-