Welches HTML Tag für Zitate

[Axel Jack Metayer]

Hi,

auf meiner Seite
http://www.kfz.de/news/zitate.php
stelle ich Zitate und den Autor dar.

Ich bin auf der suche nach dem richtigem HTML Tag für die Auszeichnung. Im Forum habe ich ein wenig gesucht und bin auf CITE und BLOCKQUOTE (http://selfhtml.teamone.de/html/text/zitate_adressen.htm#adressen)
gekommen.

ich tendiere dazu BLOCKQUOTE zu benutzen (im Moment ist alles noch mit P gemacht).

Was meint ihr dazu?

Danke
Axel

[MudGuard]

Hi,

ich tendiere dazu BLOCKQUOTE zu benutzen (im Moment ist alles noch mit P gemacht).

Als Block-Element blockquote, als inline-Element q.

cite ist für eine Quellenangabe gedacht (cite: Contains a citation or a reference to other sources. - Citation = Literaturstelle).

cu,
Andreas

[Michael Jendryschik]

Hallo,

Ich bin auf der suche nach dem richtigem HTML Tag für die Auszeichnung. Im Forum habe ich ein wenig gesucht und bin auf CITE und BLOCKQUOTE (http://selfhtml.teamone.de/html/text/zitate_adressen.htm#adressen)
gekommen.

ich tendiere dazu BLOCKQUOTE zu benutzen (im Moment ist alles noch mit P gemacht).

Was meint ihr dazu?

Vielleicht hilft dir das Beispiel unter http://jendryschik.de/wsdev/einfuehrung/xhtml/bodyelemente.html#q weiter.

Gruß,

MI

[molily]

Vielleicht hilft dir das Beispiel unter http://jendryschik.de/wsdev/einfuehrung/xhtml/bodyelemente.html#q weiter.

Ein Zitat ist vor allem dadurch intuitiv erkennbar, dass es in Zitatzeichen eingefasst ist. Die Zitatliste des OPs macht es besonders deutlich. Bei der Verwendung von q ist dies, wie du schreibst, nicht möglich. Dieses Dilemma ist nicht auflösbar. Um die Bedeutung von q wenigstens halbwegs zu kommunizieren, ist man sogar darauf angewiesen, durch zusätzliche bedeutungslose span-Elemente andere Formatierungen anzuwenden, damit ersichtlich wird, dass es sich um ein Zitat handelt. Dies potenziert den Aufwand und erzeugt murksigen, schlecht wartbaren Code. Das cite-Attribut wird auch nicht umgesetzt. Damit verliert die Auszeichnung über q jeglichen Sinn. Daher ist q inpraktikabel und ein schönes Beispiel für semantisches Markup, das beim Benutzer in der Regel nicht ankommt.

[at]

Hallo.

Ein Zitat ist vor allem dadurch intuitiv erkennbar, dass es in Zitatzeichen eingefasst ist.

Das ist jedenfalls die gängigste Form.

Die Zitatliste des OPs macht es besonders deutlich. Bei der Verwendung von q ist dies, wie du schreibst, nicht möglich. Dieses Dilemma ist nicht auflösbar. Um die Bedeutung von q wenigstens halbwegs zu kommunizieren, ist man sogar darauf angewiesen, durch zusätzliche bedeutungslose span-Elemente andere Formatierungen anzuwenden, damit ersichtlich wird, dass es sich um ein Zitat handelt.

Warum dem <span> eine Klasse zur Formatierung mitgegeben wird, statt direkt das <q> zu formatieren, erschleißt sich mir nicht.

Dies potenziert den Aufwand und erzeugt murksigen, schlecht wartbaren Code. Das cite-Attribut wird auch nicht umgesetzt. Damit verliert die Auszeichnung über q jeglichen Sinn. Daher ist q inpraktikabel und ein schönes Beispiel für semantisches Markup, das beim Benutzer in der Regel nicht ankommt.

Die Zitatzeichen ähnlich handhabbar zu machen wie die Aufzählungszeichen in Listen, ist für mich der einzig gangbare Weg. In Verbindung mit ":before" und ":after" ergäbe sich meines Erachtens das Optimum.
MfG, at

[molily]

Um die Bedeutung von q wenigstens halbwegs zu kommunizieren, ist man sogar darauf angewiesen, durch zusätzliche bedeutungslose span-Elemente andere Formatierungen anzuwenden, damit ersichtlich wird, dass es sich um ein Zitat handelt.

Warum dem <span> eine Klasse zur Formatierung mitgegeben wird, statt direkt das <q> zu formatieren, erschleißt sich mir nicht.

Was meinst du damit? Michaels Seite erklärt doch, warum span-Elemente nötig sind, darauf bezog ich mich:
»In einigen fehlerhaften Browsern macht das Element q hingegen Probleme. [...] NN4 kennt das Element q überhaupt nicht. Das Zitat ist in diesen Browsern nicht von gewöhnlichen Fließtext zu unterscheiden und dadurch nicht direkt als solches erkennbar.  Ein möglicher Workaround ist eine Verwendung von q und span zusammen. Farb- oder Schriftdeklarationen könnte man dann für span.zitat vornehmen, somit wäre das Zitat auch im NN4 von Fließtext zu unterscheiden.«
Es ist also nicht möglich, q direkt zu formatieren, und da q vollkommen unbekannt ist, nützen auch Nachkommensselektoren wie »q span« nichts. Daher die Klasse.

Ein ähnliches Problem ergibt sich mit abbr: Das Element kennt MSIE nicht (auf MSIE basierende Screenreader allerdings schon, es ist auch als DOM-Knoten vorhanden) und ignoriert jegliche Styles und auch das title-Attribut. Möglich wäre <abbr title="..."><span class="abkuerzung" title="...">...</span></abbr>. Glücklicherweise kennt MSIE acronym, was auch viele anstelle von abbr nutzen.

[at]

Hallo.

Was meinst du damit? Michaels Seite erklärt doch, warum span-Elemente nötig sind, darauf bezog ich mich:

[...]

Es ist also nicht möglich, q direkt zu formatieren, und da q vollkommen unbekannt ist, nützen auch Nachkommensselektoren wie »q span« nichts. Daher die Klasse.

Das hatte ich falsch verstanden, sorry.

Ein ähnliches Problem ergibt sich mit abbr: Das Element kennt MSIE nicht (auf MSIE basierende Screenreader allerdings schon, es ist auch als DOM-Knoten vorhanden) und ignoriert jegliche Styles und auch das title-Attribut. Möglich wäre <abbr title="..."><span class="abkuerzung" title="...">...</span></abbr>. Glücklicherweise kennt MSIE acronym, was auch viele anstelle von abbr nutzen.

Wer <acronym> statt <abbr> nutzt, wird aber auch nicht davor zurückschrecken <cite> für <q> zu einzusetzen.
MfG, at

[molily]

Ein ähnliches Problem ergibt sich mit abbr: Das Element kennt MSIE nicht (auf MSIE basierende Screenreader allerdings schon, es ist auch als DOM-Knoten vorhanden) und ignoriert jegliche Styles und auch das title-Attribut. Möglich wäre <abbr title="..."><span class="abkuerzung" title="...">...</span></abbr>. Glücklicherweise kennt MSIE acronym, was auch viele anstelle von abbr nutzen.

Wer <acronym> statt <abbr> nutzt, wird aber auch nicht davor zurückschrecken <cite> für <q> zu einzusetzen.

Was hat das miteinander zu tun? q zu verwenden, führt wie gesagt momentan nur zu Problemen, cite hat damit aber nichts zu tun und ist als Ersatz weniger sinnvoll und weniger kompatibel als ein span mit Klasse. Es gibt keinen Grund und bringt keinen Vorteil, bewusst und absichtlich cite anstatt q einzusetzen.
Ganz anders ist es bei acronym versus abbr. Zum einen interessiert die meisten Webautoren die Unterscheidung zwischen Akronymen und Abkürzungen praktisch sowieso nicht und ihnen ist es in dieser Hinsicht egal, welches Element sie letztlich verwenden. Ihnen ist es aber nicht egal, ob die Auszeichnung der Abkürzung überhaupt ankommt, das Element formatierbar ist und das title-Attribut zugänglich ist. Wie ich geschildert habe, gibt es gute Gründe, acronym anstatt abbr zu nutzen. Wenn das Schreiben von logischem Markup nicht nur ein ansonsten zweck-, nutz- und sinnloser autoerotischer Fetisch des Autors sein soll, sondern konkret die Benutzbarkeit verbessern soll, ist acronym deutlich effektiver als abbr.

[at]

Hallo.

Wer <acronym> statt <abbr> nutzt, wird aber auch nicht davor zurückschrecken <cite> für <q> zu einzusetzen.

Was hat das miteinander zu tun?

[...]

Ganz anders ist es bei acronym versus abbr. Zum einen interessiert die meisten Webautoren die Unterscheidung zwischen Akronymen und Abkürzungen praktisch sowieso nicht und ihnen ist es in dieser Hinsicht egal, welches Element sie letztlich verwenden.

Ja, genau das habe ich auf <q>/<cite> übertragen, deren Funktion den meisten Autoren auch entweder unbekannt oder offenbar egal ist.

Ihnen ist es aber nicht egal, ob die Auszeichnung der Abkürzung überhaupt ankommt, das Element formatierbar ist und das title-Attribut zugänglich ist.

Dies wäre mit <cite> gewährleistet -- daher mein Vergleich.

Wie ich geschildert habe, gibt es gute Gründe, acronym anstatt abbr zu nutzen. Wenn das Schreiben von logischem Markup nicht nur ein ansonsten zweck-, nutz- und sinnloser autoerotischer Fetisch des Autors sein soll, sondern konkret die Benutzbarkeit verbessern soll, ist acronym deutlich effektiver als abbr.

Viele Abkürzungen sind aber eben keine Akronyme, selbst welche nicht, bei denen dies nahe läge ("ADAC" etc.).
MfG, at

[emu]

Hallo!

Zum einen interessiert die meisten Webautoren die Unterscheidung zwischen Akronymen und Abkürzungen praktisch sowieso nicht und ihnen ist es in dieser Hinsicht egal, welches Element sie letztlich verwenden.

Die Mehrheit der Webautoren weiß vermutlich nichts davon, dass man Abkürzungen speziell auszeichnen kann. Bisher kam man mit diesem Zustand auch mehr oder weniger gut zurecht, Abkürzungen sind ja ohnehin per se schlechter Stil (das bemerken selbsternannte Sprachschützer seit ewigen Zeiten in periodischen Abständen), im Web herrscht nicht Speichermangel, also kann man auch ausschreiben und generell hat das Abkürzungsunwesen auf einschlägigen Seiten durch die Entdeckung dieser Elemente überhand genommen. Besser wäre es vielleicht sogar, ihre Existenz ganz zu verschweigen, sie animiert augenscheinlich zu erhöhtem Abkürzungseinsatz, als sinnvoll wäre.

Es gibt keinen sinnvollen Grund, Regelungen zu brechen, um unwichtige, zu schlechtem Schreibstil verführende Elemente in manchen Browser darstellen zu können. Regelungen an dafür sinnvollen Stellen zu brechen, wo es keine andre Möglichkeit gibt, darüber kann man reden, aber es besteht gar kein Bedarf, augenscheinlich falsch auszuzeichnen. Das wäre ein Workaround und der ist mit aller Kraft zu vermeiden.

autoerotischer Fetisch

Herzlichen Glückwunsch, Egg's Law ist erfüllt.

emu

[molily]

Die Mehrheit der Webautoren weiß vermutlich nichts davon, dass man Abkürzungen speziell auszeichnen kann. Bisher kam man mit diesem Zustand auch mehr oder weniger gut zurecht, Abkürzungen sind ja ohnehin per se schlechter Stil (das bemerken selbsternannte Sprachschützer seit ewigen Zeiten in periodischen Abständen), im Web herrscht nicht Speichermangel, also kann man auch ausschreiben und generell hat das Abkürzungsunwesen auf einschlägigen Seiten durch die Entdeckung dieser Elemente überhand genommen.

Ja, das ist mir schon vor längerer Zeit aufgefallen, als immer mehr die entsprechende Zugänglichkeitsrichtlinie beachteten und alle Nase lang triviale Abkürzungen mit abbr auszeichneten. Ich hatte damals eine Liste von häufigen Abkürzungen erstellt, welche in der Regel direkt ausgeschrieben werden sollten, anstatt als Abkürzung eine Barriere zu erzeugen, welche mit abbr eher schlecht als recht kompensiert wird:

<abbr title="beziehungsweise">bzw.</abbr> <abbr title="und so weiter">usw.</abbr> <abbr title="zum Beispiel">z.B.</abbr> <abbr title="beispielsweise">bspw.</abbr> <abbr title="das heißt">d.h.</abbr> <abbr title="oder ähnliches">o.ä.</abbr> <abbr title="unter Umständen">u.U.</abbr> <abbr title="in der Regel">i.d.R.</abbr> <abbr title="zur Zeit">z.Zt.</abbr> <abbr title="vergleiche">vgl.</abbr> <abbr title="gegebenenfalls">ggf.</abbr> <abbr title="diverse">div.</abbr> <abbr title="vermutlich">vmtl.</abbr> <abbr title="und dergleichen">udergl.</abbr> <abbr title="folgende">ff.</abbr> <abbr title="deutsch">dt.</abbr> <abbr title="englisch">engl.</abbr> <abbr title="Kilobyte">KB</abbr> <abbr title="Euro">EUR</abbr> <abbr title="inklusive">incl.</abbr> <abbr title="zirka">ca.</abbr> <abbr title="und andere">et al.</abbr> <abbr title="und andere">u.a.</abbr> <abbr title="et cetera">etc.</abbr> <abbr title="versus">vs.</abbr> <abbr title="das heißt">i.e.</abbr> <abbr title="zum Beispiel">e.g.</abbr>

Besser wäre es vielleicht sogar, ihre Existenz ganz zu verschweigen, sie animiert augenscheinlich zu erhöhtem Abkürzungseinsatz, als sinnvoll wäre.

Letzteres mag stimmen. Vor allem stört die Hervorhebung durch die Unterstreichung oder Kursivierung, wenn die Bedeutungen der Abkürzungen sowieso bekannt sind, da müsste man wieder Klassen vergeben, um triviale und neue Abkürzungen zu trennen. Aufgrund von unpassenden und kontraproduktiven Anwendung lässt sich aber nicht die Technik an sich verdammen.

Es gibt keinen sinnvollen Grund, Regelungen zu brechen, um unwichtige, zu schlechtem Schreibstil verführende Elemente in manchen Browser darstellen zu können.

Man kann nicht alle Arten von Abkürzungen über einen Kamm scheren und insgesamt als schlecht bezeichnen. Überhaupt halte ich nichts davon, hier pauschal urteilen zu wollen. Abkürzungen und entsprechende Möglichkeiten der Auszeichnung haben in vielen Fällen ihren Sinn und erleichtern die Lesbarkeit. Zu schlechterem Stil und »Abküfi« führen sie nur potenziell, nicht zwangsläufig. In meinem Artikel über position:fixed und Anker etwa kommt die Abkürzung »CSS« 58 Mal vor und ich sehe nicht ein, jedes Mal »Cascading Stylesheets« zu schreiben. Genauso unsinnig wäre aber die Auszeichnung aller 58 Vorkommnisse mit abbr und entsprechendem title-Attribut. Der Text setzt voraus, dass der Leser weiß, was HTML und was CSS bedeutet, er hat auch nicht den Anspruch, dies zu erklären. Wenn der Text allerdings einen Sachverhalt vermitteln wollen würde, bei dessen Schilderung neue Abkürzungen erfunden werden, welche als solche keine allgemeine Relevanz und Verbreitung haben, würde ich auch jede Abkürzung entsprechend auszeichnen, sodass die Bedeutung an jeder Stelle wieder ins Gedächtnis gerufen werden kann.

Regelungen an dafür sinnvollen Stellen zu brechen, wo es keine andre Möglichkeit gibt, darüber kann man reden,

Es bestehen gute Gründe, die Regelung der Trennung zwischen Akronymen und Abkürzungen in HTML für unsinnig und entsprechend hinfällig zu betrachten, die tatsächlich Umsetzung der Browser und Zusatzsoftware ist da sowieso eindeutig, es wird nicht unterschieden.

aber es besteht gar kein Bedarf, augenscheinlich falsch auszuzeichnen.

Du meinst, dass kein Bedarf bestehen darf oder sollte, das ändert aber nichts an der realen Situation.

In den Fällen, in denen ich den Einsatz von Abkürzungen und deren Auszeichnung für sinnvoll erachte, ist es mir gleichgültig, ob Puristen in ihrem ästhetischen Empfinden gestört werden, wenn diese Auszeichnung vor allem praktischen Wert hat und in der ätherischen Semantiksphäre weniger Sinn hat. Mein Kriterium ist, ob die logische Bedeutung des Markups angemessen vermittelt wird. Und ich sehe wie gesagt keinen Nachteil dieser in den Augen einiger Pedanten »falschen« Auszeichnung.

Das wäre ein Workaround und der ist mit aller Kraft zu vermeiden.

Schätzchen, Workarounds sind das wichtigste Werkzeugs eines Webautors.

autoerotischer Fetisch

Herzlichen Glückwunsch, Egg's Law ist erfüllt.

Sicherlich nicht. Jeder kann meinetwegen nach eigenem Gutdünken bis zum Exzess Markup-Hirnwichserei betreiben und sich der Welt und Umwelt voraus wähnen. Derjenige kann dann in der entsprechenden Liga der Alphageeks mitposen und sich heimelig fühlen, das ist ja schön, wenn jemand darin aufgeht. Das ist dann eben, wie ich schrieb, ein Fetisch, der als solcher seine Daseinsberechtigung hat, weil er demjenigen Befriedigung verschafft. Darüber hinaus und abgesehen davon erfüllt er aber wie gesagt keinen Zweck, tangiert niemanden und überschneidet sich in keinem Punkt mit dem Webauthoringdiskurs. Was mich hingegen stört, ist, dass denjenigen Autoren, die tatsächlich benutzbarere und zugänglichere Seiten schreiben, unterstellt wird, sie würden auch vor weiterem Markup»missbrauch« nicht »zurückschrecken«.

[at]

Hallo.
Bis zum folgenden Punkt kann ich dir uneigeschränkt zustimmen.

Es bestehen gute Gründe, die Regelung der Trennung zwischen Akronymen und Abkürzungen in HTML für unsinnig und entsprechend hinfällig zu betrachten, die tatsächlich Umsetzung der Browser und Zusatzsoftware ist da sowieso eindeutig, es wird nicht unterschieden.

Sollten Vorlese-Browser tatsächlich keinen Unterschied zwischen etwa der Abkürzung "HTML" (zu sprechen: "H. T. M. L.") und dem Akronym "DOS" (zu sprechen: "Dos") machen, hielte ich dies für einen großen Mangel. Ob dieser Mangel von in dieser Hinsicht schlechten Browsern, einem reduzierten Syntax-Umfang oder der Unaufmerksamkeit von Autoren verursacht wird, halte ich in Bezug auf das Ergebnis für sekundär. In Bezug auf die Möglichkeit, eine Verbesserung einer vorhandenen Auszeichnung vorzunehmen, wäre es hingegen tragisch, wenn der Syntax-Umfang dies nicht mehr zuließe.

Schätzchen, Workarounds sind das wichtigste Werkzeugs eines Webautors.

Deine nächsten Ausführungen habe ich zwar nach drei Zeilen abbrechen müssen, aber mit dem oberen Satz bist du reif für die Zitatesammlung.
MfG, at

[Linksetzer]

Hallo!

Sollten Vorlese-Browser tatsächlich keinen Unterschied zwischen etwa der Abkürzung "HTML" (zu sprechen: "H. T. M. L.") und dem Akronym "DOS" (zu sprechen: "Dos") machen

http://www.w3.org/TR/css3-speech/

emu

[at]

Hallo.

http://www.w3.org/TR/css3-speech/

Na, dann habe ich ja noch Zeit.
MfG, at

[molily]

Sollten Vorlese-Browser tatsächlich keinen Unterschied zwischen etwa der Abkürzung "HTML" (zu sprechen: "H. T. M. L.") und dem Akronym "DOS" (zu sprechen: "Dos") machen

http://www.w3.org/TR/css3-speech/

Das ist schon mit CSS 2 möglich. http://www.w3.org/TR/REC-CSS2/aural.html#propdef-speak Aber kein Browser/keine Zusatzsoftware außer dem unbedeutenden Emacspeak kann das.

[molily]

Hallo.
Bis zum folgenden Punkt kann ich dir uneigeschränkt zustimmen.

Es bestehen gute Gründe, die Regelung der Trennung zwischen Akronymen und Abkürzungen in HTML für unsinnig und entsprechend hinfällig zu betrachten, die tatsächlich Umsetzung der Browser und Zusatzsoftware ist da sowieso eindeutig, es wird nicht unterschieden.

Sollten Vorlese-Browser tatsächlich keinen Unterschied zwischen etwa der Abkürzung "HTML" (zu sprechen: "H. T. M. L.") und dem Akronym "DOS" (zu sprechen: "Dos") machen, hielte ich dies für einen großen Mangel.

Mir ging es eher darum, dass abbr und acronym in HTML schlecht definiert sind und die Konvention, dass acronym ausgesprochen wird, abbr aber buchstabiert wird, so nicht verbrieft ist. »GmbH« wird niemand als Wort sprechen, dennoch ist es ein Beispiel für ein Akronym laut W3C-Spec. Anders herum wird nicht jede Abkürzung buchstabiert. Daher weiß ich nicht, wie die Auszeichnung über abbr und acronym dem Browser eine Information über die Aussprache geben kann.

Die mir bekannten Screenreader nehmen acronym und abbr nicht zum Anlass, in einen bestimmten Vorlesemodus zu fallen. Sie entscheiden anhand anderer Kriterien, ob eine Buchstabenfolge buchstabiert oder als Wort ausgesprochen wird. Und diese Algorithmen werden gleichsam auf alle Wörter angewendet. »<abbr>DOS</abbr>«, »<acronym>DOS</acronym>« und »DOS« werden also gleich ausgesprochen.

Ob dieser Mangel von in dieser Hinsicht schlechten Browsern, einem reduzierten Syntax-Umfang oder der Unaufmerksamkeit von Autoren verursacht wird, halte ich in Bezug auf das Ergebnis für sekundär. In Bezug auf die Möglichkeit, eine Verbesserung einer vorhandenen Auszeichnung vorzunehmen, wäre es hingegen tragisch, wenn der Syntax-Umfang dies nicht mehr zuließe.

So oder so ist es schon seit HTML 4.01 die Meinung des W3Cs, dass solche die Präsentation betreffenden Informationen ins aural-Stylesheet gehören, insofern ist XHTML 2 nur konsequent und es geht zumindest theoretisch nicht die Möglichkeit der Differenzierung verloren.

[at]

Hallo.

Mir ging es eher darum, dass abbr und acronym in HTML schlecht definiert sind und die Konvention, dass acronym ausgesprochen wird, abbr aber buchstabiert wird, so nicht verbrieft ist.

Das ist richtig -- und das W3C liegt damit ja nicht einmal falsch. Je mehr ich darüber nachdenke, dest mehr gelange ich zu der Erkenntnis, dass ich eigentlich nur versuche, Unzulänglichkeiten der (auralen) Darstellung mit einer eigenen Interpretation von HTML auszugleichen. Ich möchte das mit Layout-Tabellen vergleichen -- ja, ich weiß, jeder Vergleich hinkt -- und in Zukunft daraus verzichten, diese Elemente in der bisherigen Weise anzuwenden.

Die mir bekannten Screenreader nehmen acronym und abbr nicht zum Anlass, in einen bestimmten Vorlesemodus zu fallen. Sie entscheiden anhand anderer Kriterien, ob eine Buchstabenfolge buchstabiert oder als Wort ausgesprochen wird. Und diese Algorithmen werden gleichsam auf alle Wörter angewendet. »<abbr>DOS</abbr>«, »<acronym>DOS</acronym>« und »DOS« werden also gleich ausgesprochen.

Dann wird wohl innerhalb der einzelnen Browser jeweils eine Liste von Wörtern bestehen, die zusammengezogen werden. Somit bliebe mir zumindest erspart "A. D. A. C." zu schreiben, wenn es nicht "Adac" gesprochen werden soll. Das Heranziehen "anderer Kriterien" hieße ansonsten "raten", wogegen ich natürlich machtlos wäre.

So oder so ist es schon seit HTML 4.01 die Meinung des W3Cs, dass solche die Präsentation betreffenden Informationen ins aural-Stylesheet gehören, insofern ist XHTML 2 nur konsequent und es geht zumindest theoretisch nicht die Möglichkeit der Differenzierung verloren.

Da stimme ich dir gerne zu -- und verlängere gleich mein Abo für "Warten auf Gates" (vielleicht mit H. Schmidt?).
MfG, at

[emu]

Hallo!

Ja, das ist mir schon vor längerer Zeit aufgefallen, als immer mehr die entsprechende Zugänglichkeitsrichtlinie beachteten und alle Nase lang triviale Abkürzungen mit abbr auszeichneten.

Bigotterie ist eben in allen Bereichen der Barrierefreiheitsdiskussion derzeit fast vorherrschend, zuerst kräftig indirekt unterstützt, mittlerweile bekämpft von den großen Experten.

Aufgrund von unpassenden und kontraproduktiven Anwendung lässt sich aber nicht die Technik an sich verdammen.

Das habe ich auch nicht getan, denn Opfer solcher Scheinargumente bin ich in der Vergangenheit mehrmals geworden. Im Gegenteil, ich finde die Möglichkeit, Abkürzungen speziell auszuzeichnen, nicht schlecht, aber doch nicht so notwendig, dass man Elemente zweckentfremden muss. In diesem Fall ist mit die Nichtnutzung dieser Möglichkeit lieber als Yet another Workaround.

CSS

Das ist ein schlechtes Beispiel, ist doch CSS zwar an sich eine Abkürzung, aber schon zum Begriff geworden, während Cascading Style Sheets auch vielen Webautoren nicht mehr verständlich wäre. Etwas weiter fortgeschritten ist diese Tendenz bei den allseits beliebten Abkürzungen Laser und Radar.

Ich schlage vor, CSS gar nicht als Abkürzung auszuzeichnen, bestenfalls in Einführungen zu erklären (denn aus Cascading Style Sheet wird wohl kaum einer schlau, der nicht ohnehin schon mit derartigen Dingen vertraut ist).

Bliebe ein Beispiel zu nennen, wo der Einsatz dieses Elementes derzeit sinnvoll ist.

Es bestehen gute Gründe, die Regelung der Trennung zwischen Akronymen und Abkürzungen in HTML für unsinnig und entsprechend hinfällig zu betrachten

Der Meinung bin ich ebenfalls.
(Wider ACK und d'accord!)

Das wäre ein Workaround und der ist mit aller Kraft zu vermeiden.
Schätzchen, Workarounds sind das wichtigste Werkzeugs eines Webautors.

Das halte ich aber für ein Gerücht. Freilich, an vielerlei Stellen ist der Workaround die einzige praktikable Möglichkeit, besser immerhin als eine wirklichkeitsfremde Lösung, aber es gilt, den Workaround als Mittel der Seitengestaltung möglichst zu vermeiden. Erstens, weil er immer unsauber ist, zweitens weil es das schöne BWL-Wort Zukunftssicherheit gibt.

autoerotischer Fetisch
Herzlichen Glückwunsch, Egg's Law ist erfüllt.
Sicherlich nicht.

Du hast deinen Diskussionspartnern vorgeworfen, sie würde bestimmte Dinge tun, weil sie es sexuell nötig hätten, exakt das beschreibt Egg's Law. Ich kann mit nicht ganz erklären, warum gerade du auf einen derart primitiven Zug der Diskussionsführung aufspringst. Dass die Ansichten der Hurra-Barrierenbefreier, von denen du dich eben schon vor einiger Zeit losgelöst hast, manchmal frustrierend sind, gut, aber das rechtfertigt nicht, ausfällig zu werden.

Ich hoffe nur, du hast deinen letzten Absatz nicht auf mich bezogen.

emu

[molily]

Das wäre ein Workaround und der ist mit aller Kraft zu vermeiden.
Schätzchen, Workarounds sind das wichtigste Werkzeugs eines Webautors.

Das halte ich aber für ein Gerücht. Freilich, an vielerlei Stellen ist der Workaround die einzige praktikable Möglichkeit, besser immerhin als eine wirklichkeitsfremde Lösung, aber es gilt, den Workaround als Mittel der Seitengestaltung möglichst zu vermeiden. Erstens, weil er immer unsauber ist, zweitens weil es das schöne BWL-Wort Zukunftssicherheit gibt.

So formuliert stimme ich zu. »Ein Workaround ist mit aller Kraft zu vermeiden« ist eine andere Aussage als »es gilt, den Workaround möglichst zu vermeiden«. »Mit aller Kraft zu vermeiden« hieße in der Regel, sich gleichgültig gegenüber Kompatibilitätsproblemen zu verhalten und Darstellungsfehler oder die Nichtumsetzung bzw. fehlende Funktionalität eines bestimmten Seitenmerkmals als solche hinzunehmen. Ein halbwegs elaboriertes CSS-Layout beispielsweise ist heutzutage nicht ohne Hacks und Workarounds denkbar. Wenn die Regel mit der obersten Priorität wäre, Workarounds unbedingt zu vermeiden, müsste auf vieles ersatzlos verzichtet werden und die Seite würde letztlich weniger benutzbar und zugänglich sein. Es gibt solche Autoren, die nicht, nimmer und nie zu Zugeständnissen bereit sind und entsprechend für Mozilla »optimieren«. Workarounds sind meist in der Tat nicht nachhaltig, sogar oft tickende Zeitbomben, die ständiger Beobachtung bedürfen, aber sie bieten Möglichkeiten im Hier und Jetzt, auf die Webautoren verständlicherweise nicht verzichten wollen, über die die Webautoren sogar ihr Selbstverständnis definieren.

autoerotischer Fetisch
Herzlichen Glückwunsch, Egg's Law ist erfüllt.
Sicherlich nicht.

Du hast deinen Diskussionspartnern vorgeworfen, sie würde bestimmte Dinge tun, weil sie es sexuell nötig hätten, exakt das beschreibt Egg's Law.

Das ist wirklich Unsinn, ich habe es groß und breit erklärt. Ich maße mir weder im allgemeinen noch im speziellen an, die Bedürfnisse anderer in irgendeiner Form zu beurteilen und respektiere diesbezüglich jedwede Freiheiten. Alle möglichen Handlungen könnte man libidinösen Hintergrund zuschreiben, ich nehme mir nicht heraus, diesen zu kritisieren, ich werfe es niemandem vor, ganz im Gegenteil, und das habe ich auch ausdrücklich gesagt. Ich beteilige mich selbst andauernd an den von der Realität längst abgekoppelten schöngeistigen Semantikdiskussionen. So interessant und intellektuell befriedigend die Suche nach der »korrekten« Auszeichnung auch sein mag, so wenig hilft es in der Regel dabei, tatsächlich bessere Webseiten zu schreiben.

Habe ich alles schon gesagt, wenn du es überlesen willst, bitte, dann habe ich eben laut Law »verloren«, damit kann ich leben.

[at]

Hallo.

So interessant und intellektuell befriedigend die Suche nach der »korrekten« Auszeichnung auch sein mag, so wenig hilft es in der Regel dabei, tatsächlich bessere Webseiten zu schreiben.

Das kann ich nicht nachvollziehen. Oder anders: Das ist zunächst einmal nur deine Meinung ;-)
MfG, at

[molily]

So interessant und intellektuell befriedigend die Suche nach der »korrekten« Auszeichnung auch sein mag, so wenig hilft es in der Regel dabei, tatsächlich bessere Webseiten zu schreiben.

Das kann ich nicht nachvollziehen.

Wir haben hier doch ein wunderbar konkretes Beispiel. Mal angenommen, es wäre klar getrennt, für was abbr und für was acronym gebraucht werden soll und angenommen, dass auf Abkürzungen nicht pauschal verzichtet wird. Welche Vorteile für den Benutzer bringt es dann, eine Abkürzung als abbr auszuzeichnen, weil das »semantisch korrekt« ist? Im Thread habe ich meiner Meinung nach anschaulich erläutert, warum es dem Benutzer unter den gegenwärtigen Bedingungen extrem wenig bringt. Insofern hilft die Erkenntnis, was gemäß den Specs und anderer abgehobener Kriterien semantisch stimmig wäre, in diesem Fall kein Stück weiter hinsichtlich der Verbesserung der Seite.
Und nein, eine bessere Seite zu schreiben heißt für mich nicht, dass der Autor das Gefühl hat, sie sei besser, weil das Markup so furchtbar ästhetisch ist bzw. weil er alleine mit dem semantischen Code etwas anfangen kann und somit möglicherweise langfristig die Wartung und Skalierbarkeit vereinfacht wird, sondern der Benutzer die Verbesserungen als solche spürt. Und ich sehe trotz aller Anstrengung nicht, wie das bei abbr speziell im Vergleich zu acronym und Workarounds sein kann.

[at]

Hallo.

So interessant und intellektuell befriedigend die Suche nach der »korrekten« Auszeichnung auch sein mag, so wenig hilft es in der Regel dabei, tatsächlich bessere Webseiten zu schreiben.

» »» Das kann ich nicht nachvollziehen.

Wir haben hier doch ein wunderbar konkretes Beispiel. Mal angenommen, es wäre klar getrennt, für was abbr und für was acronym gebraucht werden soll und angenommen, dass auf Abkürzungen nicht pauschal verzichtet wird. Welche Vorteile für den Benutzer bringt es dann, eine Abkürzung als abbr auszuzeichnen, weil das »semantisch korrekt« ist?

Und das ist "in der Regel"? Demzufolge haben Buchstaben "in der Regel" einen Punkt obenauf, etwa das "i" und das "j", und das "ä", das "ö" und das "ü" sogar gleich zwei.
Deine Betrachtung kann ich nur so verstehen, dass du dein Niveau bereits auf das gesamte Forum abbildest und daher die Verwendung von etwa <h1> bis <h6>, das Bilden von syntaktisch unnötigen Blöcken in "HTML 4.01 Transitional"-Dokumenten im Allgemeinen, die Verwendung von Listen für Listen etc. ohnehin voraussetzt. Das dies nicht gilt, zeigt etwa [pref:t=67783&m=387993], ein Beitrag, auf den wir beide geantwortet haben und innerhalb dessen einmal mehr eine Seite mit semantisch zumindest fragwürdigem Markup behandelt wird, wie sie einem ja leider nicht eben selten über den Weg läuft.
Dass gerade wir, aber natürlich auch einige andere hier uns gern in Haarspaltereien verlieren, hat dann vielleicht doch mehr den Charakter einer Literaturkritik anhand von Sekundärliteratur, während "in der Regel" unter einem guten Buch ein Handvoll gebundener Seiten verstanden wird, die nicht beim ersten Durchblättern auseinanderfallen soll. Oder anders: Dich nervt Semantik auf (zu?) hohem Niveau. -- So weit jedenfalls meine Einschätzung, da ich nicht annehmen kann und will, dass du die Erkenntnisse dieses Forums und hinreichend vieler anderer Quellen zur Semantik von HTML-Dokumenten "in der Regel", also fast vollständig über Bord werfen willst.
MfG, at

[molily]

So interessant und intellektuell befriedigend die Suche nach der »korrekten« Auszeichnung auch sein mag, so wenig hilft es in der Regel dabei, tatsächlich bessere Webseiten zu schreiben.

Das kann ich nicht nachvollziehen.

Wir haben hier doch ein wunderbar konkretes Beispiel. Mal angenommen, es wäre klar getrennt, für was abbr und für was acronym gebraucht werden soll und angenommen, dass auf Abkürzungen nicht pauschal verzichtet wird. Welche Vorteile für den Benutzer bringt es dann, eine Abkürzung als abbr auszuzeichnen, weil das »semantisch korrekt« ist?

Und das ist "in der Regel"?

Das ist ein Beispiel für eine Semantikdebatte, deren Ergebnis keine realen Vorteile bringt. Das gilt nicht für alle Semantikdebatten, dafür soll es kein Beispiel sein, das ist wohl unklar herübergekommen.

Deine Betrachtung kann ich nur so verstehen, dass du dein Niveau bereits auf das gesamte Forum abbildest und daher die Verwendung von etwa <h1> bis <h6>, das Bilden von syntaktisch unnötigen Blöcken in "HTML 4.01 Transitional"-Dokumenten im Allgemeinen, die Verwendung von Listen für Listen etc. ohnehin voraussetzt.

Ich setze tatsächlich voraus, dass über eine bestimmte Art von semantischer Auszeichung nicht groß diskutiert werden muss. Die richtige Auszeichnung ist in diesen Fällen schnell konsensuell gefunden und sie ist zumeist praktikabel und mehr oder weniger evident. Es ist relativ einfach vermittelbar, warum Überschriften als solche ausgezeichnet werden sollten und welche Vorteile das bringt.

Über diese Trivialitäten streiten sich die Experten nicht fern jeder praktischen Relevanz. Daher halte ich solche Beschäftigung mit Semantik nur für fruchtbar und kritisiere sie keineswegs. Beispielsweise der Verzicht auf Gruppierungen ohne strukturelle Entsprechung, im Extrem div-Suppe genannt, ist schon schwerer zu vermitteln, weil es schlechter Stil ist, sich aber nicht direkt nachteilig auf den Besucher auswirkt. Dasselbe gilt für das Auszeichnen von abstrakten Listenstrukturen als Listen. Der Benutzer bekommt es nur indirekt mit bzw. es ist alles andere als evident, inwiefern er profitiert. Zumindest hat es in diesen Fällen keine negativen Auswirkungen, stimmiges Markup zu schreiben. Bei abbr/acronym hingegen erstickt die stimmige Auszeichnung die Kompatibilität im Keim.

Das dies nicht gilt, zeigt etwa [pref:t=67783&m=387993], ein Beitrag, auf den wir beide geantwortet haben und innerhalb dessen einmal mehr eine Seite mit semantisch zumindest fragwürdigem Markup behandelt wird, wie sie einem ja leider nicht eben selten über den Weg läuft.

Dieser Fall und ähnliche, in denen es um die Grundlagen geht, sind eindeutig. Durch <p class="headline">IMPRESSUM</p> usw. ist bereits eine Struktur angelegt, die praktischen Vorteile von hX-Elementen liegen sowohl für den Autor als auch für den Benutzer auf der Hand. In solchen Fällen muss erst einmal im Allgemeinen für den rationalisierten Einsatz von CSS geworben werden, das führt m.E. zwangsläufig zu straighter Auszeichnung der groben Textstrukturen, weil das Ausschöpfen der CSS-Möglichkeiten einen in sich logischen, »kohärenten« Elementbaum voraussetzt. Die gestalterische Vielfalt von CSS beeindruckt schon an sich.

Darüber finden keine hochgeistigen Diskussionen statt, diese einfachen, vergleichsweise »bodenständigen« Zusammenhänge drängen sich einem förmlich auf, wenn man sich ein wenig damit beschäftigt (das ist natürlich Voraussetzung).

Dass gerade wir, aber natürlich auch einige andere hier uns gern in Haarspaltereien verlieren, hat dann vielleicht doch mehr den Charakter einer Literaturkritik anhand von Sekundärliteratur, während "in der Regel" unter einem guten Buch ein Handvoll gebundener Seiten verstanden wird, die nicht beim ersten Durchblättern auseinanderfallen soll. Oder anders: Dich nervt Semantik auf (zu?) hohem Niveau.

Mich nervt sie nicht, ich finde sie durchaus theoretisch relevant, damit sich Semantik nicht in Pragmatismus verliert. Ich sehe nur nicht, wie diese Semantik auf zu hohem Niveau den Webautoren dort draußen(tm) beim Schreiben besserer Seiten im Hier und Jetzt hilft; und die Frage nach der konkreten Nützlichkeit kann sie auch nicht immer beantworten, daher wird sie von vielen nicht akzeptiert werden und wohl oder übel eine theoretische Betätigung bleiben.

Sicherlich hast du damit Recht, dass zunächst die genannten Grundlagen verbreitet werden müssen. Das wollte ich nicht in Abrede stellen.

So weit jedenfalls meine Einschätzung, da ich nicht annehmen kann und will, dass du die Erkenntnisse dieses Forums und hinreichend vieler anderer Quellen zur Semantik von HTML-Dokumenten "in der Regel", also fast vollständig über Bord werfen willst.

Das hatte ich nicht vor.

[at]

Hallo.

Das ist ein Beispiel für eine Semantikdebatte, deren Ergebnis keine realen Vorteile bringt. Das gilt nicht für alle Semantikdebatten, dafür soll es kein Beispiel sein, das ist wohl unklar herübergekommen.

Offenbar, ja.

Ich setze tatsächlich voraus, dass über eine bestimmte Art von semantischer Auszeichung nicht groß diskutiert werden muss.

[...]

Über diese Trivialitäten streiten sich die Experten nicht fern jeder praktischen Relevanz. Daher halte ich solche Beschäftigung mit Semantik nur für fruchtbar und kritisiere sie keineswegs.

[...]

Darüber finden keine hochgeistigen Diskussionen statt, diese einfachen, vergleichsweise »bodenständigen« Zusammenhänge drängen sich einem förmlich auf, wenn man sich ein wenig damit beschäftigt (das ist natürlich Voraussetzung).

[...]

Mich nervt sie nicht, ich finde sie durchaus theoretisch relevant, damit sich Semantik nicht in Pragmatismus verliert.

[...]

Sicherlich hast du damit Recht, dass zunächst die genannten Grundlagen verbreitet werden müssen. Das wollte ich nicht in Abrede stellen.

Wenn ich gewusst hätte, dass du dich auf die "hochgeistigen Diskussionen" beziehst, würde ich dir längst zugestimmt haben, aber ich war eben von der Mehrzahl der Diskussionen -- oder besser lehrreicher Erläuterungen mit kritischen Rückfragen -- ausgegangen, die hier zu diesem Thema geführt werden.
Von meiner Seite aus wäre damit diesbezüglich eigentlich alles geklärt, so dass ich den Thread mit deiner Erlaubnis dankend abschlösse.
MfG, at

[Tim Tepaße]

Hallo at,

Wer <acronym> statt <abbr> nutzt,(..)

In XHTML 2 wird es wahrscheinlich nur noch <abbr> geben; Akronyme bilden
dann eine Untermenge davon.

Tim

[at]

Hallo.

In XHTML 2 wird es wahrscheinlich nur noch <abbr> geben; Akronyme bilden
dann eine Untermenge davon.

Eben, und nicht umgekehrt.
MfG, at

[emu]

Hallo!

[Zitate]
Ich bin auf der suche nach dem richtigem HTML Tag für die Auszeichnung.

Der Weisheit letzter Schluss ist hier noch nicht gefunden, auch, weil das Konsortium sich in der Vergangenheit auf zumindest leicht missverstänliche Formulierungen eingelassen hat.

Ich verwende folgende Konstruktion:

<blockquote>
 <p>
  <q>Ein Autobauer, der sagt, dass er keine Probleme hat, hat ein Problem.</q>
  <cite>Renault-Chef Louis Schweitzer</cite>
 </p>
</blockquote>

(cite mit display:block)

emu