Anfängerfrage: strong/em oder span?

[dbenzhuser]

Gegrüßed sollt ihr sein!

Thema ist mal wieder die Umstellung einer Seite auf CSS.

Wie ist es nun besser/empfehlenswerter?
Lieber komplett auf Textauszeichnung mit HTML verzichten, also anstatt <strong> <span style="font-weight:bold"> (oder mit Klassen) verwenden?

Wenn ich <strong> oder ähnliche Elemente benutze, diese dann in der externen CSS-Datei nochmal beschreiben:
strong {font-weight:bold;}
em {font-style:italic;}
auch wenn sich sonst nix ändert (also keine andere Farbe etc.)?

Wenn ich nun kursiv UND fett haben will, dann immer noch mit
<strong><em>bla</em></strong>, oder lohnt sich dann eher ein <span> mit den entsprechenden Eigenschaften?

Wenn ich verschiedene "hervorgehobene" Textpassagen haben will (einmal fett+rot, das andere mal fett+grün), führe ich dann fürs <strong> entsprechende Klassen ein (soll ja beides betont sein) oder ist das nun ein Einsatzzweck für <span>?

Könnte man sicher länger fortsetzen, generell ist einfach die Frage: Wann immer möglich/sinnvoll logische Textauszeichnung verwenden, oder auf nichtssagende span's ausweichen?
Oder: Gehört logische Textauszeichnung zur Gestaltung (das sind ja die direkten Auswirkungen) oder zum Content (ob betont oder nicht ist ja irgentwie zusätzlicher Inhalt)?

Werden strong und Konsorten in zukünftig auf der Abschussliste des W3C stehen wie <b> etc. oder eher nicht?

btw: Man soll ja in z.B. in XHTML alle Elemente und Attribute klein schreiben, gilt das auch für Farbangaben? Also #00ffcc anstatt #00FFCC?

Hoffe einer erbarmt sich meiner ;)
dbenzhuser

[Sven Rautenberg]

Moin!

Lieber komplett auf Textauszeichnung mit HTML verzichten, also anstatt <strong> <span style="font-weight:bold"> (oder mit Klassen) verwenden?

Vermeide <span>, wo immer es geht, und setze stattdessen logische HTML-Tags ein. Die darfst du, sofern du unterschiedliche Arten der Hervorhebung benötigst, auch gerne mit Klassen versehen, um sie in Browsern mit farbiger Darstellungsmöglichkeit hervorzuheben (andere Browser heben sie dann eben einheitlich hervor, erkennen aber immer noch die Hervorhebung).

Wenn ich <strong> oder ähnliche Elemente benutze, diese dann in der externen CSS-Datei nochmal beschreiben:
strong {font-weight:bold;}
em {font-style:italic;}
auch wenn sich sonst nix ändert (also keine andere Farbe etc.)?

Diese Formatierung ist die Standardeinstellung im Browser. Du mußt sie nicht wiederholen. Schreibe in die CSS-Datei das rein, was sich im Vergleich zum Standard _ändern_ soll.

Wenn ich nun kursiv UND fett haben will, dann immer noch mit
<strong><em>bla</em></strong>, oder lohnt sich dann eher ein <span> mit den entsprechenden Eigenschaften?

Ein <span> lohnt sich nie, wenn es um Textauszeichnung geht. Es ist nichtssagend.

Andererseits: <strong><em> als Kombination ist auch nicht wirklich gelungen. Die doppelte Auszeichnung als Hinweis auf "sehr sehr sehr wichtig" (im Vergleich zu <em>="sehr wichtig" und <strong>="sehr sehr wichtig") ist in meinen Augen nicht wirklich hilfreich. Verzichte auf die Dopplung, nimm ein einfaches <strong>, gib zusätzlich auch noch eine Klasse an und mach die Formatierung kursiv.

Wenn ich verschiedene "hervorgehobene" Textpassagen haben will (einmal fett+rot, das andere mal fett+grün), führe ich dann fürs <strong> entsprechende Klassen ein (soll ja beides betont sein) oder ist das nun ein Einsatzzweck für <span>?

Nein, kein <span>, nur Klassen.

Könnte man sicher länger fortsetzen, generell ist einfach die Frage: Wann immer möglich/sinnvoll logische Textauszeichnung verwenden, oder auf nichtssagende span's ausweichen?

<span> vermeiden, wo immer es geht. Die anderen HTML-Tags haben eine sinnmäßige Bedeutung, die bei <span> fehlt.

Überlege dir eines: Wenn eine Suchmaschine deine Seite auseinandernimmt, woran erkennt sie, was auf der Seite wichtig ist? An den HTML-Tags. Eine Überschrift <h1> könnte von der Suchmaschine als wichtiger bewertet werden, als ein Fließtext <p>. Vielleicht haben auch <strong> und <em> eine Bedeutung.

Was aber ist mit <span>? Das dient ausschließlich zur Formatierung mit CSS. Damit kann man Text sehr wichtig aussehen lassen, oder sehr unwichtig. Die Suchmaschine kann aber kein CSS, also wird sie den Sinn, den die Formatierung für den Menschen machen soll, nicht erkennen können, und <span> ignorieren. Ist immerhin auch nicht schlecht, aber es geht eben besser.

Oder: Gehört logische Textauszeichnung zur Gestaltung (das sind ja die direkten Auswirkungen) oder zum Content (ob betont oder nicht ist ja irgentwie zusätzlicher Inhalt)?

Das ist eine Ansichtssache. Ich würde es in die dritte Kategorie "Meta-Informationen" rücken.

Werden strong und Konsorten in zukünftig auf der Abschussliste des W3C stehen wie <b> etc. oder eher nicht?

Niemals. Das W3C befürwortet das "semantische Web", <strong> etc. sind unverzichtbar für sowas. Außerdem steht <b> und <i> nicht auf der Abschußliste. Wahrscheinlich ist es nicht verkehrt, wenn man künftig diese beiden Tags als äquivalent zu <strong> und <em> behandelt, ihnen also eine zusätzliche semantische Bedeutung gibt.

