nicht angemeldet
Grüße dich, Gunnar,
audio- und video-Elemente (wobei die dank des Codes-Streits eher einer Todgeburt gleichen)
Der Codex-Streit ist wohl auf dem Weg, gelöst zu werden.
Der Meinung bin ich nicht. Apple und Microsoft sträuben sich noch etwas.
Die alternative lautet meistens Flash, daher denke ich nicht, dass ein neuer Codec, den man erst herunterladen muss (MS), sich durchsetzen kann.
Aber neue Elemente, Attribute und sontiges besitzen noch keine semantische Bedetung.
Hä? 'article', 'section', 'nav' etc. haben semantische Bedeutung. @autofocus, @autocomplete, @aria-*, @data-* auch.
Die gewinnt HTML5 erst wenn es halbwegs fertig wird.
Wieso sollte sich an der semantische Bedeutung von Elementen und Attributen etwas ändern, wenn HTML5 vom Stadium "in Entwicklung" in das Stadium "fertig" übergeht?
Selbstverständlich besitzen die neuen Elemente Semantik per Definition. Dennoch gibts es momentan noch keinen veröffentlichten Browser, in dem z.B. 'article' als Artikel-Element gesehen wird. Es hat die selbe Bedeutung wie ein foo-Element.
Das kann sich erst durch die richtige Implementierung ändern, die zwangsläufig zur Fertigstellung von HTML5 führt.
Hier wird ausgenutzt, dass der IE eine ganz eigene, völlig vermurkste Vorstellung von Namensräumen besitzt.
Falsch. IE kann kein XHTML als 'application/xhtml+xml' verarbeiten, deshalb bekommt er es als 'text/html' serviert. In Tagsoup gibt es ganz einfach keine Namensräume;
<foo:bar/>ist kein Element vom Typ 'bar' aus dem per @xmlns:foo definierten Namensraum wie bei XML-Verarbeitung, sondern eben ein Element vom Typ 'foo:bar'. Deshalb ist es in CSS per Typselektor 'foo\:bar' ansprechbar.
Der IE kann auch innerhalb von text/html Namensräume verarbeiten. Das ist ein Feature, dass in IE 5 implementiert wurde (evtl auch schon vorher).
Der XHTML-Namensraum wird angegeben, weil HTML-Elemente diesem angehören. Allerdings könnte der Namensraum auch kuddeldimuddel heißen.
Falsch. Er muss 'http://www.w3.org/1999/xhtml' heißen.
Ich bin mir nicht sicher, ob du mich richtig verstanden hast. Durch das definieren eines belibigen Namensraums (für einen beliebigen Präfix), ist es möglich, Elemente 'normal' verarbeiten zu lassen. Siehe
<html xmlns:baz="kuddeldimuddel">
<body>
<baz:section>Test</baz:section>
</body>
</html>
Es wäre das selbe Ergebnis. Der Namensraum hat keine Bedeutung in diesem Trick.
Falsch. Verarbeite mal
<html xmlns="kuddeldimuddel">
<head><title>Test</title></head>
<body><a href="http://example.net">Link</a></body>
</html>
>
> als XML und nichts ist mit Link, weil das 'a'-Element nicht dem XHTML-Namensraum angehört. Anders hingegen bei
>
> ~~~xml
<html xmlns="kuddeldimuddel">
> <head><title>Test</title></head>
> <body>[code lang=html]<a href="http://example.net" xmlns="http://www.w3.org/1999/xhtml">Link</a>
~~~</body>
> </html>[/code]
Du darfst nicht von XML ausgehen. Der Trick um den es hier geht, ist eine Funktion, die der IE in HTML bereitstellt. Und gerade dort funktioniert der XHTML-Namensraum eben nicht um a-Elemente zu Verweisen zu machen.
> > Bei dem Code handelt es sich weder um HTML(5) noch um XHTML.
>
> Falsch. Es ist sowohl als auch. Es ist XHTML5.
In HTML ist es TagSoup, wie du sagen würdest. Dass das Verwenden des XHTML-Namensraums in hinsicht auf eine Verarbeitung als XML sinnvoll sein mag will ich nicht bestreiten. Du selbst sagst jedoch, dass namensräume in HTML keine Bedeutug haben. Selbst der IE, der diesen Mist implementiert hat kann nicht damit Umgehen.
Deshalb sage ich, dass diese methode die denkbar schlechteste HTML5-Emulierung ist. Das Ergebnis ist das selbe wie mit dem createElement-Trick, nur wesentlich komplizierter.
> > Vorwärtskompatibel ist das leider auch nicht, die so erstellten Elemente sind keine HTML(5)-Elemente sondern generische, bedeutungslose Elemente.
>
> Falsch.
>
> [...]
>
> sind völlig äquivalente XML-Dokumente.
>
> `<article/>`{:.language-html} und `<foo:article/>`{:.language-html} sind bei Verarbeitung als 'application/xhtml+xml' völlig äquivalente XHTML5-Elemente, wenn dem Präfix 'foo' der Namensraum 'http://www.w3.org/1999/xhtml' zugeordnet wurde.
Das streite ich nicht ab. Ich habe in Bezug auf X(HT)ML ohnehin schon etwas zurückgerudert. Aber hier geht es nunmal nicht um XML. Der Versuch mit dem a-Element zeigt, dass es sich um generische HTML-Elemente handelt, nicht um definierte Elemente mit Bedeutung.
> > Was das Schreiben von HTML anbelangt ist HTML4 im Moment einfach noch die beste Wahl.
>
> Nö. Wenn schon, dann XHTML 1.
Meinetwegen auch das, macht ja keinen Unterschied.
> > XHTML definiert sich durch den Medientyp application/xhtml+xml, durch nichts anderes.
>
> Falsch. Für XHTML5 ist das so gesagt. XHTML 1 kann durchaus als 'text/html' ausgeliefert werden.
Auch XHTML 1.x definiert sich über 'application/xhtml+xml', man kann es nur zufälligerweise auch als 'text/html' ausliefern und verarbeiten lassen. Was das W3C auch erlaubt hat.
> > Alles was nicht XHTML oder XML ist, ist HTML.
>
> Also ich für meinen Teil bin nicht XHTML oder XML, aber deshalb noch lange kein HTML.
Entschuldige, von deinen Beiträgen her hätte ich wissen müssen, dass du eher CSS bist :)
> Im Übrigen lässt sich "XHTML oder XML" zu "XML" zusammenfassen, da XHTML in XML echt enthalten ist.
Das ist klar, mache ich auch oft, aber hin und wieder ist eine Abgrenzung ganz sinnvoll. Sagst du damit aber nicht aus, dass XML auch als 'text/html' ausgeliefert werden kann?
> > HTML 4.01 (gefälligst Strict, aber mit stabilen Zusätzen wie etwa dem canvas-Element) ist die erste Wahl.
>
> Es gibt keine Zusätze in HTML 4.01 Strict. Tagsoup mit HTML-fremden Elementen ist kein HTML mehr.
Es geht hier nicht darum, einem bestimmten Standard zu entsprechen. Es geht darum, ein vernünftiges Dokument zu schreiben, dass von allen wichtigen Browsern verarbeitet werden kann.
HTML und XML erlauben nunmal TagSoup, dagegen kommen wir nicht mit Diskussion an. Aber mit Aufklärung von Autoren.
Gruß, Daniel
Gunnar Bittersmann