XHTML - eigentlich nur case sensitive, CSS und Endtags?

[Tobi]

Hallo,

ich moechte einen XHTML konformen Code erstellen.

Habe ich das richtig verstanden, dass folgende zu beachtende Punkte schon alles im Vergleich zu normalem HTML (4.0) sind?

• case sensitive
• ausschliesslich CSS
• Endtags, e.g. <br />
• einige wenige Attribute, e.g. noshade

Das waere ja zu einfach....;o)

Gruss & Danke fuer die Antworten,
Tobi

[Christian Seiler]

Hallo Tobi,

ich moechte einen XHTML konformen Code erstellen.

Warum?

• case sensitive

Richtig. In XHTML wird _alles_ kleingeschrieben - auch onclick, onmouseover und so. (häufiger Fehler)

• ausschliesslich CSS

Falsch. Wie kommst Du darauf?

• Endtags, e.g. <br />

Richtig.

• einige wenige Attribute, e.g. noshade

Richtig. Leere Attribute müssen immer noch einen Wert enthalten, also wie in Deinem Beispiel noshade="noshade".

Ach ja, http://selfhtml.teamone.de/html/xhtml/unterschiede.htm.

Das waere ja zu einfach....;o)

Och, das ist schon eine ganze Menge.

Christian

[Tobi]

Moin Christian,

Warum?

Hmm...eigentlich wollte ich mit meinem Coding auf der Hoehe der Zeit bleiben, daher etwas mehr Richtung XHTML und XML gehen....oder ist das alles nur Bloedsinn und ich sollte beim HTML 4.0 bleiben?
Die Idee von XML, wieder eine Beschreibungssprache mit strikter Trennung von Form und Inhalt, finde ich eigentlich logisch und gut...auch im Hinblick auf die vielseitige Einsetzbarkeit und Kompatibilitaet des XML Formates, Import in Anwendungen usw.

• ausschliesslich CSS

Falsch. Wie kommst Du darauf?

Ja, hast recht...ich hatte an den font Tag gedacht, aber der war ja schon bei HTML 4.0 nicht mehr okay, oder?

Ach ja, http://selfhtml.teamone.de/html/xhtml/unterschiede.htm.

Jaq, genau das habe ich vorher gelesen, aber wollte nachfragen, ob ichs richtig verstanden habe, weil ....

Das waere ja zu einfach....;o)

Och, das ist schon eine ganze Menge.

Geht, finde ich recht uebersichtlich...

Danke & Gruss
Tobi

[Christian Seiler]

Hallo Tobi,

Hmm...eigentlich wollte ich mit meinem Coding auf der Hoehe der Zeit bleiben, daher etwas mehr Richtung XHTML und XML gehen....oder ist das alles nur Bloedsinn und ich sollte beim HTML 4.0 bleiben?

Ähm, man muss nicht jedem Hype nachrennen, _vor allem_ nicht, wenn er XHTML heißt. Bedenke: Wenn Du XHTML »richtig«[tm] auslieferst, dann musst Du den Mimetype application/xhtml+xml nehmen - und da versagen fast alle Browser. Daher musst Du text/html nehmen. Bei text/html _sollte_ der Browser aber einen reinen HTML-, d.h. SGML-Parser verwenden. Und das gibt Probleme, denn <img .../> _sollte_ als <img ...>> interpretiert werden. Dass fast kein Browser macht (und die, die es machen, sind extreme Randphänomene, Konqueror z.B. hat einen riesigen Marktanteil im Vergleich zu ihnen) macht es trotzdem nicht richtiger und man weiß ja nie, was die Zukunft bringt.

IMHO ist es sinnvoller, HTML 4.01 zu verwenden, solange es nicht weiter verbreitet ist. Oder Du machst Content Negotiation, d.h. Du lieferst XHTML-Seiten, wenn der Client XHTML versteht und HTML-Seiten, wenn der Client kein XHTML versteht. (Das kannst Du beim Apachen mit MultiViews machen, ich bin jetzt zu faul, das Archiv danach zu durchstöbern, aber irgendwo gab es einen Link mit der Anleitung dazu)

Die Idee von XML, wieder eine Beschreibungssprache mit strikter Trennung von Form und Inhalt, finde ich eigentlich logisch und gut...

Das gab es schon bei HTML 4 und HTML 2. (HTML 3.2 war da so eine Ausnahme...)