btw: Man soll ja in z.B. in XHTML alle Elemente und Attribute klein schreiben, gilt das auch für Farbangaben? Also #00ffcc anstatt #00FFCC?

Die Attribut_namen_ müssen klein geschrieben werden. Die Attribut_werte_ sind durch XHTML nicht vorgeschrieben.

- Sven Rautenberg

[Thiemo Mättig]

Gehört logische Textauszeichnung zur Gestaltung (das sind ja die direkten Auswirkungen) oder zum Content (ob betont oder nicht ist ja irgentwie zusätzlicher Inhalt)?

Betrachte das Ganze in DREI Ebenen: Inhalt, Layout und Design. Inhalt: Der Text, also z.B. "das ist wichtig". Layout: Inhaltliche/logische Struktur des Textes, also z.B. "<strong>das</strong> ist wichtig". Design: Optische Darstellung, also z.B. "strong{color:red;}".

Außerdem steht <b> und <i> nicht auf der Abschußliste.

Das stimmt nicht. <b> und <i> wird es in XHTML 2.0 nicht mehr geben. Verwende nur noch <strong> und <em>.

Wahrscheinlich ist es nicht verkehrt, wenn man künftig diese beiden Tags als äquivalent zu <strong> und <em> behandelt, ihnen also eine zusätzliche semantische Bedeutung gibt.

Das geht natürlich. Ein globales Suchen und Ersetzen ist ja kein Problem, sobald das notwendig werden sollte.

[Michael Jendryschik]

Hallo,

Betrachte das Ganze in DREI Ebenen: Inhalt, Layout und Design. Inhalt: Der Text, also z.B. "das ist wichtig". Layout: Inhaltliche/logische Struktur des Textes, also z.B. "<strong>das</strong> ist wichtig". Design: Optische Darstellung, also z.B. "strong{color:red;}".

Du bezeichnest die inhaltliche/logische Struktur des Textes als »Layout«? Das halte ich für gewagt. Deine Dreiteilung ist natürlich richtig. Man geht von folgenden drei Bestandteilen eines Dokuments aus:

* Inhalt
  Text, Bilder usw.

* Struktur
  Aufteilung in Kapitel und Abschnitte, semantische Informationen
  über einzelne Wörter oder Satzteile (u.a. HTML, XHML, XML)

* Informationen zur (visuellen) Darstellung
  Layout, Schriftart und -größe, Farben, Rahmen, Abstände uvm.
  (u.a. CSS, JSSS)

Gruß,

MI

[wahsaga]

hi,

Wenn ich <strong> oder ähnliche Elemente benutze, diese dann in der externen CSS-Datei nochmal beschreiben:
strong {font-weight:bold;}
em {font-style:italic;}
auch wenn sich sonst nix ändert (also keine andere Farbe etc.)?
Diese Formatierung ist die Standardeinstellung im Browser. Du mußt sie nicht wiederholen. Schreibe in die CSS-Datei das rein, was sich im Vergleich zum Standard _ändern_ soll.

es mag standardeinstellung in _deinem_ browser sein - ich glaube jedoch nicht, dass man darauf auf alle browser schliessen sollte (oder ist im standard irgendwo vorgeschrieben, dass im normalfall <strong> mit fetter schrift formatiert werden soll?).
wenn du <strong> in jedem browser mit roter, fetter schrift angezeigt bekommen willst, dann würde ich sowohl die farbe rot als auch das schriftgewicht fett explizit angeben.

gruss,
wahsaga

[Thiemo Mättig]

ist im standard irgendwo vorgeschrieben, dass im normalfall <strong> mit fetter schrift formatiert werden soll?

Ja, siehe http://www.w3.org/TR/html4/struct/text.html#edef-STRONG. Es gibt eine Empfehlung, die besagt, dass <strong> in der Regel fett dargestellt wird. Es kann allerdings nie schaden, trotzdem font-weight:bold anzugeben. Sicher ist sicher. ;-)

[Michael Jendryschik]

Hallo,

ist im standard irgendwo vorgeschrieben, dass im normalfall <strong> mit fetter schrift formatiert werden soll?
Ja, siehe http://www.w3.org/TR/html4/struct/text.html#edef-STRONG. Es gibt eine Empfehlung, die besagt, dass <strong> in der Regel fett dargestellt wird.

Dein Englisch scheint nicht das beste zu sein. In diesem Absatz wird keine Empfehlung ausgesprochen, sondern lediglich angemerkt, wie die Darstellung dieser beiden Elemente im Allgemeinen aussieht bzw. wie Sprachsynthesizer sie umsetzen könnten.

Gruß,

MI

[Sven Rautenberg]

Moin!

es mag standardeinstellung in _deinem_ browser sein - ich glaube jedoch nicht, dass man darauf auf alle browser schliessen sollte (oder ist im standard irgendwo vorgeschrieben, dass im normalfall <strong> mit fetter schrift formatiert werden soll?).

Es gibt ein vom W3C empfohlenes Standard-Stylesheet für alle Tags.

Wenn man deinem Ansatz nachgehen würde, müßte jedes Tag immer eine komplette Formatierungsanweisung aller möglichen CSS-Eigenschaften erhalten, damit man sichergehen kann, dass die Darstellung in jedem Browser so ist, wie vom Autoren gewünscht (sofern nicht noch User-Stylesheets mit !important dazwischenfunken...).

wenn du <strong> in jedem browser mit roter, fetter schrift angezeigt bekommen willst, dann würde ich sowohl die farbe rot als auch das schriftgewicht fett explizit angeben.

Und ich würde nur rot angeben, die Fettschreibung aber als Standard voraussetzen.

Denn was ist, wenn in dem jeweiligen "abartigen" Browserstylesheet ein <strong> unerwarteterweise nicht fett, sondern kursiv dargestellt wird? Du kriegst durch die Fett- und Rotmachung deines Stylesheets dann fette, rote und _kursive_ Schrift für <strong>. Das ist sicher nicht das, was du wolltest. Also mußt du, um sicherzugehen, auch die Eigenschaft font-style, und um ganz sicher zu sein, auch font-variant, font-stretch, word-spacing, letter-spacing, text-decoration, text-transform, text-shadow, border, margin, background-color, padding, etc. setzen...

