Dieser Artikel ist Teil einer Serie:
- Fragen zu HTML5 & Co 1
- Fragen zu HTML5 & Co 2
- Fragen zu HTML5 & Co 3
- Fragen zu HTML5 & Co 4
- Fragen zu HTML5 & Co 5
- Fragen zu HTML5 & Co 6
- Fragen zu HTML5 & Co 7
- Fragen zu HTML5 & Co 8
- Fragen zu HTML5 & Co 9
- Fragen zu HTML5 & Co 10
- Fragen zu HTML5 & Co 11
- Fragen zu HTML5 & Co 12
- Fragen zu HTML5 & Co 13
- Fragen zu HTML5 & Co 14
- Fragen zu HTML5 & Co 15
- Fragen zu HTML5 & Co 16
- Fragen zu HTML5 & Co 17
- Fragen zu HTML5 & Co 18
- Fragen zu HTML5 & Co 19
- Fragen zu HTML5 & Co 20
- Fragen zu HTML5 & Co 21
- Fragen zu HTML5 & Co 22
- Fragen zu HTML5 & Co 23
- Fragen zu HTML5 & Co 24
- Fragen zu HTML5 & Co 25
- Fragen zu HTML5 & Co 26
- Fragen zu HTML5 & Co 27
Als Erklärbär für HTML5 und andere Webtechnologien bekomme ich jede Woche neue Fragen rund um Webentwicklung gestellt. Da diese Fragen (und Antworten) viel zu schade sind, um sie in meinem E-Mail-Archiv verrotten zu lassen, hole ich sie im Rahmen der Artikelserie „Fragen zu HTML5 und Co“ regelmäßig ans Tageslicht – denn dumme Fragen gibt es schließlich nicht!
Wann welches Element verwenden?
Wann sollte man
<mark>
verwenden und wann<strong>
,<em>
,<b>
, und<i>
?
Es stimmt, dass all diese Elemente auf den ersten Blick so ziemlich das gleiche zu machen scheinen und es nicht immer ganz einfach, das richtige Element zu wählen. Anhand von Beispielen bekommt man am besten ein Gefühl dafür, was wann richtig ist und die gute Nachricht an dieser Stelle ist: es gibt in den HTML5-Spezifikationen offizielle Beispiele, hier für <em>
. Eine der großen Errungenschaften von HTML5 ist nicht zuletzt die Qualität der Spezifikationen. Während man in den offiziellen Dokumenten zu HTML 4.01 nur sehr spärliche Erläuterungen und Beispiele findet (wenn überhaupt) sind die HTML5-Specs voll mit Beispielen, Tutorials und erklärender Prosa.
Wenn man also ein Beispiel oder eine Erklärung sucht, kann der Blick in den offiziellen Standard durchaus lohnen. Wem die offiziellen Specs mit ihrem monströsen Umfang etwas zu abschreckend erscheinen, könnte mit den Web Developer Editions von W3C und WHATWG (ja, davon gibt es gleich zwei, eine von jeder Arbeitsgruppe) glücklich werden.
Um aber die eigentliche Frage zu beantworten:
<strong>
: Wichtige Textpassagen, deren Wichtigkeit die Bedeutung des betroffenen Satzes nicht verändert.<em>
: Betonte Textpassagen, deren Betonung die Bedeutung des betroffenen Satzes verändert.<b>
und<i>
: Textpassagen, die vom Rest abgesetzt, aber nicht auf- oder abgewertet werden sollen. Beispiele wären Produktnamen in einem Review oder Wörter aus anderen Sprachen. Dabei sollte man<b>
verwenden, wenn die typografische Repräsentation der betroffenen Passage üblicherweise fetter Text wäre und<i>
, wenn es kursiver Text wäre.<mark>
: Hervorhebung von Textpassagen, die in einem nicht aus ihrem Ursprungskontext heraus eine Hervorhebung verdient hätten, sondern die nur aufgrund eines speziellen Umstandes relevant sind – z.B. weil sie ein Keyword sind, nach dem der Nutzer gesucht hat.
XLink und XHTML5
Für XML-basierte Sprachen wie z.B. SVG gibt es doch die Sprache XLink. Wäre es rein theoretisch auch möglich, sie in XHTML5 einzubinden?
XLink kann man theoretisch schon in XHTML verwenden. Es ist schließlich alles nichts weiter als XML und die (X)HTML5-Spezifikationen erlauben die Verwendung des XLink-Namespaces auch ausdrücklich. Das Problem ist nur, dass es meiner Recherche nach so gut wie gar keine Browserunterstützung gibt. Einzig der Firefox scheint Teile von XLink für SVG- und MathML-Dokumente zu implementieren.
<nav> und ARIA
Macht es Sinn, das
<nav>
-Element und WAI-ARIA in Kombination zu verwenden, also z.B. als<nav role="navigation">
? Oder ist das doppelt gemoppelt? Das<nav>
macht doch eigentlich schon deutlich, dass es sich um eine Navigation handelt …
Das ist in der Tat zumindest laut Standard doppelt gemoppelt, denn diese ARIA-Role wird Nav-Elementen automatisch zugeteilt. In der Realität sieht die Sache aber schwieriger aus. Wie man dieser Tabelle hier entnehmen kann, haben die wenigsten Browser heutzutage diese ARIA-Mappings auch wirklich standardkonform implementiert.
Was tun? Rumprobieren und testen. Es mag zwar falsch sein, role="navigation"
zu verwenden, aber wenn das der einzige Weg ist, die Navigation auch für Screenreader als solche auszuzeichnen (und ich weiß nicht, ob das der Fall ist – was machen Browser, die <nav>
unterstützen, lesen die dann zwei mal „Navigation“ vor?), dann sollte man sich nicht aufhalten lassen. Regeln sind da, um (nach Kenntnisnahme und gründlichem Nachdenken) gebrochen zu werden.
Selektive Anwendung von CSS-Regeln auf Links
Ich verwende Attributselektoren, um externe Links zu markieren. Hierfür suche ich jetzt eine Erweiterung: Ich habe einen Share-Button von Add this integriert und in der Javascript-Box stören diese Markierungen. Wie kann der Code
a[target=_blank]{}
erweitert werden, so dass die Regel nicht für eine bestimmte Ziel-URL gilt?
Hier gibt es zwei mögliche Lösungen und jeweils helfen die Attributselektoren für Substrings, die in CSS3 frisch eingeführt wurden. Zum einen kann man eine bestehende Markierung für alle Links, deren href
-Attribut mit einer bestimmten URL beginnt, einfach zurücksetzen …
/* Externe Links markieren... */ a[target="_blank"]{ background: yellow; } /* ... und die Markierung wieder zurücksetzen */ a[href^="http://www.facebook.com"]{ background: none; }
… oder man greift zur Negations-Pseudoklasse (:not()
) und wendet die Markierung gar nicht erst auf Links mit der betreffenden URL an:
/* All-in-one-Lösung */ a[target="_blank"]:not([href^="http://twitter.com"]){ background: yellow; }
Beide Lösungen führen zum gleichen Ergebnis, allerdings funktioniert die :not()
-Variante im Internet Explorer erst ab Version 9.
Weitere Fragen?
Eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Formspring bemühen und ein bisschen Geduld haben – falls ich gerade unterwegs bin, kann es mit Antwort manchmal etwas dauern, doch früher oder später schreibe ich garantiert zurück.
Kommentare (7)
Eric Eggert ¶
14. Mai 2012, 13:29 Uhr
zu ARIA:
ja, im Moment
role="navigation"
unbedingt einsetzen, entweder im HTML-Code oder als Polyfill. Es wird nicht doppelt angesagt, da die implizite Rolle von der expliziten überschrieben wird. Und es ist total valide und richtignav
zu verwenden und der Validator hat auch mit<nav role="navigation">
gar keine ProblemePeter Kröner ¶
14. Mai 2012, 13:42 Uhr
Danke für die Info, dass das tatsächlich nötig ist und keine Probleme macht. Streng genommen valide ist es allerdings nicht, wenn man ganz genau in die Specs schaut:
Aber wie gesagt – Regeln sind da, um gebrochen zu werden. Und wenn der Validator nicht meckert, merkt es ja auch keiner :)
Gerhard Großmann ¶
14. Mai 2012, 14:51 Uhr
Off Topic:
Ich kann mich noch immer nicht an die Pfeile gewöhnen, mit denen du externe Links kenzeichnest. Von ihrer Gestaltung her scheinen sie immer auf das nachfolgende Wort zu verweisen, à la → siehe Seite 64. Außerdem reißen sie eine Lücke in den Text.
Wie wäre es mit einem diagonalen Pfeil (↗), der auch nicht so viel horizontalen Platz einnimmt?
Peter Kröner ¶
14. Mai 2012, 22:45 Uhr
Muss mal schauen was die älteren Browser-Betriebssystem-Kombinationen damit anstellen, aber an sich ist das keine schlechte Idee mit dem neuen Pfeil.
Don ¶
17. Mai 2012, 16:31 Uhr
zu
<mark>
:könnte man theoretisch die Bezeichnung der Html-Elemente in deinen Texten in
<mark>
setzen?Peter Kröner ¶
17. Mai 2012, 16:38 Uhr
Nein, jedenfalls nicht im Normalfall. Nur wenn die Elemente aus Gründen relevant werden, die nicht direkt aus dem Text selbst hervorgehen – also wenn sie z.B. in Suchergebnissen hervorgehoben werden sollen oder im Rahmen eines Kommentars besprochen werden. Falls die Elemente von sich aus wichtig sind, sind sie besser mit
<em>
und Konsorten hervorgehoben.David Vielhuber ¶
18. Mai 2012, 00:29 Uhr
Ein großes Problem liegt meiner Meinung nach in WYSIWYG-Editoren, die quasi nur ein FETT-geschriebenes Wort kennen (meist mit < strong > gekennzeichnet). Solange dort nicht mehr Auswahlmöglichkeiten mit guten Erklärungen, so wie Du sie lieferst, zu finden ist, werden die Elemente weiterhin in falschem Kontext verwendet werden.