auch im Hinblick auf die vielseitige Einsetzbarkeit und Kompatibilitaet des XML Formates, Import in Anwendungen usw.

Theoretisch wäre das wirklich ein Vorteil von XHTML, aber XHTML wird nunmal nur von Mozilla, Opera und Amaya verstanden, um mal die »verbreitetsten« Browser zu nennen.

Ja, hast recht...ich hatte an den font Tag gedacht, aber der war ja schon bei HTML 4.0 nicht mehr okay, oder?

Das font-Element ist immer noch Teil von HTML 4.01 Transitional und XHTML 1.0 Transitional. Dass man es trotzdem nicht mehr verwenden soll, dürfte klar sein. ;-)

Christian

[Danny]

Hi,

dass man nicht gleich jedem Hype nachrennen sollte, ist klar. Man muß ja nicht XHTML oder XML ausliefern, sondern kann auch sehr davon im Backend-Bereich profitieren.

Wenn man Design und Inhalte einer Webseite häufig ändert, aber weder WYSIWYG-Editoren, CMS oder mySQL-Zeug zur Pflege verwenden will oder kann, dann ist das XML-Format zur Datenverwaltung sehr sinnvoll. Mit einem lokalen Webserver und wenigen Zeilen PHP-Code kann man leicht Templates erstellen, die sich die Daten aus XML-Quellen ziehen... Das ist gar nicht mal so kompliziert und erleichtert die Arbeit ernorm!

Gruß,
Danny

[Daniel Thoma]

Hallo,

»»Und das gibt Probleme, denn <img .../> _sollte_ als <img ...>> interpretiert werden.

XML ist kompatibel zu SGML, d.h. eine wohlgeformte XML-Datei ist auch eine wohlgeformte SGML-Datei.
--> Der Browser sollte das also schlicht ignorieren.

Was den Mime-Type angeht, so steht hier unter welchen Bedingungen text/html eingesetzt werden kann:
http://www.w3.org/TR/xhtml-media-types/#text-html

Der Einsatz von xhtml ist also relativ Problemlos; von der Transitional-Variante sowieso.
Wenn man dadurch also Vorteile beispielsweisee bei der Erzeugung hat, braucht man meiner Meinung nach nicht zu zögern es einzusetzen.

Grüße

Daniel

[Christian Seiler]

Hallo Daniel,

Und das gibt Probleme, denn <img .../> _sollte_ als <img ...>> interpretiert werden.

XML ist kompatibel zu SGML, d.h. eine wohlgeformte XML-Datei ist auch eine wohlgeformte SGML-Datei.

Unter der Vorraussetzung, dass SGML Wohlgeformtheit kennen würde: ja.

--> Der Browser sollte das also schlicht ignorieren.

Nein, siehe </archiv/2002/12/33371/#m181512>.

Was den Mime-Type angeht, so steht hier unter welchen Bedingungen text/html eingesetzt werden kann:
http://www.w3.org/TR/xhtml-media-types/#text-html

Irgendwie widersprüchlich. Hmm. Ein SGML-Experte anwesend, der das vielleicht endgültig mal klären könnte?

Christian

[Michael Jendryschik]

Ähm, man muss nicht jedem Hype nachrennen, _vor allem_ nicht, wenn er XHTML heißt. Bedenke: Wenn Du XHTML »richtig«[tm] auslieferst, dann musst Du den Mimetype application/xhtml+xml nehmen

Wie kommst du darauf? Sofern die HTML-Kompatibilitätsrichtlinien eingehalten werden, darf XHTML 1.0 auch als 'text/html' ausgeliefert werden, vgl. http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/xhtml-media-types.html.

Bei text/html _sollte_ der Browser aber einen reinen HTML-, d.h. SGML-Parser verwenden. Und das gibt Probleme, denn <img .../> _sollte_ als <img ...>> interpretiert werden. Dass fast kein Browser macht (und die, die es machen, sind extreme Randphänomene, Konqueror z.B. hat einen riesigen Marktanteil im Vergleich zu ihnen)

Ich kenne nur Emacs-W3, der sich - wie ich hörte - angeblich so verhalten soll. Kennst du noch einen weiteren?

IMHO ist es sinnvoller, HTML 4.01 zu verwenden, solange es nicht weiter verbreitet ist. Oder Du machst Content Negotiation, d.h. Du lieferst XHTML-Seiten, wenn der Client XHTML versteht und HTML-Seiten, wenn der Client kein XHTML versteht. (Das kannst Du beim Apachen mit MultiViews machen, ich bin jetzt zu faul, das Archiv danach zu durchstöbern, aber irgendwo gab es einen Link mit der Anleitung dazu)