Auf gewisse Dinge muß man sich eben verlassen. Das erleichtert die Arbeit. Denn man kann in der Regel davon ausgehen, dass <strong> vom Browser fett dargestellt wird, sofern der Browser das kann. Wenn der Benutzer die Darstellung verändert hat, wird man durch die eigenen Stylesheets auf dieser Darstellung _aufsetzen_ und muß annehmen, dass der Benutzer sich sein <strong> schon irgendwie sinnvoll formatiert hat. Er wird dabei nämlich davon ausgehen, dass Webseitenersteller davon ausgehen, dass <strong> fett ist... :)

- Sven Rautenberg

[Michael Jendryschik]

Hallo,

Niemals. Das W3C befürwortet das "semantische Web", <strong> etc. sind unverzichtbar für sowas. Außerdem steht <b> und <i> nicht auf der Abschußliste.

Leider.

Wahrscheinlich ist es nicht verkehrt, wenn man künftig diese beiden Tags als äquivalent zu <strong> und <em> behandelt, ihnen also eine zusätzliche semantische Bedeutung gibt.

Wie stellst du dir das vor? Wie soll man Elementen, die für die fette bzw. kursive *Darstellung* von Inhalten sorgen, eine semantische Bedeutung zuordnen können?

Gruß,

MI

[molily]

Hallo,

Wahrscheinlich ist es nicht verkehrt, wenn man künftig diese beiden Tags als äquivalent zu <strong> und <em> behandelt, ihnen also eine zusätzliche semantische Bedeutung gibt.

Wie stellst du dir das vor? Wie soll man Elementen, die für die fette bzw. kursive *Darstellung* von Inhalten sorgen, eine semantische Bedeutung zuordnen können?

Natürlich nicht, aber welche Elemente soll man sonst benutzen? Schaut man sich beispielsweise einen beliebigen Zeitungsartikel an, wird kursive Formatierung oft benutzt, ohne dass eine Hervorhebung im Hinblick auf Emphase und Wichtigkeit vorliegt. Das betrifft unter anderem

• fremdsprachliche Wörter/Wendungen,
• Eigennamen/Bezeichnungen/Titel und
• Wörter/Wendungen, die als Zeichen selbst gemeint sind.

Nehmen wir http://www.zeit.de/2003/40/Gouverneurs-Wahlen als Beispiel. Zeit.de benutzt für kursiven Text im Fließtext immer das em-Element:

Ist es nun aus und vorbei mit dem <em>California Dreamin'</em>?
»... Das ist Teil unserer Existenz. Tod und Wiedergeburt. Goldrausch und Geisterstadt. <em>Boom and bust.</em> ...«
»<em>Have fun!</em>«, sagt er zum Abschied.
Vor der Wohnanlage des Kriegsfilmers Jerry Bruckheimer (<em>Pearl Harbor</em>) kommt Riordan auf die bösen Geister der kalifornischen Politik zu sprechen.
»Ein totales Desaster, ticken alle links, besonders die <em>Los Angeles Times</em>.«
Wie ein Schwarzenegger-Denkmal stehen am »<em>muscle beach</em>« von Santa Monica all die Barren und Turnstangen herum, an denen der Narziss sich vor aller Augen perfektionieren kann.
Denn jedes Mal, wenn er es tut -- zuletzt in der Fernsehshow bei <em>Larry King live</em> --, kommt er an.
In seinem Film <em>Conan, der Barbar</em> brachte es Schwarzenegger mit 75 Worten zu Weltruhm.

Meiner Meinung nach ist em in keinem der obigen Fälle gerechtfertigt, weil keine Emphase vorliegt, mir fallen auch keine besseren Elemente ein. Mit class kann man nicht jede unpassende Elementverwendung nachträglich zurechtbiegen. Dann bliebe man auf i oder span sitzen, was aber ignorieren würde, dass die Kursivierung nicht von ungefähr kommt und durchaus den Text mit Bedeutung füllt. Es begegnen einem ständig Fälle begegnet, in denen Text kursiv hervorgehoben ist, ohne eine Emphase zu verdeutlichen und ohne dass ein spezielleres Element existiert.

Mathias

[Michael Jendryschik]

Hallo,

Wahrscheinlich ist es nicht verkehrt, wenn man künftig diese beiden Tags als äquivalent zu <strong> und <em> behandelt, ihnen also eine zusätzliche semantische Bedeutung gibt.

Wie stellst du dir das vor? Wie soll man Elementen, die für die fette bzw. kursive *Darstellung* von Inhalten sorgen, eine semantische Bedeutung zuordnen können?

Natürlich nicht, aber welche Elemente soll man sonst benutzen?

Geeignete Elemente, die den Text semantisch auszeichnen, oder 'span' mit entsprechenden Bezeichern und Formatierungen.

Es begegnen einem ständig Fälle begegnet, in denen Text kursiv hervorgehoben ist, ohne eine Emphase zu verdeutlichen und ohne dass ein spezielleres Element existiert.

Das Element 'i' hilft dir da sicher nicht weiter.

Gruß,

MI

[at]

Hallo.

Natürlich nicht, aber welche Elemente soll man sonst benutzen? Schaut man sich beispielsweise einen beliebigen Zeitungsartikel an, wird kursive Formatierung oft benutzt, ohne dass eine Hervorhebung im Hinblick auf Emphase und Wichtigkeit vorliegt. Das betrifft unter anderem

• fremdsprachliche Wörter/Wendungen,
• Eigennamen/Bezeichnungen/Titel und
• Wörter/Wendungen, die als Zeichen selbst gemeint sind.
  Meiner Meinung nach ist em in keinem der obigen Fälle gerechtfertigt, weil keine Emphase vorliegt, mir fallen auch keine besseren Elemente ein. Mit class kann man nicht jede unpassende Elementverwendung nachträglich zurechtbiegen. Dann bliebe man auf i oder span sitzen, was aber ignorieren würde, dass die Kursivierung nicht von ungefähr kommt und durchaus den Text mit Bedeutung füllt. Es begegnen einem ständig Fälle begegnet, in denen Text kursiv hervorgehoben ist, ohne eine Emphase zu verdeutlichen und ohne dass ein spezielleres Element existiert.

