5 und SVG bzw. MathML
0 0 
Gunnar Bittersmann
0 0 
molily
0 0 0 Gunnar Bittersmann
0 0 Gunnar Bittersmann
0 0 molily
0 molily
5 und SVG bzw. MathML
Moin Forum,
ich hab jetzt auf die Schnelle nicht in der HTML5-Spec nachgeschaut sondern nur bei Wikipedia, aber wie kann ich denn verstehen, dass SVG und MathML nur _ohne Namensraumpräfix_ in HTML5 verwendet werden dürfen? Ich bin durch einen Artikel in einem Journal darauf gestoßen: Der URI hat den MIME-Type text/html und den HTML5-Doctype mit Start-Tag ~~~html
<!DOCTYPE html>
<html lang='en' xml:lang='en'>
Viele Grüße,
Robert
-
Hallo,
ich hab jetzt auf die Schnelle nicht in der HTML5-Spec nachgeschaut sondern nur bei Wikipedia, aber wie kann ich denn verstehen, dass SVG und MathML nur _ohne Namensraumpräfix_ in HTML5 verwendet werden dürfen?
Das bedeutet, dass du in HTML Elemente nicht in der Form mathml:mo oder svg:path notieren darfst, sondern nur als <mo> bzw <path> (optional darfst du im Wurzelelement des SVG- oder MathML-Abschnitts dessen Namespace im xmlns-Attribut hinterlegen). In XHTML sind beide Varianten möglich (hier musst du aber den Namensraum immer Angeben, entweder im ersten SVG/MathML-Element oder als Präfixdefinition im Wurzelelement).
Ich kann dir allerdings nicht sagen, ob sich die beiden Varianten von der Schreibweise abgesehen voneinander unterscheiden.
In HTML5 kann ich per Spec ja SVG, MathML oder Anderes einfach „hereinwurschteln“, aber wie sieht es denn mit XHTML5 aus?
Egal ob HTML oder XHTML, es gibt Regeln, wie fremdsprachige Abschnitte eingefügt werden können - und die sind nahezu identisch. In HTML werden SVG- und MathML-Elemente automatisch ihrem Namensraum zugeordnet, in XHTML musst du das wie gewohnt manuell machen.
Gehören da SVG und MathML mit zur Spec oder brauche ich dann doch wieder Namensräume? Oder soll XHTML5 gar kein valides XML sein?
Der einzige Unterschied zwischen HTML und XHTML ist, dass du in HTML nur SVG und MathML einfügen kannst, während du in XHTML alle möglichen XML-Derivate einfügen kannst (theoretisch).
Wenn der Autor alles richtig macht ist XHTML(5) valides, well-formed XML.
Gruß, Daniel
-
@@Daniel.S:
nuqneH
In HTML werden SVG- und MathML-Elemente automatisch ihrem Namensraum zugeordnet
?? In HTML gibt es Namensräume?
während du in XHTML alle möglichen XML-Derivate einfügen kannst (theoretisch).
Bei XHTML 1 nicht (wenn’s valide sein sein soll). SVG und MathML mit entsprechender DTD.
Qapla'
--
Wer möchte nicht lieber durch Glück dümmer als durch Schaden klüger werden? (Salvador Dalí)-
In HTML werden SVG- und MathML-Elemente automatisch ihrem Namensraum zugeordnet
?? In HTML gibt es Namensräume?
Ja, gibt es. Sie sind den Namesräumen in XML ziemlich ähnlich - was der Sinn der Sache ist, da sich HTML und XHMTL dadurch ähnlicher werden und SVG und MathML in HTML verwendbar werden - sie sind nur nicht so mächtig wie XML-Namensräume.
während du in XHTML alle möglichen XML-Derivate einfügen kannst (theoretisch).
Bei XHTML 1 nicht (wenn’s valide sein sein soll). SVG und MathML mit entsprechender DTD.
Ich verstehe nicht, wieso XHTML in der Hinsicht so beschränkt wurde.
Ist das Problem, dass das verlinkte Dokument lösen will nun nur die Validierung (sprich: Validatoren können nicht mit XML-Namensräumen umgehen) oder sind XML-Namensräume so unflexibel, dass nicht alles mit allem gemischt werden kann?-
Ich verstehe nicht, wieso XHTML in der Hinsicht so beschränkt wurde.
Man wollte irgendwie Konformität zur Spezifikation definieren. Dazu wurde »strictly conforming« so definiert, dass ein Dokument gegen eine gegebene XML-DTD validiert. Die enthält eben nur das eingeschränkte XHTML-Vokabular.
Ist das Problem, dass das verlinkte Dokument lösen will nun nur die Validierung (sprich: Validatoren können nicht mit XML-Namensräumen umgehen)
Das Grundproblem ist, dass man Markupsprachen in DTDs definiert hat und Validität als Validität gegen die DTDs. Bis man gemerkt hat, dass DTDs für die Anforderungen von Markup aus verschiedenen Namensräumen nicht geeignet sind. Dann hat man versucht, immer größere DTDs bereitzustellen bzw. sie aus Modulen zusammenzubauen… Was natürlich zum Scheitern verurteilt ist. Was ist z.B. mit ARIA oder RDFa?
oder sind XML-Namensräume so unflexibel, dass nicht alles mit allem gemischt werden kann?
Im Prinzip schon. Es ist nur schwer, das maschinenlesbar auszudrücken. Validator.nu macht einen Eiertanz mit Schematron, NVDL und Relax NG.
Mathias
-
Moin,
?? In HTML gibt es Namensräume?
Ja, gibt es. Sie sind den Namesräumen in XML ziemlich ähnlich - was der Sinn der Sache ist, da sich HTML und XHMTL dadurch ähnlicher werden und SVG und MathML in HTML verwendbar werden - sie sind nur nicht so mächtig wie XML-Namensräume.
Hast du einen Beleg oder weiterführende Informationen dazu? Mir ist nämlich bis dato auch unbekannt, dass HTML in irgendeiner Form Namensräume kennte.
Ich verstehe nicht, wieso XHTML in der Hinsicht so beschränkt wurde.
Ist das Problem, dass das verlinkte Dokument lösen will nun nur die Validierung (sprich: Validatoren können nicht mit XML-Namensräumen umgehen) oder sind XML-Namensräume so unflexibel, dass nicht alles mit allem gemischt werden kann?Wie schon von molily beschrieben liegt die Einschränkung an der Definition mittels DTD. Mit RelaxNG oder XML Schema können beliebige Namensräume in XML verwendet und auch validiert werden.
Viele Grüße,
Robert-
Hallo,
Hast du einen Beleg oder weiterführende Informationen dazu? Mir ist nämlich bis dato auch unbekannt, dass HTML in irgendeiner Form Namensräume kennte.
Das ist nicht schwer zu finden. Beispielhaft würde ich folgende drei Stellen nennen:
HTML5 §2.1.2 XML (HTML-Elemente kommen in den HTML-Namensraum).
HTML5 §2.9 Namespaces (HTML5 kennt auch einige andere Namesräume).Dort wird auch gleich darauf Hingewisen, dass die Namesraumfunktion - verzeih mir die laienhaften Begriffe - per Präfix (z.B. svg:path) in HTML nicht genutzt werden kann.
HTML5 §8.2.5.1 Creating and inserting elements
Hier wird unter anderem beschrieben, was mit SVG- und MathML-Elementen (sog. foreign elements) passiert. Diese nutzen natürlich ihren eigenen Namesraum.
Wie schon von molily beschrieben liegt die Einschränkung an der Definition mittels DTD. Mit RelaxNG oder XML Schema können beliebige Namensräume in XML verwendet und auch validiert werden.
Ich denke ich habe den Gedanken dahinter verstanden. Ein Glück, dass HTML5 auch keine DTD mehr braucht.
Gruß, Daniel.
-
@@Daniel.S:
nuqneH
Ein Glück, dass HTML5 auch keine DTD mehr braucht.
Von Glück kann da keine Rede sein. Eine Auszeichnungssprache nicht über eine Grammatik, sondern über den Parser zu definieren, ist bedenklich.
Und das auch noch so zu tun, dass es unzählige Kontextabhängigkeiten gibt, ist schon ziemlich katastrophal.
HTML5 saugt. Und „HTML“ noch mehr.
Qapla'
--
Wer möchte nicht lieber durch Glück dümmer als durch Schaden klüger werden? (Salvador Dalí)-
Grüße dich Gunnar,
Von Glück kann da keine Rede sein. Eine Auszeichnungssprache nicht über eine Grammatik, sondern über den Parser zu definieren, ist bedenklich.
Und das auch noch so zu tun, dass es unzählige Kontextabhängigkeiten gibt, ist schon ziemlich katastrophal.
Bei diesem Satz hilft mir mein Parser mehr als meine Grammatikkenntnisse.
HTML5 saugt. Und „HTML“ noch mehr.
Sicher bist du nicht dazu gezwungen, HTML zu nutzen.
Es ist niemand ist davon abgehalten, eine DTD, RelaxNG oder ein XML-Schema für (X)HTML5 zu erstellen.
Gruß, Daniel.
-
@@Daniel.S:
nuqneH
Es ist niemand ist davon abgehalten, eine DTD, RelaxNG oder ein XML-Schema für (X)HTML5 zu erstellen.
Wer das versucht, weiß nicht, was eine DTD auszudrücken vermag und was HTML5 ausdrückt.
Es ist unmöglich, eine DTD für HTML(5) zu erstellen. HTML(5) ist vollgestopft mit Wenn-dann-so-sonst-anders-Regeln; und was für welche! Keine Chance, das in eine DTD zu gießen.
Bsp. @alt für img ist Pflicht, aber nicht, wenn @title mit nichtleerem Wert vorhanden ist. Auch nicht, wenn img in figure enthalten, was einige unverständliche Bedingungen erfüllt. Und auch nicht, wenn ganz oben im head ein meta-Element mit @name="generator" vorhanden ist.
Mittels DTD lassen sich einfache, verständliche Regeln notiteren – so, wie eine Auszeichnungssprache aufgebaut sein sollte. Die Regeln von HTML(5) sind kompliziert, unverständlich und teilweise schwachsinnig.
Qapla'
--
Wer möchte nicht lieber durch Glück dümmer als durch Schaden klüger werden? (Salvador Dalí)-
Grüße dich, Gunnar,
Wer das versucht, weiß nicht, was eine DTD auszudrücken vermag und was HTML5 ausdrückt.
Es ist unmöglich, eine DTD für HTML(5) zu erstellen. HTML(5) ist vollgestopft mit Wenn-dann-so-sonst-anders-Regeln; und was für welche! Keine Chance, das in eine DTD zu gießen.
Ich habe in diesem Thema bereits gelernt, dass sich DTDs nicht dazu eignen, HTML-Dokumente zu validieren.
Mittels DTD lassen sich einfache, verständliche Regeln notiteren – so, wie eine Auszeichnungssprache aufgebaut sein sollte. Die Regeln von HTML(5) sind kompliziert, unverständlich und teilweise schwachsinnig.
Die Regeln von HTML5 - ob kompliziert, unverständlich und schwachsinnig oder nicht - lassen sich ebenfalls mit einfachen Mitteln darstellen.
Neu ist, dass in HTML5 verschiedene Sichten definiert werden und nicht für jede davon die selben Regeln gelten. HTML-Dokumente werden nicht nur im Browser verarbeitet.
Die Erkenntnis, dass das Notieren von einfachen, verständlichen Regeln für Auszeichnungssprachen nicht geeignet ist, ist dagegen alt: Bereits bei der Neuformulierung von HTML 4 in XML sind die Autoren auf dieses Problem gestoßen. Sie umgingen es damals mit einem normativen Anhang zur Spezifikation.
Gruß, Daniel
-
Es ist niemand ist davon abgehalten, eine DTD, RelaxNG oder ein XML-Schema für (X)HTML5 zu erstellen.
Macht Validator.nu längst.
Mittels DTD lassen sich einfache, verständliche Regeln notiteren
Regeln, die die Komplexität von HTML noch nie adäquat abbilden konnten.
so, wie eine Auszeichnungssprache aufgebaut sein sollte.
Ja, sehr primitive Auszeichnungssprachen. Nicht DIE Auszeichnungssprache par excellence.
Die Regeln von HTML(5) sind kompliziert, unverständlich und teilweise schwachsinnig.
HTML ist keine einfache Sprache. Das war sie nie und wird sie nie sein. Es ist nicht HTML5, welche das Ausdrücken seiner Grammatik in DTD verunmöglicht. Das Problem gab es schon bei HTML 4 und XHTML 1. Dort hat man es einfach so gelöst, dass man unzählige Regeln einfach gar nicht in die DTD geschrieben hat – weil DTD es nicht erlaubt hat. So standen sie nur menschenlesbar in der Spec oder noch besser, sie waren lediglich implizit und common practice in den Browsern.
Auch hier, diese Diskussion ist Jahre alt (ich habe auch viel dazu geschrieben) und äußerst vielschichtig. Dein Ranting fällt hinter diese Diskussion zurück.
Mathias
-
-
-
Eine Auszeichnungssprache nicht über eine Grammatik, sondern über den Parser zu definieren, ist bedenklich.
Das ist Unsinn. Diese Behauptung wird hier immer wieder perpetuiert, ihr wurde schon hundert mal widersprochen. Näheres findet man im Archiv, in unzähligen meiner Artikel, Podcasts usw.
HTML5 als Sprache mit Semantik und Syntaxregeln wird nicht über den Parser definiert. Es wird *auch* ein Parser definiert. Der verhält sich zu diesen Regeln anders, das ist nicht zu verwechseln.
Mathias
-
-
-
-
-
-