http://schneegans.de/tips/apache-xhtml.html womöglich?

MI

[Christian Seiler]

Hallo Michael,

Wie kommst du darauf? Sofern die HTML-Kompatibilitätsrichtlinien eingehalten werden, darf XHTML 1.0 auch als 'text/html' ausgeliefert werden, vgl. http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/xhtml-media-types.html.

Darf als text/html ausgeliefert werden: ja. Aber ob das dann gültig ist bzw. den gewünschten Effekt erzielt, ist die zweite Frage.

Ich kenne nur Emacs-W3, der sich - wie ich hörte - angeblich so verhalten soll. Kennst du noch einen weiteren?

Erkläre mir bitte das:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.christian-seiler.de%2Ftemp%2Fsgmltest.html
Die Datei:
http://www.christian-seiler.de/temp/sgmltest.html

http://schneegans.de/tips/apache-xhtml.html womöglich?

Genau das wars. Danke.

Christian

[Michael Jendryschik]

Wie kommst du darauf? Sofern die HTML-Kompatibilitätsrichtlinien eingehalten werden, darf XHTML 1.0 auch als 'text/html' ausgeliefert werden, vgl. http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/xhtml-media-types.html.

Darf als text/html ausgeliefert werden: ja. Aber ob das dann gültig ist bzw. den gewünschten Effekt erzielt, ist die zweite Frage.

Was ist für dich der Unterschied zwischen "gültig" und "erlaubt"?

Erkläre mir bitte das:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.christian-seiler.de%2Ftemp%2Fsgmltest.html

Das Dokument ist kein gültiges HTML 4.01 Dokument.

MI

[Christian Seiler]

Hallo Michael,

Darf als text/html ausgeliefert werden: ja. Aber ob das dann gültig ist bzw. den gewünschten Effekt erzielt, ist die zweite Frage.

Was ist für dich der Unterschied zwischen "gültig" und "erlaubt"?

Ob es dann als gültig angesehen wird, wollte ich vielleicht sagen. Man siehe mein unteres Beispiel.

Erkläre mir bitte das:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.christian-seiler.de%2Ftemp%2Fsgmltest.html
Das Dokument ist kein gültiges HTML 4.01 Dokument.

Was meinst Du, warum ich es sonst hochgeladen habe?

Achte darauf, dass das Zeichen, das nicht erlaubt ist, nicht der Schrägstrich, sondern das Zeichen, das Tags schließt, (d.h. spitze Klammer zu) ist.

Ich habe hier nur dargelegt, was passiert, wenn ein XHTML-Dokument in einen korrekten SGML-Parser gelangt, der _kein_ XHTML unterstützt. (Daher andere DOCTYPE)

Christian

[Michael Jendryschik]

Erkläre mir bitte das:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.christian-seiler.de%2Ftemp%2Fsgmltest.html
Das Dokument ist kein gültiges HTML 4.01 Dokument.

Was meinst Du, warum ich es sonst hochgeladen habe?

Ich weiß nicht, warum du dieses Dokument hochgeladen hast.

Achte darauf, dass das Zeichen, das nicht erlaubt ist, nicht der Schrägstrich, sondern das Zeichen, das Tags schließt, (d.h. spitze Klammer zu) ist.

Ja, und?

Ich habe hier nur dargelegt, was passiert, wenn ein XHTML-Dokument in einen korrekten SGML-Parser gelangt, der _kein_ XHTML unterstützt. (Daher andere DOCTYPE)

Nein, du hast dargelegt, was passiert, wenn du innerhalb eines HTML 4.01 Dokumentes XML-Syntax verwendest. Was du daraus zwingend ableiten willst, ist mir nicht klar.

MI

[Christian Seiler]

Hallo Michael,

Nein, du hast dargelegt, was passiert, wenn du innerhalb eines HTML 4.01 Dokumentes XML-Syntax verwendest. Was du daraus zwingend ableiten willst, ist mir nicht klar.

Wenn ein Browser jetzt kein XHTML bzw. XML versteht, sowie auch keine DOCTYPEs interpretiert, sondern stattdessen nur HTML parsen kann, dann können XHTML-Seiten, die als text/html ausgeliefert werden (bei denen er ja dann seinen HTML-Parser anwirft) Probleme bereiten.

