nicht angemeldet
Gernot Back
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Tim Tepaße
Hi,
Ich versteh das grad nicht. Was sonst habe ich in einem dt?
Wann sollte ich innerhalb des dt noch ein dfn verwenden und wann nicht?
Das Beispiel in der Spec macht mich auch nicht schlauer.
~dave
Hallo,
Ich versteh das grad nicht. Was sonst habe ich in einem dt?
Alles mögliche. dl ist in HTML5 nicht mehr nur eine Definitionsliste im Sinne eines Glossars, sondern eine allgemeine Zuordnungsliste – vom Datenmodell her mit einer einfachen Tabelle vergleichbar. Ein oder mehreren Inhalten (dt) werden ein oder mehrere Inhalte (dd) zugeordnet.
Wann sollte ich innerhalb des dt noch ein dfn verwenden und wann nicht?
Wenn du ein Glossar hast und in dt ein Begriff steht, der in dd erklärt wird, so solltest du den Begriff im dt zusätzlich mit dfn auszeichnen.
Die mehreren Beispiele beginnend bei dl bis zu dd finde ich dafür recht verständlich. Lies dich da mal von oben durch.
Eine FAQ kann beispielsweise mit dl umgesetzt werden. Dann werden i.d.R. keine Begriffe definiert. Wenn es jedoch ein Glossar ist, sollte mit expliziten dfn-Elementen gearbeitet werden.
Mathias
Hallo dave,
"The dt element itself, when used in a dl element, does not indicate that its contents are a term being defined, but this can be indicated using the dfn element."
Ich versteh das grad nicht. Was sonst habe ich in einem dt?
Bereits in der HTML 4.01-Spezifikation hieß es ja:
"Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words."
http://www.w3.org/TR/html401/struct/lists.html#h-10.3
In der HTML5-variante heißt es also nun auch entsprechend
"The dd element represents the _description_, definition, or _value_, part of a term-description group in a description list (dl element)."
Eine zusätzliche Auszeichnung mit einem DFN-Element halte ich jedoch nur dann für sinnvoll, wenn eine zusätzliche Definition in etwas anderem als in einer reinen Definitionsliste, also z.B. in einer Dialog- oder Beschreibungsliste vorkommt.
Als "Beschreibungsliste könnte ich mir z.B. auch eine Reihe von Bildern oder Grafiken vorstellen, zu denen eine Beschreibung geliefert werden soll. Die Grafik befände sich dann in einem DT-Element und die Beschreibung, die dem im ALT-Attribut enthaltenen oder dem über das LONGDESC-Attribut referenzierten Inhalt der Grafik entsprechen könnte, befände sich dann in dem DD-Element.
Gruß Gernot
Als "Beschreibungsliste könnte ich mir z.B. auch eine Reihe von Bildern oder Grafiken vorstellen, zu denen eine Beschreibung geliefert werden soll. Die Grafik befände sich dann in einem DT-Element und die Beschreibung, die dem im ALT-Attribut enthaltenen oder dem über das LONGDESC-Attribut referenzierten Inhalt der Grafik entsprechen könnte, befände sich dann in dem DD-Element.
Das wäre für mich eher eine gewöhnliche ul jeweils mit figure/img/figcaption. Ene solche Auszeichnung hielte ich für präziser.
longdesc ist übrigens nicht mehr Bestandteil von HTML5.
Mathias
@@molily:
nuqneH
[…] die Beschreibung, die dem im ALT-Attribut enthaltenen oder dem über das LONGDESC-Attribut referenzierten Inhalt der Grafik entsprechen könnte, befände sich dann in dem DD-Element.
In dem Falle gehört nichts ins @alt-Attribut, was seine Existenz an sich infrage stellt. Und die Unsinnigkeit von HTML, ein solches zu verlangen.
longdesc ist übrigens nicht mehr Bestandteil von HTML5.
Und das ist auch gut so. Dummerweise ist @alt immer noch Bestandteil. Jaja, ich weiß: Abwärtskompatibilität. Dennoch hat HTML5 es auch hier versäumt, einen Designfehler von HTML zu berichtigen. Inhalte gehören nicht in Attributwerte. Aber Hixie hat wohl seine Scheuklappen so eingesellt, dass er XHTML 2 außerhalb seines Gesichtsfeldes liegt.
Qapla'
Dummerweise ist @alt immer noch Bestandteil.
Du meinst: img existiert noch (als leeres Element)?
Aber Hixie hat wohl seine Scheuklappen so eingesellt, dass er XHTML 2 außerhalb seines Gesichtsfeldes liegt.
object existiert schon seit HTML 4 und steht bereit, wenn man längeren/komplexeren Alternativtext hat. Was sollte HTML5 zusätzlich tun?
XHTML 2 sah ebenfalls ein img-Element und ein object-Element vor, darüber hinaus als Vereinfachung dieser beiden die generischen src- und srctype-Attribute.
Mathias
@@molily:
nuqneH
Du meinst: img existiert noch (als leeres Element)?
Es kann von mir aus weiterexistieren – nur halt nicht (zwangsweise) als leeres Element.
object existiert schon seit HTML 4 und steht bereit, wenn man längeren/komplexeren Alternativtext hat.
'object' stünde auch für Audio- und Video-Inhalte bereit, wozu also 'audio'- und 'video'-Elemente? HTML5 schafft ja gerade für verschiedene Medien jeweils eigene Elemente, da wäre es widersinnig, das Element für Bildinhalte abzuschaffen.
Was sollte HTML5 zusätzlich tun?
Elementinhalt für 'img' erlauben. Und wie den Wert von @alt zu behandeln. Wenn ein 'img'-Element Inhalt hat, darf es kein @alt-Attribut haben. Wenn es Inhalt und @alt hat, hat der Inhalt Vorrang. (Das ganze Wenn und Aber ist voll im Stil der HTML5-Spec.)
<img src="foo">bar</img> und <img src="foo" alt="bar"/> wären gleichbedeutend. <img src="foo" alt="bar">baz</img> wäre ungültig, bei der Verarbeitung würde "baz" als Alternativtext genommen werden. (Auch etwas als ungültig zu erklären, aber dennoch anzugeben, wie damit umzugehen sei, ist voll im Stil der HTML5-Spec.)
Qapla'
@@Gunnar Bittersmann:
nuqneH
Und [Elementinhalt] wie den Wert von @alt zu behandeln.
Hoppla, das war wohl etwas salopp. Natürlich sollte im Elementinhalt enthaltenes Markup als solches verarbeitet werden, das würde ja gerade den bedeutsamen Unterschied gegenüber dem @alt-Wert ausmachen.
Qapla'
'object' stünde auch für Audio- und Video-Inhalte bereit, wozu also 'audio'- und 'video'-Elemente?
Weil das hier schon dutzende Male diskutiert wurde: siehe Archiv.
Elementinhalt für 'img' erlauben.
Langsam sollten dir die Designprinzipien von HTML5 bekannt sein und es sollte ersichtlich sein, warum HTML5 dies nicht tun würde. Es wäre nicht abwärtskompatibel möglich. Man kann nicht plötzlich ein leeres Element in ein Element mit Inhalt umdefinieren, ohne die Verarbeitung von bestehenden Dokumenten komplett umzustricken. Damit ein Parser weiß, um welchen Typ es sich handelt, müsste er bis zum Ende des Dokuments parsen, schließlich könnte dort noch ein </img> stehen. Man könnte natürlich auch beim ersten schließenden Tag eines geöffneten Elements auf dem Stack das img-Element als inhaltsloses erkennen, z.B. bei <p>Hallo <img> Welt</p> nach dem Einlesen von </p>. Ich kann mir nicht vorstellen, dass sich dieses Verhalten in die recht einfache State-Machine, die der HTML5-Parser ist, integrieren lässt. Wie gesagt sehe ich ohnehin keinen Grund dafür, img aufzubohren, daher weiß ich nicht, welchen Sinn es hat, darüber hypothetisch zu diskutieren.
Mathias
Hi,
Elementinhalt für 'img' erlauben.
Langsam sollten dir die Designprinzipien von HTML5 bekannt sein und es sollte ersichtlich sein, warum HTML5 dies nicht tun würde. Es wäre nicht abwärtskompatibel möglich. Man kann nicht plötzlich ein leeres Element in ein Element mit Inhalt umdefinieren, ohne die Verarbeitung von bestehenden Dokumenten komplett umzustricken.
Wenn man neue Elemente “audio” und “video” einführen kann, hätte man sich auch ein “image” gönnen können …
MfG ChrisB
Wenn man neue Elemente “audio” und “video” einführen kann, hätte man sich auch ein “image” gönnen können …
Hätte man, aber img und object existieren bereits. Wenn image demgegenüber keine neue, spezifische Funktionalität hinzufügt, wie es audio und video gegenüber object und embed unzweifelhaft tun, so gibt es keinen Grund für ein image-Element. Allein aus Konsistenzgründen werden keine neuen Elemente eingeführt.
Zudem gibt es schon ein image-Element: Zwar nicht spezifiziert, aber alle vier großen Browserengines behandeln ein <image> genauso wie ein <img>.
Mathias
Lieber molily,
Hätte man, aber img und object existieren bereits. Wenn image demgegenüber keine neue, spezifische Funktionalität hinzufügt, wie es audio und video gegenüber object und embed unzweifelhaft tun, so gibt es keinen Grund für ein image-Element. Allein aus Konsistenzgründen werden keine neuen Elemente eingeführt.
wenn sich <image src="bild.jpg">Hier der <em>Text der <strong>Bildunterschrift</strong></em></image> als eine vernünftige "Bilderbox" nutzen ließe, die ähnlich wie eine Tabelle einfach einen rechteckigen Raum verbraucht, bei dem oben das Bild und unten der Content steht (mit CSS näher gestaltbar), dann wäre das durchaus eine "neue, spezifische Funktionalität" und damit sehr wohl ein Grund, ein neues Element einzuführen.
Zudem gibt es schon ein image-Element: Zwar nicht spezifiziert, aber alle vier großen Browserengines behandeln ein <image> genauso wie ein <img>.
Meiner Meinung nach ist html5 genauso verkorkst wie die neue deutsche Rechtschreibung. Ich bleibe bei XHTML1strict.
Liebe Grüße,
Felix Riesterer.
Grüße dich, Felix,
wenn sich
<image src="bild.jpg">Hier der <em>Text der <strong>Bildunterschrift</strong></em></image>als eine vernünftige "Bilderbox" nutzen ließe, die ähnlich wie eine Tabelle einfach einen rechteckigen Raum verbraucht, bei dem oben das Bild und unten der Content steht (mit CSS näher gestaltbar), dann wäre das durchaus eine "neue, spezifische Funktionalität" und damit sehr wohl ein Grund, ein neues Element einzuführen.
Das wäre aber schon eine sehr seltsame Funktionsweise. Bisher gibt es zum Glück kein Element, dessen Fallback-Content als automatische Beschreibung dient (da wäre da Gejammer groß).
Wenn du Bilder mit Bildunterschrift erstellen möchtest, dann kannst du das spätestens seit IE8 interoperabel und strukturell einwandfrei.
Zudem gibt es schon ein image-Element: Zwar nicht spezifiziert, aber alle vier großen Browserengines behandeln ein <image> genauso wie ein <img>.
Meiner Meinung nach ist html5 genauso verkorkst wie die neue deutsche Rechtschreibung. Ich bleibe bei XHTML1strict.
Das hat nichts mit HTML5 zu tun, es steht dort lediglich drin, weil es seit 199x so gehandhabt wird.
Gruß, Daniel
Lieber Daniel.S,
Das wäre aber schon eine sehr seltsame Funktionsweise. Bisher gibt es zum Glück kein Element, dessen Fallback-Content als automatische Beschreibung dient (da wäre da Gejammer groß).
hmm, ich hatte irgendwie schon immer mit der "Fallback"-Idee meine Probleme. Das alt-Attribut als Fallback und den Element-Inhalt als Bildunterschrift, wäre das konsensfähig? Damit bleibt die für molily wesentliche "neue Funktionalität" gegeben.0
Wenn du Bilder mit Bildunterschrift erstellen möchtest, dann kannst du das spätestens seit IE8 interoperabel und strukturell einwandfrei.
Klar, aber wie? Als Tabelle? Als hier beschriebenes <dl>-Konstrukt? Als Textabsatz mit passender Klasse? An was genau hattest Du dabei gedacht?
Das hat nichts mit HTML5 zu tun, es steht dort lediglich drin, weil es seit 199x so gehandhabt wird.
Mit der Einführung der von mir vorgeschlagenen Funktionalität wäre das <image>-Element abwärtskompatibel. Oder siehst Du das anders? Wenn HTML-Autoren künftig zwischen <img> und <image> unterscheiden müssen, damit sie die in html5 nach meinem Vorschlag erweiterte Funktionalität nutzen, ist doch Abwärtskompatibilität, oder nicht?
Liebe Grüße,
Felix Riesterer.
Grüße dich, Felix,
hmm, ich hatte irgendwie schon immer mit der "Fallback"-Idee meine Probleme. Das alt-Attribut als Fallback und den Element-Inhalt als Bildunterschrift, wäre das konsensfähig? Damit bleibt die für molily wesentliche "neue Funktionalität" gegeben.0
Ich denke es ist entweder ein Alternativtext oder eine Bildunterschrift erforderlich aber nicht beides, dann wäre nämlich eines überflüssig.
Zudem soll der Elementinhalt ja gerade deshalb als Fallback dienen, weil in einem alt-Attribut keine Elemente notiert werden können.
Hätten die Browserhersteller ein klein wenig mehr Interesse an generierten Inhalten a la CSS 3 hätten wir längst die Möglichkeit das alt-Attribut sichtbar zu machen. Aber das hat experimentell eben nur Opera.
Klar, aber wie? Als Tabelle? Als hier beschriebenes <dl>-Konstrukt? Als Textabsatz mit passender Klasse? An was genau hattest Du dabei gedacht?
Eine Tabelle bestehend aus einer Tabellenzelle und einem caption-Element (dann wäre es auch in Uralt-IEs möglich und von der Struktur her nicht unzumutbar), eine Definitionsliste oder eben das in HTML5 hinzugekommene figure-Element.
Der Grundgedanke läuft darauf hinaus, dass ein Float als Tabelle dargestellt wird (caption wird nicht breiter als die Tabelle selbst). Das scheint mir die einfachste Lösung zu sein.
Mit der Einführung der von mir vorgeschlagenen Funktionalität wäre das <image>-Element abwärtskompatibel. Oder siehst Du das anders? Wenn HTML-Autoren künftig zwischen <img> und <image> unterscheiden müssen, damit sie die in html5 nach meinem Vorschlag erweiterte Funktionalität nutzen, ist doch Abwärtskompatibilität, oder nicht?
Nein, sobald du image nicht mehr als inhaltsleeres Element definierst, brichst du mit der Rückwärtskompatibilität. Manche Webseite nutzt image und verlässt sich darauf, dass das Element identisch zum img-Element verarbeitet wird (ob nun absichtlich oder nicht spielt dabei keine Rolle).
Gruß, Daniel
@@molily:
nuqneH
Weil das hier schon dutzende Male diskutiert wurde: siehe Archiv.
Nichts lag mir ferner als eine neue Diskussion darüber anzuzetteln. Meine Bemerkung war nicht contra 'audio' und 'video', sondern pro 'img'.
[…] es sollte ersichtlich sein, warum HTML5 dies nicht tun würde. Es wäre nicht abwärtskompatibel möglich.
Ähm, stimmt. In XML wäre das problemlos möglich.
Leider ist HTML5 nicht den XML-Weg gegangen. Vielleicht hat Hixie die Vorteile von XML immer noch nicht verstanden.
So bleibt also als einzige mögliche Einbindung von Bildern mit richtigen Alternativtexten das 'object'-Element. Dummerweise geht das im IE erst ab Version 9.
Qapla'
@@Gunnar Bittersmann:
nuqneH
[…] 'object'-Element. Dummerweise geht das im IE erst ab Version 9.
s/9/8
Qapla'
Grüße dich, Gunnar,
[…] es sollte ersichtlich sein, warum HTML5 dies nicht tun würde. Es wäre nicht abwärtskompatibel möglich.
Ähm, stimmt. In XML wäre das problemlos möglich.
Ähm, in X(HT)ML als text/html wäre es dann aber immernoch nicht möglich.
Leider ist HTML5 nicht den XML-Weg gegangen. Vielleicht hat Hixie die Vorteile von XML immer noch nicht verstanden.
Niemand will XML seine Vorteile aberkennen. Allerdings scheinst du noch nicht verstanden zu haben, welche Vorteile in einer einheitlichen Verabreitung von HTML liegen.
Nebenbei, soweit ich mich erinnere, kann HTML5 durchaus als XML verarbeitet werden.
So bleibt also als einzige mögliche Einbindung von Bildern mit richtigen Alternativtexten das 'object'-Element. Dummerweise geht das im IE erst ab Version 9.
Version 8, wie du bereits richtig festgestellt hast. Ein image-Element hättest du erst ab IE9 nutzen können, wo liegt also der Nachteil?
Wenn du IE7 und älter berücksichtigen willst, musst du für CSS und Skripte schon Zusatzarbeit leisten. Ein Element im Stil von object/image zu emulieren wäre keine Schwierigkeit. Es müsste sich nur mal jemand hinsetzen und einen guten Workaround entwickeln, der Acessibility und andere Prinzipien berücksichtigt.
Anscheinend ist die Nachfrage danach aber nicht wirklich hoch, oder es hat niemand Lust, die wenigen Benutzer, die im "Westen" noch mit IE6 und 7 surfen derart zu verwöhnen.
Einfach geduldig sein, die alten IEs verschwinden von selbst.
Gruß, Daniel
[…] es sollte ersichtlich sein, warum HTML5 dies nicht tun würde. Es wäre nicht abwärtskompatibel möglich.
Ähm, stimmt. In XML wäre das problemlos möglich.
Auch das braucht immer noch jemanden, der die Implikationen des erweiterten Schemas implementiert; schliesslich ist XML kein Zauberstab, der einfach so replaced content, spezielle Anpassungen zur Vermeidung von Reflow, Implikationen für den Ressourcen-Nachlader, vielleicht gar CORS und so implementiert. Manchmal bin ich auch arg genervt von der Browser-Hersteller-First-Ideologie von Hixie. Sie ganz zu ignorieren halte ich aber für ebenso verkehrt, wenn nicht noch verkehrter.