Wenn du <cite>, <q> (beide ein imaginäres "ich zitiere:") und gegebenfalls auch <sample> ("z. B.") und <dfn> ("der/die/das sogenannte") richtig einsetzt, kommst du der Sache bereits einen Schritt näher. Noch mehr Semantik erlangst du aber leider wohl nur mit einer eigenen DTD.
MfG, at

[Tim Tepaße]

Hallo at,

Wenn du <cite>, <q> (beide ein imaginäres "ich zitiere:") ..

Bei <cite> stimmt das nicht ganz. Dieses ist eher so gedacht:

Wie schon <cite>Deepthought</cite> sagte: <q>42</q>.

Also zur Angabe der Quelle eines Zitates. Zugegeben, das ganze ist etwas
verworren; ich meine mich zu erinnern, daß es bei XHTML 2 Überlegungen
gab, auf dieses Element zu verzichten.

Tim

[at]

Hallo.

Bei <cite> stimmt das nicht ganz. Dieses ist eher so gedacht:

Wie schon <cite>Deepthought</cite> sagte: <q>42</q>.

Also zur Angabe der Quelle eines Zitates. Zugegeben, das ganze ist etwas
verworren; ich meine mich zu erinnern, daß es bei XHTML 2 Überlegungen
gab, auf dieses Element zu verzichten.

Ich war so naiv, auf http://selfhtml.teamone.de/html/text/logisch.htm zu vertrauen, wo es zu <cite> heißt: "zeichnet einen Text aus mit der Bedeutung 'dies ist ein Zitat von einer anderen Quelle'". Aber vielleicht hatte sich der Autor ja auch nur auf http://www.w3.org/TR/html401/struct/text.html#edef-CITE verlassen, wo es heißt: "CITE: Contains a citation or a reference to other sources.". Wenn es also so gedacht war wie du meinst, solltest du vielleicht eine kurze Mail an das W3C verfassen ;-)
MfG, at

[Tim Tepaße]

Hallo at,

Aber vielleicht hatte sich der Autor ja auch nur auf
http://www.w3.org/TR/html401/struct/text.html#edef-CITE verlassen,
wo es heißt: "CITE: Contains a citation or a reference to other sources.".

Scroll mal etwas runter, dort findet man einige Anwendungsbeispiele für
cite, die eben nur die Referenzen, sprich die Zitatquelle, enthalten.
Auch daß cite nicht in einem eigenen Abschnitt wie die anderen Zitatelemente,
nämlich blockquote und q aufgeführt werden, bestärkt mich darin.

Wenn es also so gedacht war wie du meinst, solltest du vielleicht eine kurze
Mail an das W3C verfassen ;-)

Sie könnten das klarer ausdrücke, ja. ;-)

Tim

[at]

Hallo.

Scroll mal etwas runter, dort findet man einige Anwendungsbeispiele für
cite, die eben nur die Referenzen, sprich die Zitatquelle, enthalten.

Beispiele über die Definition zu stellen, halte ich nicht für sinnvoll.

Auch daß cite nicht in einem eigenen Abschnitt wie die anderen Zitatelemente,
nämlich blockquote und q aufgeführt werden, bestärkt mich darin.

Nun, dafür gibt es ja <blockqute> und <q>. Mit der gleichen Berechtigung könntest du dies aber bei <em> und <strong> fragen. Weshalb sollte man wörtliche Rede nur in einem Absatz wiedergeben dürfen?

Sie könnten das klarer ausdrücke, ja. ;-)

Ich hoffe, du hast die Mail bereits verfasst ;-)
MfG, at

[Michael Jendryschik]

Hallo,

Auch daß cite nicht in einem eigenen Abschnitt wie die anderen Zitatelemente,
nämlich blockquote und q aufgeführt werden, bestärkt mich darin.

Nun, dafür gibt es ja <blockqute> und <q>. Mit der gleichen Berechtigung könntest du dies aber bei <em> und <strong> fragen. Weshalb sollte man wörtliche Rede nur in einem Absatz wiedergeben dürfen?

Was meinst du damit? 'q' benötigt und bildet keinen eigenen Absatz.

Gruß,

MI

[at]

Hallo.

Auch daß cite nicht in einem eigenen Abschnitt wie die anderen Zitatelemente,
nämlich blockquote und q aufgeführt werden, bestärkt mich darin.

Nun, dafür gibt es ja <blockqute> und <q>. Mit der gleichen Berechtigung könntest du dies aber bei <em> und <strong> fragen. Weshalb sollte man wörtliche Rede nur in einem Absatz wiedergeben dürfen?

Was meinst du damit? 'q' benötigt und bildet keinen eigenen Absatz.

Nein, natürlich nicht. Dafür gibt es ja <blockquote>. Ich hatte den Absatz, auf den ich geantwortet hatte auch völlig falsch verstanden wie ich gerade feststelle.
MfG, at

[Tim Tepaße]

Hallo at,

Beispiele über die Definition zu stellen, halte ich nicht für sinnvoll.

Ich würde sagen, die Beispiele sind Bestandteil der Definition.

Nun, dafür gibt es ja <blockqute> und <q>. Mit der gleichen Berechtigung
könntest du dies aber bei <em> und <strong> fragen. Weshalb sollte man
wörtliche Rede nur in einem Absatz wiedergeben dürfen?

Äh ja. Das Du diesen meinen Satz falsch verstanden hast, hast Du ja selbst
gesagt. Ich sollte etwas an meinem Ausdrucksvermögen arbeiten.

Ich glaube, der wesentliche Unterschied zwischen cite auf der einen Seite und
blockquote und q(uote) auf der anderen Seite besteht darin, daß diese zwei
verschiedene Arten von Zitaten meinen. Es gibt zum einen die direkte
Wiedergabe des Textes des Zitats, also ein Textfragment. Für dieses würde
ich dann q und blockquote, evtl. mit dem Attribut cite verwenden. Dann
gibt es aber noch die andere Zitierungen. Beispielsweise im Passiv.
Beispielsweise inhaltlich zusammenfassend, was der Autor meint. Und
für die Referenz ist dann cite zu verwenden. Aber ich gebe gerne zu, daß das
etwas Spekulierend ist, wenn man dieses unglückliche »citation« im von Dir
zitiertem Standard berücksichtigt.

