Doctype wirklich "unbedingt" erforderlich?
-
Reyx schrieb:
3. der Internet Explorer, sowohl Version 6 als auch 7, unterstützen sehr wohl XHTML! Bitte nicht immer solche falschen Unterstellungen! Die Unterstützung ist, im 6er, zwar bei weitem nicht perfekt, aber zu sagen er unterstützte "überhaupt kein XHTML" ist schlichtweg falsch!
Wenn man keine Ahnung hat, einfach mal die Klappe halten.
Ich hab's mir schon im letzten Thread gedacht, in dem du groß von deinem "XHTML 1.1 Strict" getönt hast. Jetzt hast du es dankenswerterweise bestätigt. Nur weil du XHTML falsch verwendest und die Fehlerbehandlung des IE etwas brauchbares aus deinen Seiten produziert, bedeutet nicht, dass der IE auch XHTML unterstützt.
Es ist schon eine Ironie für sich, wie du großspurig und selbstüberzeugt andere belehrst, und dabei genau das, was du anderen ankreidest, selbst falsch machst. Es ist zwar ganz nett, dass sich in dem Forum hier die Leute gerne selbst lächerlich machen, aber solche Möchtegerne wie du sind wirklich nervig.Es gibt etwas total abgefahrenes, das nennt sich MIME-Type. Noch nie gehört? Merk ich. Mit dem MIME-Type gibt der Webserver die Art der Daten an.
HTML hat den MIME-Type "text/html". Empfängt der Browser etwas mit diesem MIME-Type, rendert er es als HTML.
XHTML dagegen hat den MIME-Type "application/xhtml+xml". Nur wenn dieser MIME-Type gesetzt ist, werden die Daten als XHTML verarbeitet.
Wenn du schlau bist, merkst du jetzt schon, worauf es hinausläuft ...Der IE 6 und auch der IE 7 unterstützen kein XHTML. Sie beherrschen den MIME-Type "application/xhtml+xml" nicht. Gründe dafür kannst du gerne dem Blog der IE7-Entwickler entnehmen (kurz gesagt: die Engine des IE, welche immerhin vom IE 4(!) stammt, müsste dafür vollständig neu geschrieben werden). Du kannst gerne mal versuchen deine Seiten als XHTML an einen IE auszuliefern ...
Nun zu dir. Du lieferst dein XHTML als "text/html" aus. Das heißt auf gut deutsch, dass du dir nur einbildest XHTML zu verwenden. In Wirklichkeit werden deine Seiten aber als fehlerhaftes HTML gerendert und dargestellt. Von XHTML keine Spur. Mit "text/html" hat der IE natürlich auch keine Probleme.
Denn HTML kennt er.Und weil ich so ein netter Kerl bin, erzähl ich dir auch gleich was es mit XHTML 1.0 und XHTML 1.1 auf sich hat.
XHTML 1.0 ist als abwärtskompatible Variante von XHTML gedacht. Deswegen ist es bei XHTML 1.0 als einzige(!) XHTML-Variante explizit ok sie als "text/html" auszuliefern. Bei XHTML 1.1, also was du verwendest, um "cool" zu sein, ist das dagegen nicht ok. XHTML 1.1 ist nur als "application/xhtml+xml" auszuliefern - und damit kann der IE eben nichts anfangen.
Nochmal zum nachlesen:
http://www.w3.org/TR/xhtml-media-types/#summary"Better to remain silent and be thought a fool than to speak out and remove all doubt." (Abraham Lincoln)
Wenn ich nur jedes mal einen Euro bekommen würde, wenn dieser Spruch zutrifft, ich wäre reich
-
Bei XHTML 1.1, also was du verwendest, um "cool" zu sein, ist das dagegen nicht ok. XHTML 1.1 ist nur als "application/xhtml+xml" auszuliefern - und damit kann der IE eben nichts anfangen.
Wie leitest du das aus "SHOULD NOT" her? Das ich damit dann auch den IE füttern kann halte ich für "may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful"
MfG SideWinder
-
Zum ersten: Das XHTML 1.1 Strict war ein Flüchtigkeitsfehler, dass es das nicht gibt ist mir bewusst.
Zum zweiten: Woher nimmst du bitte die Dreistigkeit, mir anzukreiden, ich würde meine Webseiten mit falschen MIME-Type ausliefern? Zu deiner Information, das tu ich nämlich nicht; der Kompatibilität halber beliefere ich ausschließlich den IE und einige andere Empfänger, wie z.B. Google (weil die z.B. mit application/xhtml+xml auch nicht klar kommen! Was sagst du dazu! Ist Google jetzt auch scheiße und baut auf antiker Technik?) mit einem einfachen text/html-MIME. Und die Unwissenheit, ja gerade zu Dummheit, die du mir hier haltlos und auf einer Dichterei deinerseits basierend anheißen willst, beleidigt mich durchaus! Also entweder deine Behauptungen auf stichhaltigen Fakten begründen (zeige mir meine Seite, die falsch geschrieben ist, und mit der ich es "genau so falsch mache" wie alle die, denen ich es hier ankreide) oder du lässt es! Auf diesem Niveau diskutiere ich nämlich nicht weiter.
Die Rede war hier vom interpretieren von XHTML, nicht jedoch von den Empfehlungen des W3C auf das Zusammenspiel mit dem HTTP-Protokoll. Zudem siehe SideWinders Post.
Ferner verwende ich XHTML 1.1 nicht um "cool" zu sein; mit solchen kindlichen Wortandichtungen brauchst du mir nicht kommen. Ich verwende es, weil ich bisher immer sehr gut damit gefahren bin und nie größere Kompatibilitätsprobleme hatte. Das ist Fakt, und wenn du etwas anderes behaupten solltest, wäre das anmaßend.
-
Reyx schrieb:
Der Browser fällt zurück zum Quirks Mode, weil er davon ausgehen muss, dass dieser die gewählte Technik am ehesten repräsentiert! Er nimmt eine Fehlerbehandlung vor, die du bewusst einbauen willst! Das ist fahrlässig, wird vom W3C (aus gutem Grunde) nicht gutgeheißen und ist schlichtweg falsches HTML!
macht aber nix. das ergebnis zählt, nämlich dass möglichst viele browser es (wie gewollt) darstellen können. es geht nicht darum alles standardkonform zu machen, nur um hinterher über die unfähigkeit der browserhersteller zu wettern
-
SideWinder schrieb:
Bei XHTML 1.1, also was du verwendest, um "cool" zu sein, ist das dagegen nicht ok. XHTML 1.1 ist nur als "application/xhtml+xml" auszuliefern - und damit kann der IE eben nichts anfangen.
Wie leitest du das aus "SHOULD NOT" her? Das ich damit dann auch den IE füttern kann halte ich für "may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful"
Selbstverfreilich ist das im Einzelfall eine Notlösung, die man bei XHTML 1.1 ergreifen kann (Stichwort "Content Negotiation"!). Wenn man aber weiß, dass man sowieso nur "text/html" verwendet, dann ist XHTML 1.0 die einzig sinnvolle Möglichkeit. Der Grund dafür liegt auf der Hand, XHTML 1.0 ist eine Neuformulierung von HTML 4 in XML. XHTML 1.1 dagegen verhält sich fundamental anders (modulbasiert) und streicht diverse Tags und Attribute von HTML 4.
XHTML 1.1 standardmäßig als "text/html" auszuliefern - also selbst XHTML-fähigen Browsern - ist der größte Schwachfug, den man überhaupt machen kann. Und genau das ist eben mit "SHOULD NOT" ausgedrücktReyx schrieb:
Zum zweiten: Woher nimmst du bitte die Dreistigkeit, mir anzukreiden, ich würde meine Webseiten mit falschen MIME-Type ausliefern?
Weil es die sinnvolle Interpretation deiner bisheren Beiträge ist.
1. Du hast offensichtlich keine Ahnung von der Bedeutung und den Auswirkungen von "text/html" und "application/xhtml+xml" (siehe z.B. deinen aktuellen Beitrag "Die Rede war hier vom interpretieren von XHTML, nicht jedoch von den Empfehlungen des W3C auf das Zusammenspiel mit dem HTTP-Protokoll.").
2. Deine Behauptung, dass man ganz einfach XHTML+CSS schreibt und alle Browser es sofort richtig machen, zusammen mit deiner Betonung, dass du keinerlei serverseitiges Skript verwendest, legt nahe, dass du jedem Browser exakt das selbe auslieferst. Und das heißt dann eben auch "text/html".
Wenn du das Content Negotation aber mit dem Webserver machst, und die Browser eben nicht identisch beliefert werden, stellt sich die Frage, was du mit deiner Betonung von keinen Skripten überhaupt betonen willst ...
-
Ja, das möglichst viele Browser es möglichst gleich darstellen! Die Quirks Modes fallen aber bei den mir bekannten Browsern wesentlich unterschiedlicher aus, als die korrekt arbeitenden Renderer, auch wenn das früher vielleicht einmal anders war. Ich musste immer sehr viel "umfrickeln" um bei HTML 4.01 alles so dargestellt zu bekommen, das es überall gleich aussah (da war der Quirks Mode wohl tatsächlich eine Erleichterung), aber das habe ich bei XHTML nicht mehr!
Aber es ist natürlich jedem selbst überlassen, was er macht und was nicht. Trotzdem ist es in meinen Augen ein Fehler. Ihr funktionalisiert den Browser zu einem fehlerbehebenden Interpreter um. Würdet ihr einen Compiler genau so bevorzugen, der euch Fehler im Quellcode eurer Programme nach eigenem Ermessen stillschweigend retuschiert? Aber bitte ...
EDIT:
@minhen
Wenn du meinen Post, über den du dich so auslässt, tatsächlich mit einer Aufmerksamkeit gelesen hättest, die deine Argumentation hier rechtfertigen würde, dann währe dir aufgefallen, das ich keine clientseitigen Scripts verwende! Zur Information: Das wäre z.B. JavaScript undhat mit einem MIME-Type oder dem, was beim Browser landet, nichts zu tun. Also bitte noch einmal lesen und noch einmal nachdenken.Ferner scheinst du meine Post so auszulegen, wie es dir passt. Du sagst ich würde die "Wichtigkeit" des MIME-Types unterschätzen. Das tue ich ganz sicher nicht. Aber der MIME-Type ist und bleibt Bestandteil des HTTP-Protokolls, was der Browser daraus macht ist seine Sache. Mehr habe ich nicht ausgesagt, und wenn du mir jetzt erzählen willst, der MIME-Type würde zum HTTP-Protokoll gehören, dann bin ich auf gute Quellen erster Hand, die das belegen, gespannt!
Und zu deinem Text über den MIME-Type von XHTML 1.1: Ich stimme dir voll und ganz zu! Aber von einem standardmäßigen Ausliefern von XHTML 1.1 - Dokumenten als text/html war hier keine Rede!
2. Deine Behauptung, dass man ganz einfach XHTML+CSS schreibt und alle Browser es sofort richtig machen
Auch das habe ich nie ausgesagt.
-
Nun, dann bitte ich darum, dass hier jemand ein schlichtes Beispiel postet, wie man unter HTML 4.01 (kein XHTML) Das Wort "Test" exakt in der Mitte des Browserfensters darstellt... also horizontal und vertikal zentriert...
-
Da du noh HTML 4.01 verwendest sollte das so sehr einfach von statten gehen:
<center>Test</center>
ist aber bereits deprecated.
MfG SideWinder
-
Nein, das wird oben zentriert, ich miente aber auch vertikal, was gerade das PRoblem darstellt...
-
Reyx schrieb:
@Mr. B
Der <center>-Tag ist in HTML 4.01 deprecated, aber afaik nicht falsch. Das Attribut align hingegen ist im Standard enthalten. In XHTML 1.0 ist center afair nicht mehr vorhanden und das Attribut align deprecated. In XHTML 1.1 (und 1.0 Strict? Da bin ich mir jetzt nicht sicher ...) ist beides ein Fehler, da setzt man (zu Recht) auf die viel flexibleren und durchdachteren Stylesheets.aber was ist bitte der vorteil, wenn man sämtliche tags, die das aussehen der datei beeinflussen, in eine andere datei verbannt? ich seh da einfach keinen vorteil...
Mr. B
-
Um es mal etwas zu verdeutlichen:
Test
Soetwas suche ich.
-
Mr. B schrieb:
aber was ist bitte der vorteil, wenn man sämtliche tags, die das aussehen der datei beeinflussen, in eine andere datei verbannt? ich seh da einfach keinen vorteil...
Na ist doch ganz einfach: Du hast jetzt eine Datei, in der der Inhalt spezifiziert wird und eine zweite, in der das Aussehen spezifiziert wird. Das eine läßt sich nun unabhängig vom anderen verändern. Da Aussehen und Inhalt in gewisser Weise orthogonal zueinander sind, ist es doch ganz nett die beiden auch unabhängig voneinander variieren zu können.
-
Jester schrieb:
Mr. B schrieb:
aber was ist bitte der vorteil, wenn man sämtliche tags, die das aussehen der datei beeinflussen, in eine andere datei verbannt? ich seh da einfach keinen vorteil...
Na ist doch ganz einfach: Du hast jetzt eine Datei, in der der Inhalt spezifiziert wird und eine zweite, in der das Aussehen spezifiziert wird. Das eine läßt sich nun unabhängig vom anderen verändern. Da Aussehen und Inhalt in gewisser Weise orthogonal zueinander sind, ist es doch ganz nett die beiden auch unabhängig voneinander variieren zu können.
das kann man jetzt mit HTML 4.01 auch. nur kann man es eben auch in einer datei zusammenschreiben. das bietet doch so gesehen noch mehr möglichkeiten: einmal die variante alles zusammenschreiben oder, wer will, beides zu trennen.
wieso also der zwang zur trennung?
Mr. B
-
Mr. B schrieb:
das kann man jetzt mit HTML 4.01 auch. nur kann man es eben auch in einer datei zusammenschreiben. das bietet doch so gesehen noch mehr möglichkeiten: einmal die variante alles zusammenschreiben oder, wer will, beides zu trennen.
Naja, goto biete zum Beispiel auch "mehr Möglichkeiten", als for- und while-Schleifen. Trotzdem benutzt man es seltener bzw. manche Sprachen haben es garnicht erst.
Manchmal muß man die Leute halt zu ihrem Glück zwingen.
-
Könnte man jetzt bitte zum Thema zurückkehren?
Sphy schrieb:
Test
Soetwas suche ich.
Mir ist jetzt egal, ob HTML 4.01 oder sonst irgendetwas, wie bekommt man das nun so hin, dass ter Text horizontal und vertikal zentriert ist, auf der Seite?
-
@Jester
Ich hätte einfach noch das Argument gebracht, wenn man mit mehreren Seiten arbeitet; dann wäre jedwede Diskussion sofort hinfällig@Sphy
Ich würde dir raten, es mit CSS "vertical-align: middle; text-align: center;" zu versuchen. Das sollte soweit eigentlich funktionieren. Wie du das Parent-Objekt aber auf immer 100% der verfügbaren Höhe bekommst, ist dir überlassen und kommt auch auf die weiteren Umstände an ...
-
Parent-Objektz wäre body... nur scheint da die Höhe nicht wirklich definiert zu sein, denn wenn ich das darauf anwende (hatte ich schonmal versucht), bekam ich das auch nur oben zentriert...
-
...und was ist das Elter vom body? Wenn schon in der Hirarchie nach oben, dann bis zur Spitze...
-
Sphy schrieb:
Um es mal etwas zu verdeutlichen:
Test
Soetwas suche ich.
Das ist nicht ganz einfach. Mit purem HTML ist mir nichts bekannt, was das Problem lösen könnte. Ich kenne nur eine Lösung mit (X)HTML+CSS, bei der der Text aber in einem absolut positionierten block-Element stehen muss (nicht so schlimm) und die Höhe und Breite des block-Elements bekannt sein müssen (schon schlimmer, da unflexibel).
Zuerst formatiert man das block-Element so, dass dessen linke obere Ecke in der Mitte des Browserfensters ist:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <title>Test</title> <style type="text/css"> div.centered { position:absolute; top:50%; left:50%; text-align:center; } </style> </head> <body> <div class="centered">Test</div> </body> </html>
Wenn es so wie oben nur ein kurzes Wort ist, braucht man den Code jetzt nicht unbedingt weiter anpassen, denn es ist nur um einige Pixel vom Zentrum verschoben.
Will man aber einen größeren Inhalt, muss man Höhe und Breite des Elements festlegen und das Element um die Hälfte der Höhe bzw. Breite nach oben bzw. links verschieben. Siehe dazu hier.
-
Das ist nicht ganz korrekt, hier beginnt das Objekt in der Mitte und von dort aus nach unten rechts... es soll aber exakt zentriert liegen...