nicht angemeldet
Die mangelnde Browserunterstützung. Es spräche logisch auch nichts dagegen musik und film als object einzubinden, aber dafür hat man halt einfach mal <audio /> und <video /> gebastelt, weil man zu faul war object ordentlich zu erweitern.
Und was wäre in dem Fall mit der mangelnden Browserunterstützung? So wie ich es sehe wäre zwar ein Allround-object-Element möglich, aber gleichzeitig auch Überladen und daher mE komplizierter anzuwenden.
Was wäre z.B. mit einem object-Element, dass eine Audiodatei enthält, aber ein poster-Attribut besitzt?
Ich denke so ist es besser, weil dann jedes Element seinen eigenen Attribute und Prozesse verarbeiten kann. Auch wenn beide vielleicht gemeinsame Kontrollen teilen (was ein browser ja zweifelsohne Codesparent implementieren kann).
HTML5 hat im Gesamtbild vielleicht ein paar unschöne Ecken und Kanten, aber es löst viele der Probleme die wir nicht hätten, wenn HTML und XHTML mit mehr Sorgfalt spezifiziert worden wären.
HTML4 sagt zum Beispiel, dass leere p-Elemente ignoriert werden sollten (HTML401, 9.3.1 Paragraphs: the P element).
Frage: <p></p> ist leer, aber ist <p> </p> auch leer? Wird <p></p> im DOM dargestellt? Wenn nein, was passiert, wenn es dynamich mit Inhalt gefüllt wird? Wenn ja, darf es dargestellt werden, z.B. durch CSS-Manipulation?
DOM Core Level 3, createElement (und ein paar andere Methoden) sagt:
Return Value: A new Element object with the nodeName attribute set to tagName, and localName, prefix, and namespaceURI set to null.
Nun, HTML-Elemente besitzen den null-Namensraum, aber was ist mit XHTML-Dokumenten, diese besitzen den XHTML-Namensraum. Warum besitzt die selbe Sprache in unterschiedlichen Ausführungen eigentlich verschiedene Namensräume?
HTML5 definiert, dass HTML und XHTML den selben Namensraum teilen und dass createElement und andere DOM-Methoden in HTML-Dokumenten automatisch den XHTML-Namensraum anwenden. Die Unterschiede zwischen HTML und XHTML werden also verkleinert.
createElement ist da ein gutes Beispiel, da es bis vor einiger Zeit nicht interoperabel implementiert war (Webkit).
XHTML sagt, dass leere Elemente mit schließendem Endtag oder als selbstschließendes Element notriert werden müssen (XHTML 1.0 SE, 4.6. Empty Elements).
Mal ungeachtet der Tatsache, dass lange schlicht ignoriert wurde, dass Endtags für diese Elemente Darstellungsfehler bei TS-Parsern verursachen...
Endtags für leere Elemente und selbstschließende Elemente sind in HTML4 nicht erlaubt. Wie also hat ein HTML-Parser damit umzugehen? Ich würde in der SGML-Spezifikation nachlesen, aber dazu fehlt mir das Geld.
Mag sein, dass jetzt wieder die Leute angerannt kommen und ewtas von spielt-keine-Rolle-Spec/Implementierung faseln. Aber das sind nur drei von zahlreichen Beispiele, die sich direkt auf eine ... eher unvollständig durchdachte Spezifikation zurückzuführen sind.
Gunnar Bittersmann
Der Martin