Nebenbei:
In einer Hypertextwelt ist das ganz noch absurder, letztendlich setzt
man dann (beispielsweise in Weblogs, das berühmte »via«) öfters
<cite><a href="..">..</a></cite>-Kombinationen ein. Weswegen dann
gerade cite nicht mit einem href-Attribut ausgestattet ist, ist mir
schleierhaft.

Ich hoffe, du hast die Mail bereits verfasst ;-)

Och, wenn ich Zeit habe, recherchiere ich erstmal in den Archiven der
öffentlichen Mailingliste. Ich bin mir sicher, da steht noch mehr.

Tim

[Michael Jendryschik]

Hallo,

Beispiele über die Definition zu stellen, halte ich nicht für sinnvoll.

Ich würde sagen, die Beispiele sind Bestandteil der Definition.

Beispiele sind sogar das wichtigste an Spezifikationen! Bert Bos schreibt in http://www.w3.org/People/Bos/DesignGuide/designguide.html sehr schön:

»In fact, removing explanations can be a good thing for another reason as well: the more explanations, the higher the chance that they contradict each other. It is better to put explanations and annotations in a separate, non-normative document, or maybe in a book.

But do not remove examples. A well-chosen example can often replace several paragraphs of explanation. And moreover they can be used as a rough test case for new implementations.

Programmers typically like to find out how things work while programming, rather than while reading English. It is a paradox: giving less explanation makes them understand better. I guess programmers like puzzles...«

:-)

Gruß,

MI

[at]

Hallo.

Beispiele sind sogar das wichtigste an Spezifikationen!

Die Schwierigkeiten, die sich daraus ergeben, sind aber auch nicht zu unterschätzen: Von einem der angegebenen Beispiele auf den eigenen konkreten Anwendungsfall zu schließen, ist oftmals nicht möglich, und Aufzählungen sehr unterschiedlicher Dinge, die mit "etc." schließen, sind alles andere als hilfreich, wenn es um ein Ja oder Nein geht.
Sprache ist zu komplex, um sie in all ihrer Sinnhaftigkeit in einige wenige Definitionen zu pressen. Die Standards des WWW -- und hier beziehe ich die zukünftigen mit ein, obwohl ich sie ja noch gar nicht kenne -- begreife ich lediglich als Übersetzung einer Teilmenge dessen, was Sprache ausmacht und wie wir sie verwenden.
MfG, at

[Michael Jendryschik]

Hallo,

Ich war so naiv, auf http://selfhtml.teamone.de/html/text/logisch.htm zu vertrauen, wo es zu <cite> heißt: "zeichnet einen Text aus mit der Bedeutung 'dies ist ein Zitat von einer anderen Quelle'".

Das Beispiel auf http://jendryschik.de/wsdev/einfuehrung/xhtml/bodyelemente.html#q erläutert die Anwendung der Elemente 'q', 'blockquote' und 'cite' sowie des Attributs 'cite' meiner Ansicht nach sehr gut.

Aber vielleicht hatte sich der Autor ja auch nur auf http://www.w3.org/TR/html401/struct/text.html#edef-CITE verlassen, wo es heißt: "CITE: Contains a citation or a reference to other sources.".

Im XHTML 2.0 WD unter http://www.w3.org/TR/xhtml2/mod-inline-text.html#sec_9.2. heißt es weiterhin: »The 'cite' element contains a citation or a reference to other sources.« -- Sehr unglücklich, meiner Ansicht nach.

Wenn es also so gedacht war wie du meinst, solltest du vielleicht eine kurze Mail an das W3C verfassen ;-)

Wer oder was hindert dich daran? [e-mail] ist eine öffentliche Mailingliste. Anregungen werden dort diskutiert und in den Entwicklungsprozess von Spezifikationen mit einbezogen.

Gruß,

MI

[at]

Hallo.

Das Beispiel auf http://jendryschik.de/wsdev/einfuehrung/xhtml/bodyelemente.html#q erläutert die Anwendung der Elemente 'q', 'blockquote' und 'cite' sowie des Attributs 'cite' meiner Ansicht nach sehr gut.

Meiner Ansicht nach auch, vielen Dank :-)

Im XHTML 2.0 WD unter http://www.w3.org/TR/xhtml2/mod-inline-text.html#sec_9.2. heißt es weiterhin: »The 'cite' element contains a citation or a reference to other sources.« -- Sehr unglücklich, meiner Ansicht nach.

Das von dir gefundene Zitat entspricht dem von mir herangezogenen inhaltlich vollständig. Mein Problem ist, dass ich mich ja zumindest auf die Formulierungen des W3C verlassen muss, da diese Organisation normbildend und damit maßgeblich ist. -- Auch hier teile ich deine Ansicht.

Wer oder was hindert dich daran? [e-mail] ist eine öffentliche Mailingliste. Anregungen werden dort diskutiert und in den Entwicklungsprozess von Spezifikationen mit einbezogen.

Das glaube ich gern, aber der Enwicklungsprozess interessiert mich ehrlich gesagt kaum. Meine Schwierigkeiten liegen im Hier und Jetzt. Die zukünftigen Spezifikationen schreibe ich mir dann in Form eigener DTDs selbst, da schlicht nicht davon auszugehen ist, dass das W3C auf jeden Einzelfall eingehen kann, ohne sich hoffnungslos zu verzetteln. Die Verwendung eigener DTDs birgt zwar andere Gefahren, aber auch die werden sich ausräumen lassen.
MfG, at

[molily]

Hallo at,

Meiner Meinung nach ist em in keinem der obigen Fälle gerechtfertigt, weil keine Emphase vorliegt, mir fallen auch keine besseren Elemente ein. Mit class kann man nicht jede unpassende Elementverwendung nachträglich zurechtbiegen. Dann bliebe man auf i oder span sitzen, was aber ignorieren würde, dass die Kursivierung nicht von ungefähr kommt und durchaus den Text mit Bedeutung füllt. Es begegnen einem ständig Fälle begegnet, in denen Text kursiv hervorgehoben ist, ohne eine Emphase zu verdeutlichen und ohne dass ein spezielleres Element existiert.