Christian

[Michael Jendryschik]

Nein, du hast dargelegt, was passiert, wenn du innerhalb eines HTML 4.01 Dokumentes XML-Syntax verwendest. Was du daraus zwingend ableiten willst, ist mir nicht klar.

Wenn ein Browser jetzt kein XHTML bzw. XML versteht, sowie auch keine DOCTYPEs interpretiert, sondern stattdessen nur HTML parsen kann, dann können XHTML-Seiten, die als text/html ausgeliefert werden (bei denen er ja dann seinen HTML-Parser anwirft) Probleme bereiten.

Soviel zur Theorie. Welche Bedeutung hat dies in der Praxis?

MI

[Christian Seiler]

Hallo Michael,

Soviel zur Theorie. Welche Bedeutung hat dies in der Praxis?

Andersherum gefragt: Was für Vorteile hab' ich denn noch, wenn ich XHTML als text/html ausliefere?

• Einfaches parsen: nein.
• Modularisierung: nein.
• Andere Sprachen (SVG, MathML) einbinden: nein.
• XML-DOM: nein.

Und wenn es dann auch noch zu Problemen kommen _kann_: Warum sollte ich dann XHTML nehmen? Welchen Vorteil hat es dann gegenüber HTML 4?

In drei Jahren können wir noch mal darüber reden, da gibt es _vielleicht_ (optimitsich betrachtet) genug Browser, die application/xhtml+xml verstehen.

Christian

[Michael Jendryschik]

Soviel zur Theorie. Welche Bedeutung hat dies in der Praxis?

Andersherum gefragt:

Du weichst also aus, meinetwegen.

Was für Vorteile hab' ich denn noch, wenn ich XHTML als text/html ausliefere?

Im Vergleich wozu? Die Frage sollte lauten, welche Vorteile es mit sich bringt, XHTML- statt HTML-Dokumente zu verfassen.

XHTML Dokumente kann man mit normalen XML Werkzeugen erstellen, verarbeiten, betrachten, bearbeiten und validieren. Das habe ich bereits einige Male getan, indem ich aus einem XML-Dokument mit Hilfe von XSLT ein XHTML-Dokument generiert habe. Mit HTML geht das nicht.

XHTML verfügt über eine *zwingend* logische Struktur, die es für Anfänger im Vergleich zu HTML einfacher macht, XHTML zu verstehen.

Und wenn es dann auch noch zu Problemen kommen _kann_:

Wie ich schon mehrfach fragte: Wo kommt es in der Praxis zu Problemen, wenn ich XHTML 1.0 Dokumente als 'text/html' ausliefere? Unter http://www.websitedev.de/xhtml/xhtml1/#xhtml steht nicht umsonst zu lesen: "Indem Inhaltsentwickler heute auf XHTML umsteigen, können sie in die XML-Welt mit allen dazugehörigen Vorteilen einsteigen, während sie sich auf die Abwärts- wie auch die zukünftige Kompatibilität ihrer Inhalte verlassen können."

In drei Jahren können wir noch mal darüber reden, da gibt es _vielleicht_ (optimitsich betrachtet) genug Browser, die application/xhtml+xml verstehen.

Dann kann ich meine Dokumente einfach als 'application/xhtml+xml' ausliefern und genieße von da an alle Vorteile, die XHTML mit sich bringt, ohne meine gesamte Website komplett umschreiben zu müssen.

MI

[Christian Seiler]

Hallo Michael,

Im Vergleich wozu? Die Frage sollte lauten, welche Vorteile es mit sich bringt, XHTML- statt HTML-Dokumente zu verfassen.

Das meinte ich doch.

XHTML Dokumente kann man mit normalen XML Werkzeugen erstellen, verarbeiten, betrachten, bearbeiten und validieren.

Und wer macht das wirklich?

Das habe ich bereits einige Male getan, indem ich aus einem XML-Dokument mit Hilfe von XSLT ein XHTML-Dokument generiert habe. Mit HTML geht das nicht.

Du kannst mit XSLT soweit ich weiß jegliche Art von Dokument erstellen, oder sehe ich da was falsch? (ich habe noch nie mit XSLT gearbeitet)

XHTML verfügt über eine *zwingend* logische Struktur, die es für Anfänger im Vergleich zu HTML einfacher macht, XHTML zu verstehen.