Wenn du <cite>, <q> (beide ein imaginäres "ich zitiere:")

Bei den genannten kursiven Titeln wird nichts zitiert, es ist auch keine Quellenreferenz im inhaltlichen Sinne (Wiedergabe/Übernahme von Inhalten, ergänzende/weiterführende Lektüre, Abhängigkeit/direkte Bezugnahme, ...). Alleine den Namen einer Zeitung, eines Filmes, einer Fernsehshow usw. bei jeder Nennung unabhängig vom Kontext als Quellenreferenz zu bezeichnen, halte ich für weit hergeholt. In manchen Kontexten passt es natürlich, beispielsweise bei: »Wie das Nachrichtenmagazin <cite>Der Spiegel</cite> in seiner gestrigen Ausgabe berichtete, ...« Aber in einem simplen Satz wie »Die tageszeitung wurde kürzlich 25 Jahre alt« würde ich nicht <cite>tageszeitung</cite> schreiben, nur weil eine allgemeine inhaltliche Bezugnahme vorliegt.

und gegebenfalls auch <sample> ("z. B.")

Das samp-Element »designates sample output from programs, scripts, etc.« Das passt in der Regel nicht, insbesondere nicht, wenn ein normalsprachliches Beispiel gegeben wird.

und <dfn> ("der/die/das sogenannte")

Das passt auch nicht, das dfn-Element »indicates that this is the defining instance of the enclosed term.« Dieser Fall liegt in keinem der Beispiele vor. Bei den gerechtfertigten Anwendungen stellte sich die Frage, wie die Folgevorkommen ausgezeichnet werden, welche ebenfalls kursiv dargestellt werden sollen.

richtig einsetzt, kommst du der Sache bereits einen Schritt näher.

Das denke ich nicht. Darüber habe ich mir schon Gedanken gemacht, ich bleibe weiterhin bei der Meinung, dass es für keines der genannten Beispiele ein hinreichend stimmiges Elements gibt. <span class="..."> lässt grüßen...

Mathias

[Tim Tepaße]

Hallo Mathias,

Das denke ich nicht. Darüber habe ich mir schon Gedanken gemacht, ich bleibe
weiterhin bei der Meinung, dass es für keines der genannten Beispiele ein
hinreichend stimmiges Elements gibt. <span class="..."> lässt grüßen...

Wobei meiner Meinung nach bei einigen Deiner der Zeit entnommenen Beispiele
durchaus nur <span lang="en"> angemessen ist. Nur ein bisken semantischer
Mehrwert, aber es genügt ja.

Tim

[at]

Hallo.

Wobei meiner Meinung nach bei einigen Deiner der Zeit entnommenen Beispiele
durchaus nur <span lang="en"> angemessen ist. Nur ein bisken semantischer
Mehrwert, aber es genügt ja.

Ein guter Gedanke. Werde ich sofort notieren :-)
MfG, at

[molily]

Hallo, Tim,

Das denke ich nicht. Darüber habe ich mir schon Gedanken gemacht, ich bleibe weiterhin bei der Meinung, dass es für keines der genannten Beispiele ein hinreichend stimmiges Elements gibt. <span class="..."> lässt grüßen...

Wobei meiner Meinung nach bei einigen Deiner der Zeit entnommenen Beispiele durchaus nur <span lang="en"> angemessen ist. Nur ein bisken semantischer Mehrwert, aber es genügt ja.

Ja, das hatte ich mir auch gedacht. Das beruhigt das Semantik-Gewissen, genügt aber nicht in Hinblick auf die Visualisierung. Da [lang=en] oder gar :lang(en) nicht hinreichend unterstützt wird, lässt sich aus dem Markup keine Formatierungsregel ableiten. Außerdem sollen nicht alle englischsprachigen Wörter, dazu zählen auch Namen, kursiv formatiert sein. Strenggenommen sind »Jerry Bruckheimer« und »Santa Monica« aus den Beispielen englisch und müssten konsequenterweise entsprechend ausgezeichnet werden. Es gibt auch englische Lehnwörter, die im Deutschen ohne besondere Kennzeichnung eingesetzt werden, aber trotzdem ein <span lang="en"> verdienten. Um eine Klasse kommt man also nicht herum. Aber ich verstehe, was du meintest, damit hast du natürlich recht.

Mathias

[at]

Hallo.

Ja, das hatte ich mir auch gedacht. Das beruhigt das Semantik-Gewissen, genügt aber nicht in Hinblick auf die Visualisierung. Da [lang=en] oder gar :lang(en) nicht hinreichend unterstützt wird, lässt sich aus dem Markup keine Formatierungsregel ableiten.

Das ist eine Frage der CSS-Unterstützung. Der _Semantik_ ist damit definitiv genüge getan.

Außerdem sollen nicht alle englischsprachigen Wörter, dazu zählen auch Namen, kursiv formatiert sein. Strenggenommen sind »Jerry Bruckheimer« und »Santa Monica« aus den Beispielen englisch und müssten konsequenterweise entsprechend ausgezeichnet werden.

Wenn du so konsequent bist, solltest du jedes Wort mit einem Hyperlink versehen, da es zu allem ja weitere Informationen gibt. Dass du dies -- hoffentlich -- nicht machst, zeigt wer die Grenzen der Semantik zieht: der Autor, der eben nicht das Mögliche oder Vollständige erzeugen will, sondern eine Information zum Leser transportieren möchte.

Es gibt auch englische Lehnwörter, die im Deutschen ohne besondere Kennzeichnung eingesetzt werden, aber trotzdem ein <span lang="en"> verdienten.

An den Schreibregeln für eingedeutschte Begriffe lässt sich festmachen, dass genau dies nicht sinnvoll ist. Wenn nämlich etwa von "mehreren Browsern" die Rede ist, ist "Browsern" kein korrektes Englisch, dürfte also nicht ausgezeichnet werden. Warum sollte dieses im deutschen Sprachschatz inzwischen arrivierte Lehnwort dann aber in der Einzahl markiert werden, wenn es grammatisch bereits integriert worden ist?