Mit HTML kann man auch eine logische Struktur einhalten, daher verstehe ich das Argument nicht. (XHTML zwingt auch keine logische Struktur auf, ich kann genauso <span style="..."> statt <h1> schreiben)

Wie ich schon mehrfach fragte: Wo kommt es in der Praxis zu Problemen, wenn ich XHTML 1.0 Dokumente als 'text/html' ausliefere?

Ich habe schon IEs erlebt, die damit Probleme hatten. Warum weiß ich nicht, da das immer bei dynamischen Seiten aufgetreten ist und auch nur sehr sporadisch. (Manchmal ging es, manchmal nicht, manchmal half Cache leeren, manchmal wieder nicht - sehr seltsam) Nicht, dass sie jetzt SGML verstanden haben, aber sie haben irgendwie versucht, das Dokument zu parsen und sind dabei gescheitert. (XML-Verarbeitungsfehler) Nur dass das produzierte Dokument valide war. (und außerdem »text/html« mitgegeben wurde) Ich werde am Wochenende mal versuchen, das noch mal zu reproduzieren.

Dann kann ich meine Dokumente einfach als 'application/xhtml+xml' ausliefern

Eben.

und genieße von da an alle Vorteile, die XHTML mit sich bringt, ohne meine gesamte Website komplett umschreiben zu müssen.

Wenn Du valides HTML4 Strict schreibst - wie groß ist da der Aufwand wirklich?

Christian

[Michael Jendryschik]

Du kannst mit XSLT soweit ich weiß jegliche Art von Dokument erstellen, oder sehe ich da was falsch?

Ja, du siehst da was falsch.

XHTML verfügt über eine *zwingend* logische Struktur, die es für Anfänger im Vergleich zu HTML einfacher macht, XHTML zu verstehen.

Mit HTML kann man auch eine logische Struktur einhalten, daher verstehe ich das Argument nicht.

Man *kann*, sicher. Aber man *muss* nicht.

(XHTML zwingt auch keine logische Struktur auf, ich kann genauso <span style="..."> statt <h1> schreiben)

Natürlich, klar. Aber das meinte ich nicht, sorry. Ich meinte folgendes:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN">

<!-- 'html lediglich implizit vorhanden -->
  <head>
  <title>Dokument</title>
  <meta name="description" content="Beschreibung"> <!-- nicht geschlossen -->
    <!-- 'head' nicht geschlossen -->

<!-- 'body' lediglich implizit vorhanden' -->

<p>Hier steht Text. <!-- kein </p>, es stellt sich die Frage: welche Elemente
                           müssen geschlossen werden und welche nicht?  -->
  <ul>
  <li>Listenpunkt     <!-- keine </li>, daher unübersichtliche Verschachtelung -->
     <UL>
     <li>Listenpunkt
     <li>Listenpunkt
     </ul>            <!-- <UL>, aber </ul> -->
  <li>Listenpunkt
  </ul>

Es gibt noch weitere skurrile Dinge (zum Beispiel: Wann muss ich Attributwerte in Anführungszeichen setzen und wann nicht?), die mich zu der Überzeugung gebracht haben: HTML ist scheiße! ;)

Wie ich schon mehrfach fragte: Wo kommt es in der Praxis zu Problemen, wenn ich XHTML 1.0 Dokumente als 'text/html' ausliefere?

Ich habe schon IEs erlebt, die damit Probleme hatten. Warum weiß ich nicht, da das immer bei dynamischen Seiten aufgetreten ist und auch nur sehr sporadisch. (Manchmal ging es, manchmal nicht, manchmal half Cache leeren, manchmal wieder nicht - sehr seltsam)

Na super. Damit hast du mich überzeugt.

Ich werde am Wochenende mal versuchen, das noch mal zu reproduzieren.

Ich bitte darum.

und genieße von da an alle Vorteile, die XHTML mit sich bringt, ohne meine gesamte Website komplett umschreiben zu müssen.

Wenn Du valides HTML4 Strict schreibst - wie groß ist da der Aufwand wirklich?

Zu groß, in meinen Augen. Und darüber hinaus überflüssig, da ich doch gleich XHTML schreiben kann.

MI

[Christian Seiler]

Hallo Michael,

Es gibt noch weitere skurrile Dinge (zum Beispiel: Wann muss ich Attributwerte in Anführungszeichen setzen und wann nicht?), die mich zu der Überzeugung gebracht haben: HTML ist scheiße! ;)