Um eine Klasse kommt man also nicht herum.

Das Eine schließt das Andere sicher nicht aus.

Aber ich verstehe, was du meintest, damit hast du natürlich recht.

Mich meinst du damit zwar nicht, aber ich möchte an dieser Stelle kurz erwähnen, dass ich diese Diskussion als sehr angenehm und lehrreich empfinde.
MfG, at

[at]

Hallo.

Alleine den Namen einer Zeitung, eines Filmes, einer Fernsehshow usw. bei jeder Nennung unabhängig vom Kontext als Quellenreferenz zu bezeichnen, halte ich für weit hergeholt.

Da bin ich anderer Ansicht.

In manchen Kontexten passt es natürlich, beispielsweise bei: »Wie das Nachrichtenmagazin <cite>Der Spiegel</cite> in seiner gestrigen Ausgabe berichtete, ...« Aber in einem simplen Satz wie »Die tageszeitung wurde kürzlich 25 Jahre alt« würde ich nicht <cite>tageszeitung</cite> schreiben, nur weil eine allgemeine inhaltliche Bezugnahme vorliegt.

Aus schriftgestalterischer Sicht ist die Kursivstellung im aufgeführten Beispiel auch gar nicht zu vertreten. Wenn man sie dennoch verwenden will, sollte man also damit rechnen, keine vorgefertigte Semantik vorzufinden.

Das samp-Element »designates sample output from programs, scripts, etc.« Das passt in der Regel nicht, insbesondere nicht, wenn ein normalsprachliches Beispiel gegeben wird.

Was normalsprachlich ist, weiß leider der Leser allein. Der Autor muss hier also abwägen, was er als "etc." einstuft.

Das passt auch nicht, das dfn-Element »indicates that this is the defining instance of the enclosed term.« Dieser Fall liegt in keinem der Beispiele vor. Bei den gerechtfertigten Anwendungen stellte sich die Frage, wie die Folgevorkommen ausgezeichnet werden, welche ebenfalls kursiv dargestellt werden sollen.

Weshalb nicht genau so?

Das denke ich nicht. Darüber habe ich mir schon Gedanken gemacht, ich bleibe weiterhin bei der Meinung, dass es für keines der genannten Beispiele ein hinreichend stimmiges Elements gibt. <span class="..."> lässt grüßen...

Das möchte ich gar nicht ausschließen. Nur habe ich den Eindruck, dass viele gar nicht erst versuchen, ein passendes Tag zu finden, weil sie aus der Beutzung gängiger Textverarbeitungsprogramme die nicht semantisch hinterfragte Nutzung von Auszeichnungen gewohnt sind.
MfG, at

[wahsaga]

hi,

In manchen Kontexten passt es natürlich, beispielsweise bei: »Wie das Nachrichtenmagazin <cite>Der Spiegel</cite> in seiner gestrigen Ausgabe berichtete, ...«

auch so halte ich es für völlig unpassend eingesetzt.

_das_, was der spiegel berichtet hat, kannst du mit <cite> kenntlich machen - aber "der spiegel" damit zu umschliessen, ergibt für mich gar keinen semantischen sinn.

gruss,
wahsaga

[wahsaga]

hi,

sorry, nach dem ich gearde tims beitrag, [pref:t=58783&m=330620], gelesen habe, muss ich gestehen, dass ich hier wohl falsch liege.

gruss,
wahsaga

[at]

Hallo.

sorry, nach dem ich gearde tims beitrag, [pref:t=58783&m=330620], gelesen habe, muss ich gestehen, dass ich hier wohl falsch liege.

Ja, multifunktionale Tags sind wirklich unpraktisch. Sobald eigene DTDs von mehr als 99% der Browser unterstützt werden, sollte sich dieses Problem jedoch erlefigt haben ;-)
MfG, at

[Sven Rautenberg]

Moin!

Wahrscheinlich ist es nicht verkehrt, wenn man künftig diese beiden Tags als äquivalent zu <strong> und <em> behandelt, ihnen also eine zusätzliche semantische Bedeutung gibt.

Wie stellst du dir das vor? Wie soll man Elementen, die für die fette bzw. kursive *Darstellung* von Inhalten sorgen, eine semantische Bedeutung zuordnen können?

Wenn heutzutage die Faustformel gilt: Nimm semantische Tags, keine physikalischen, und die Leute deshalb <strong> statt <b> nehmen, um Fettschrift zu erzeugen, dann kann man umgekehrt auch folgern, dass die Bedeutung von <strong> nicht "starke Hervorhebung", sondern physikalisch "Fettschrift" ist. Mit anderen Worten: Die zwei Tags sind äquivalent. Mithin wäre es simpel, wenn man dem <b>-Tag dann ebenfalls nicht nur "Fettschrift" als Bedeutung zuordnet, sondern auch "starke Betonung". Denn wenn <strong> nur deswegen genutzt wird, weil <b> angeblich böse ist, um Fettschrift zu erreichen, werden diese zwei Tags austauschbar.

Und wenn ich mir Lynx' Darstellung so ansehe, dann erkenne ich zwischen <b> und <strong> auch keinen Unterschied - und das, obwohl gerade Lynx von semantischer Auszeichnung mehr profitiert (beispielsweise, was die vernünftige Darstellung von <Hx>-Überschriften etc. angeht), und die Darstellung von "Fettschrift" ohnehin nicht funktioniert. :)

- Sven Rautenberg

[Michael Jendryschik]

Hallo,

Wie stellst du dir das vor? Wie soll man Elementen, die für die fette bzw. kursive *Darstellung* von Inhalten sorgen, eine semantische Bedeutung zuordnen können?

Wenn heutzutage die Faustformel gilt: Nimm semantische Tags, keine physikalischen, und die Leute deshalb <strong> statt <b> nehmen, um Fettschrift zu erzeugen,

dann ist das einfach nur falsch, und man sollte die Leute darüber aufklären, statt ihr Verhalten dadurch zu rechtfertigen, dass man postuliert, 'b' habe ebenfalls die Bedeutung 'stark betont', auch wenn dies nicht der Fall ist.

Gruß,

MI

[Sven Rautenberg]

Moin!

Wenn heutzutage die Faustformel gilt: Nimm semantische Tags, keine physikalischen, und die Leute deshalb <strong> statt <b> nehmen, um Fettschrift zu erzeugen,

dann ist das einfach nur falsch, und man sollte die Leute darüber aufklären, statt ihr Verhalten dadurch zu rechtfertigen, dass man postuliert, 'b' habe ebenfalls die Bedeutung 'stark betont', auch wenn dies nicht der Fall ist.

Ok. Dann wird in der Konsequenz den Leuten also eine von zwei Alternativen bleiben:

1. Es wird zum Erzeugen von Fettschrift wieder nur <b> genommen.
2. Es wird zum Erzeugen von Fettschrift <span style="font-weight:bold"> genommen.

Beides ist semantisch gesehen suboptimal. Aber das <b> hat aufgrund seiner Nähe zum <strong> bzw. generell aufgrund seiner physikalischen Funktion "Fettschrift" (denn was Fettschrift macht, hebt hervor - ob nun "strong" oder nur "em", sei dahingestellt) immerhin noch irgendeinen Wert, während <span> komplett wertlos ist.

- Sven Rautenberg

[Michael Jendryschik]

Hallo,

Wenn heutzutage die Faustformel gilt: Nimm semantische Tags, keine physikalischen, und die Leute deshalb <strong> statt <b> nehmen, um Fettschrift zu erzeugen,

dann ist das einfach nur falsch, und man sollte die Leute darüber aufklären, statt ihr Verhalten dadurch zu rechtfertigen, dass man postuliert, 'b' habe ebenfalls die Bedeutung 'stark betont', auch wenn dies nicht der Fall ist.

Ok. Dann wird in der Konsequenz den Leuten also eine von zwei Alternativen bleiben:

1. Es wird zum Erzeugen von Fettschrift wieder nur <b> genommen.
2. Es wird zum Erzeugen von Fettschrift <span style="font-weight:bold"> genommen.

Beides ist semantisch gesehen suboptimal.

Ich kann mich nicht erinnern, wann ich zuletzt eine dieser beiden Alternativen verwendet habe. Wenn ich Textstellen auf eine besondere Art und Weise kennzeichen möchte, hat das immer auch einen semantischen Grund. Dann verwende ich 'span' zusammen mit einem aussagekräftigen Bezeichner. Oder aber ich möchte in der Tat eine Betonung ausdrücken, dann verwende ich 'em' oder 'strong'. Die Elemente 'b' und 'i' finde ich schlichtweg überflüssig.

Gruß,

MI

[Michael Jendryschik]

Hallo,

Wie ist es nun besser/empfehlenswerter?
Lieber komplett auf Textauszeichnung mit HTML verzichten, also anstatt <strong> <span style="font-weight:bold"> (oder mit Klassen) verwenden?

Du hast hier einiges falsch verstanden. 'strong' und 'span' sind Elemente der logischen Textauszeichnung, versehen Inhalte mit einer Bedeutung wie auch 'h1' bis 'h6', 'li' oder 'p'. Die Semantik durch 'span'-Konstrukte zu verwischen, wäre äußerst dumm.

Böse Zungen behaupten ja, statt

<h1>Überschrift</h2>

<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
     elit, sed diam <em>nonummy</em> nibh euismod tincidunt
     ut laoreet dolore magna aliquam erat volutpat.</p>

<ul>
    <li>Listenpunkt</li>
    <li>Listenpunkt</li>
    <li>Listenpunkt</li>
  </ul>

würde immer mehr wie folgt ausgezeichnet werden:

<div class="ueberschrift1">Überschrift</div>

<div class="text">Lorem ipsum dolor sit amet, consectetuer adipiscing
     elit, sed diam <span class="betont">nonummy</span> nibh euismod
     tincidunt ut laoreet dolore magna aliquam erat volutpat.</div>

<div class="liste">
    <div><img src="schwarzer_punkt.png" /> Listenpunkt</div>
    <div><img src="schwarzer_punkt.png" /> Listenpunkt</div>
    <div><img src="schwarzer_punkt.png" /> Listenpunkt</div>
  </div>

Wenn ich nun kursiv UND fett haben will, dann immer noch mit
<strong><em>bla</em></strong>, oder lohnt sich dann eher ein <span> mit den entsprechenden Eigenschaften?

'span' und 'em' haben mit »fett« und »kursiv« nur so viel zu tun, dass das die Standarddarstellung in den meisten Browsern ist. Das Element 'strong' zeichnet einen Text als »stark betont« aus, das Element 'em' als »betont«. Das kann auch anders ausgedrückt werden, zum Beispiel durch Farbe oder aber durch besonders laute Aussprache in Screenreadern. Wenn du Inhalte fett bzw. kursiv darstellen möchtest, verwende 'b' bzw. 'i' -- oder aber entsprechende 'span'-Konstruktionen mit geeigneten (also an der Semantik orientierten) Bezeichnern.

Könnte man sicher länger fortsetzen, generell ist einfach die Frage: Wann immer möglich/sinnvoll logische Textauszeichnung verwenden, oder auf nichtssagende span's ausweichen?

Ich frage dich: Welche Vorteile glaubst du für dich oder die Nutzer deiner Seiten zu erkennen, wenn du alle Semantik durch bedeutungslose Konstruktionen verwischt? Wie kommst du überhaupt auf so eine Idee?

btw: Man soll ja in z.B. in XHTML alle Elemente und Attribute klein schreiben, gilt das auch für Farbangaben? Also #00ffcc anstatt #00FFCC?

Was sagt der Validator?

Gruß,

MI

[dbenzhuser]

Vielen Dank an alle!

Da bin ich wahrscheinlich auf meinem Weg zum
<span class="wirklich_sehr_sehr_wichtig"><strong><em>
perfekten
</em></strong></span>
Code ein ganzes Stück weitergekommen ;)

(und hab einiges An Arbeit vor mir...)

dbenzhuser