Sie doch mal ehrlich: diejenigen, die wirklich so skurrile Dinge machen, scheren sich doch einen Dreck um validen Code. Alle Seiten, die so seltsame Sachen haben und die ich gesehen habe, waren invalide. Jemand, der validen Code schreibt, wird sich sicherlich an die logische Struktur halten, sonst verliert er ja selbst den Überblick. Ich selbst halte mich an die logische Struktur. Zu den Attributwerten - die habe ich immer in doppelte Anführungszeichen gesetzt - schon bevor ich überhaupt wußte, was XHTML ist. (Nur weil etwas nicht Pflicht ist, heißt es noch lange nicht, dass man es nicht einhalten kann - es ist mir ja auch nicht vom Compiler bzw. Interpreter auferlegt, dass ich meinen Programmiercode kommentiere - trotzdem tue ich es)

Zu groß, in meinen Augen.

Da sind wir anderer Meinung.

Christian

[Michael Jendryschik]

Sie doch mal ehrlich: diejenigen, die wirklich so skurrile Dinge machen, scheren sich doch einen Dreck um validen Code. Alle Seiten, die so seltsame Sachen haben und die ich gesehen habe, waren invalide.

Mag sein, aber was hat das eine mit dem anderen zu tun? Wolltest du mich nicht ursprünglich davon überzeugen, dass XHTML heute noch keinen Sinn macht? ;-)

Zu groß, in meinen Augen.

Da sind wir anderer Meinung.

Damit kann ich leben.

MI

[Christian Seiler]

Hallo Michael,

Wolltest du mich nicht ursprünglich davon überzeugen, dass XHTML heute noch keinen Sinn macht? ;-)

Ach weißt Du, wenn ich mit Dir argumentiere, habe ich immer das Problem, dass ich von einem komplett anderen Standpunkt an die Sache herangehe als Du. Ich fürchte, das mit dem gegenseitigem Überzeugen wird nichts.

Für mich selbst gibt es keinen wirklich Vorteil von XHTML, für andere (wie Dich) mag es ihn dagegen vielleicht geben.

Naja, wegen dem IE: da war noch eine <?xml?>-Deklaration mit reingeraten, deswegen hat er gesponnen.

Damit kann ich leben.

Ich auch. ;-)

Christian

[Michael Schröpl]

Hi Christian,

Jemand, der validen Code schreibt, wird sich sicherlich an die logische Struktur halten, sonst verliert er ja selbst den Überblick. Ich selbst halte mich an die logische Struktur.

aber es ist viel einfacher, sich an "die logische Struktur" zu halten, wenn man dies durch entsprechend "scharfes" Validieren dann auch bestätigen lassen kann.

Ich möchte nicht nur _vielleicht_ "fast XHTML-taugliche" HTML-Seiten haben, sondern ich will _wirklich_ XHTML-taugliche Seiten haben. Ich will _jetzt_ verhindern, daß ich irgendwo versehentlich HTML-Code verwende, der in XHTML nicht mehr erlaubt wäre.

Ich will mir nicht selbst einen Validator schreiben müssen, um Deinen Stil im Umgang mit HTML-Dokumenten praktizieren zu können.

Viele Grüße
      Michael

[Michael Jendryschik]

Die Idee von XML, wieder eine Beschreibungssprache mit strikter Trennung von Form und Inhalt, finde ich eigentlich logisch und gut...

Das kannst du auch schon mit HTML 4.01 haben.

Ja, hast recht...ich hatte an den font Tag gedacht, aber der war ja schon bei HTML 4.0 nicht mehr okay, oder?

Kommt drauf an. 'font' ist in HTML 4.01 Strict nicht mehr enthalten, in Transitional schon, siehe http://www.w3.org/TR/html401/present/graphics.html#edef-FONT.

MI

[Michael Jendryschik]

ich moechte einen XHTML konformen Code erstellen.

Warum?

Warum nicht?

• case sensitive

Richtig. In XHTML wird _alles_ kleingeschrieben - auch onclick, onmouseover und so. (häufiger Fehler)

Das ist genau genommen nicht richtig. Ich zitiere aus http://www.websitedev.de/xhtml/xhtml1/#diffs:

"XHTML Dokumente müssen Kleinschreibung für alle HTML Element- und Attributnamen verwenden. Dieser Unterschied ist notwendig, da XML Groß-/Kleinschreibungsempfindlich ist, z.B. sind <li> und <LI> unterschiedliche Tags."

Richtig. Leere Attribute müssen immer noch einen Wert enthalten, also wie in Deinem Beispiel noshade="noshade".

Was sind denn "leere Attribute"?

MI

[molily]

Hallo,

In XHTML wird _alles_ kleingeschrieben - auch onclick, onmouseover und so. (häufiger Fehler)

Das ist genau genommen nicht richtig. Ich zitiere aus http://www.websitedev.de/xhtml/xhtml1/#diffs: [#h-4.2 --molily]

"XHTML Dokumente müssen Kleinschreibung für alle HTML Element- und Attributnamen verwenden. ...

Erklärst du mir den Unterschied zu Christians Aussage?

... Dieser Unterschied ist notwendig, da XML Groß-/Kleinschreibungsempfindlich ist, z.B. sind <li> und <LI> unterschiedliche Tags."

Ja, und? Das ist eine der entscheidenden Grundlagen; dies widerspricht nicht dem, was Christian sagte. Mit XML hat es auch nur insofern zu tun, dass XML eben diesbezüglich empfindlich ist; der naheliegende Grund ist, dass XHTML nunmal Attribut- und Elementnamen ohne Großbuchstaben verwendet, weil es so gewählt wurde und dadurch vorgeschrieben ist. Natürlich wären auch Li oder LI als Elementname theoretisch denkbar gewesen, die Schreibweise wäre natürlich aus dem von dir genannten Grund bindend, darüber hat Christian jedoch keine gegenteiligen Aussagen gemacht. Dass HTML vor XHTML explizit Element- oder Attributnamen in Großbuchstaben oder einer bestimmten gemischten Schreibweise fordert, hat er ebenso nicht behauptet. So what?

M.

[Michael Jendryschik]

Hallo,

In XHTML wird _alles_ kleingeschrieben - auch onclick, onmouseover und so. (häufiger Fehler)

Das ist genau genommen nicht richtig. Ich zitiere aus http://www.websitedev.de/xhtml/xhtml1/#diffs: [#h-4.2 --molily]

"XHTML Dokumente müssen Kleinschreibung für alle HTML Element- und Attributnamen verwenden. ...

Erklärst du mir den Unterschied zu Christians Aussage?

Dass nicht *alles* kleingeschrieben werden braucht, sondern nur alle HTML Element- und Attributnamen. 'id="GrOsSUnDkLeIn"' ist kein Problem.

MI

[Sven Schrodt]

hallo!

Richtig. Leere Attribute müssen immer noch einen Wert enthalten, also wie in Deinem Beispiel noshade="noshade".
Was sind denn "leere Attribute"?

ich denke es waren "leere Elemente" gemeint..

Sven

[Michael Schröpl]

Hi Sven Schrodt,

Richtig. Leere Attribute müssen immer noch einen Wert enthalten, also wie in Deinem Beispiel noshade="noshade".
Was sind denn "leere Attribute"?
ich denke es waren "leere Elemente" gemeint..

meine Vermutung wäre gewesen, daß es um "semantisch leere" Attribute geht - der Wert des "noshade"-Attributs kann nur eine einzige Ausprägung haben, ist also kein Informationsträger (nur das Vorhandensein des Attributs ist einer).

Daß man solche Attribute in XHTML in dieser Form notieren muß, obwohl gar kein "Bedarf" für einen Wert besteht, ist in der Tat gewöhnungsbedürftig.
Ein Parameter "shade=yes|no" wäre in dieser Hinsicht leichter zu verstehen, finde ich.

Hätte ich XHTML definiert, dann hätte ich diese "leeren Attribute" möglicherweise tatsächlich inkompatibel geändert - zur Hölle mit Abwärtskompatibilität, es gibt ja schließlich DOCTYPEs.
Wenn schon eine Redefinition mit begrenzter Kompatibilität, warum dann keine didaktisch optimierte?

Viele Grüße
      Michael

[Michael Jendryschik]

ich moechte einen XHTML konformen Code erstellen.

Aber bitte noch nicht XHTML 1.1.

Habe ich das richtig verstanden, dass folgende zu beachtende Punkte schon alles im Vergleich zu normalem HTML (4.0) sind?

Vielleicht hilft dir ein Blick auf http://jendryschik.de/wsdev/einfuehrung/xhtml/xhtml.html oder gleich auf http://www.websitedev.de/xhtml/xhtml1/.

MI