Ich hatte mal einen Chef, der Wörter geliebt, geliebt, geliebt, geliebt hat. Das war lange bevor wir WYSIWYG-Editoren benutzten und ich diesen Mist von Hand codieren musste.
<p>
I used to have this boss who <em>loved</em>, <strong>loved</strong>,
<strong><em>loved</em></strong>, <strong><em><u>loved</u></em></strong>
to emphasize words.
</p>
(Lass uns nicht auf die Farben eingehen, die er für noch MEHR Betonung verwendet hat.)
Diese ganze Markup-Schreiberei fühlte sich nie gut an. Der Aufwand, den es kostete, klar, was auch immer. Aber ist es überhaupt eine gute Idee, Inhalte mit doppelten – oder mehr! – Betonungen zu überladen?
Verschiedene Tags vermitteln unterschiedliche Betonungen
Zunächst einmal sind die Tags <strong> und <em> für unterschiedliche Zwecke konzipiert. Wir haben sie in HTML5 bekommen, wo
<strong>: Wird verwendet, um „starke Wichtigkeit, Ernsthaftigkeit oder Dringlichkeit für seinen Inhalt“ zu vermitteln.<em>: Repräsentiert „Betonung durch Hervorhebung“.
Also gibt <strong> dem Inhalt mehr Gewicht in dem Sinne, dass es darauf hindeutet, dass der Inhalt darin wichtig oder dringend ist. Denken Sie an eine Warnung
Warnung: Der folgende Inhalt wurde als großartig gekennzeichnet.
Es mag verlockend sein, zu diesem Zweck nach <em> zu greifen. Kursiver Text kann schließlich Aufmerksamkeit erregen. Aber es ist wirklich als Hinweis gedacht, den Inhalt beim Lesen stärker zu betonen. Zum Beispiel hier zwei Versionen desselben Satzes mit der Betonung an verschiedenen Stellen
<p>I ate the <em>entire</em> plate of burritos.</p>
<p>I ate the entire <em>plate</em> of burritos.</p>
Beide Beispiele betonen die Hervorhebung, aber auf verschiedenen Wörtern. Und sie würden unterschiedlich klingen, wenn man sie laut vorlesen würde. Das macht <em> zu einer großartigen Möglichkeit, Ton in Ihrer Schrift auszudrücken. Es ändert die Bedeutung des Satzes auf eine Weise, die <strong> nicht tut.
Visuelle Betonung vs. semantische Betonung
Das sind zwei Dinge, die Sie bei der Hervorhebung von Inhalten abwägen müssen. Zum Beispiel gibt es viele Fälle, in denen Sie Inhalt kursivieren müssen, ohne die Bedeutung des Satzes zu beeinträchtigen. Aber diese können mit anderen Tags behandelt werden, die Kursivschrift rendern
<i>: Das ist der Klassiker! Vor HTML5 wurde dies verwendet, um überall Betonung durch Kursivschrift zu erzielen. Jetzt wird es rein visuell verwendet, um Inhalte kursiv zu gestalten, ohne die semantische Bedeutung zu ändern.<cite>: Gibt die Quelle einer Tatsache oder Zahl an. („Quelle: CSS-Tricks“)<address>: Wird verwendet, um Kontaktinformationen zu kennzeichnen, nicht nur physische Adressen, sondern auch Dinge wie E-Mail-Adressen und Telefonnummern. ([email protected])
Bei <strong> wird es genauso sein. Anstatt es zum Stylen von Text zu verwenden, der schwerer aussehen soll, ist es besser, den klassischen <b>-Tag zum Fettdruck zu verwenden, um Inhalten, die es nicht benötigen, keine zusätzliche Bedeutung zu verleihen. Und denken Sie daran, einige Elemente wie Überschriften werden dank der Standardstile des Browsers bereits fett gedruckt. Es besteht keine Notwendigkeit, noch mehr starke Betonung hinzuzufügen.
Kursivschrift in hervorgehobenem Inhalt (und umgekehrt) verwenden
Es gibt legitime Fälle, in denen Sie einen Teil einer Zeile kursivieren müssen, die bereits hervorgehoben ist. Oder vielleicht einen Teil des Textes hervorheben, der bereits kursiv ist.
Eine Blockquote könnte ein gutes Beispiel sein. Ich habe schon oft gesehen, dass sie aus stilistischen Gründen kursiviert werden, obwohl die Standardstile des Browsers dies nicht tun
blockquote {
font-style: italic;
}
Was ist, wenn wir einen Filmtitel in dieser Blockquote erwähnen müssen? Das sollte kursiviert werden. Es ist keine starke Betonung erforderlich, daher reicht ein <i>-Tag aus. Aber es ist trotzdem seltsam, etwas zu kursivieren, wenn es bereits so gerendert wird
<blockquote>
This movie’s opening weekend performance offers some insight in
to its box office momentum as it fights to justify its enormous
budget. In its first weekend, <i>Avatar: The Way of Water</i> made
$134 million in North America alone and $435 million globally.
</blockquote>
In einer Situation, in der wir etwas innerhalb von kursiviertem Inhalt wie diesem kursivieren, sollen wir die Kursivschrift aus dem verschachtelten Element entfernen... <i> in diesem Fall.
blockquote i {
font-style: normal;
}
Container-Stil-Abfragen werden sehr nützlich sein, um all diese Fälle zu erfassen, wenn wir sie bekommen
blockquote {
container-name: quote;
font-style: italic;
}
@container quote (font-style: italic) {
em, i, cite, address {
font-style: normal;
}
}
Dieser kleine Ausschnitt wertet die Blockquote aus, um zu sehen, ob ihre font-style auf italic gesetzt ist. Wenn ja, dann stellt er sicher, dass die Elemente <em>, <i>, <cite> und <address> als normaler Text gerendert werden, während die semantische Bedeutung beibehalten wird, falls vorhanden.
Aber zurück zur Betonung innerhalb der Betonung
Ich würde <strong> nicht in <em> wie folgt verschachteln
<p>I ate the <em><strong>entire</strong></em> plate of burritos.</p>
...oder <em> stattdessen in <strong> verschachteln
<p>I ate the <em><strong>entire</strong></em> plate of burritos.</p>
Das Rendering ist in Ordnung! Und es spielt keine Rolle, in welcher Reihenfolge sie sind... zumindest in modernen Browsern. Jennifer Kyrnin erwähnt, dass einige Browser nur den Tag am nächsten am Text rendern, aber ich bin dem bei meinen begrenzten Tests nirgends begegnet. Aber etwas zum Beobachten!
Der Grund, warum ich eine Betonungsform nicht in eine andere verschachteln würde, ist, dass es einfach nicht nötig ist. Es gibt keine Grammatikregel, die dies vorschreibt. Wie bei Ausrufezeichen reicht eine Form der Betonung aus, und Sie sollten diejenige verwenden, die zu dem passt, was Sie erreichen möchten, sei es visuell, Gewicht oder angekündigte Betonung.
Und obwohl einige Screenreader dazu in der Lage sind, hervorgehobenen Inhalt anzukündigen, lesen sie das Markup nicht mit zusätzlicher Bedeutung oder Betonung vor. Also, soweit ich sehen kann, keine zusätzlichen Barrierefreiheitsvorteile.
Aber ich will wirklich all die Betonung!
Wenn Sie sich in der Position befinden, in der Ihr Chef wie meiner ist und ALLLE die Betonung will, würde ich zum richtigen HTML-Tag für die Art der Betonung greifen und dann den Rest der Stile mit einer Mischung aus Tags anwenden, die keine Semantik beeinflussen, mit CSS, um alles zu berücksichtigen, was Browserstile nicht handhaben.
<style>
/* If `em` contains `b` or `u` tags */
em:has(b, u) {
color: #f8a100;
}
</style>
<p>
I used to have this boss who <em>loved</em>, <strong>loved</strong>,
<strong><em>loved</em></strong>, <strong><em><u>loved</u></em></strong>
to emphasize words.
</p>
Ich könnte es sogar mit dem <strong>-Tag als Vorsichtsmaßnahme tun
/* If `em` contains `b` or `u` tags */
em:has(b, u),
/* If `strong` contains `em` or `u` tags */
strong:has(i, u) {
color: #f8a100;
}
Solange wir uns defensiv verhalten, können wir Fehler identifizieren, bei denen Betonungen in Betonungen verschachtelt sind, indem wir sie rot oder so hervorheben
/* Highlight semantic emphases within semantic emphases */
em:has(strong),
strong:has(em) {
background: hsl(0deg 50% 50% / .25);
border: 1px dashed hsl(0deg 50% 50% / .25);
}
Dann würde ich wahrscheinlich den Ausschnitt aus dem letzten Abschnitt verwenden, der die Standard-Kursivschrift eines Elements entfernt, wenn es in einem anderen kursivierten Element verschachtelt ist.
Sonst noch was?
Viiiiielleicht
- Stellen Sie sicher, dass Ihre Webfonts fette und kursive Varianten enthalten – andernfalls verlassen Sie sich darauf, dass der Browser versucht, Text für Sie fett oder kursiv zu drucken. Beschränken Sie Ihre Schriftdateien jedoch auf die von Ihnen benötigten Schnitte und Stile für eine bessere Leistung.
- Erwägen Sie, den Inhalt neu zu formulieren, wenn die Formatierung falsch erscheint. Es gibt natürliche Wege, Inhalte so zu formulieren, dass bestimmte Teile an Betonung gewinnen.
- Überprüfen Sie Ihre Analysedaten für die Browser, die Ihre Besucher verwenden, und testen Sie entsprechend. Auch wenn ich keinem Browser begegnet bin, der
<strong>in<em>oder umgekehrt verweigert hat, kann es einen Browser oder mehrere geben, die dies tun.
Nur zur Info, Ihre Erwähnungen der HTML5-Spezifikation sind weit daneben – strong/em wurden lange vor HTML5 eingeführt. Mindestens HTML3, wenn nicht früher.
Sieht aus, als wäre es HTML2 (http://www.martinrinehart.com/frontend-engineering/engineers/html/html-tag-history.html)
Auch
<i>und<b>haben seit der Einführung in HTML5 wieder semantische Bedeutungen. Sie sind nicht nur zum Kursivieren oder Fettdrucken von Text da.4.5.20 Das
i-Element4.5.21 Das
b-ElementAber was ist mit der Verschachtelung von
<em>in<em>oder<strong>in<strong>?Der HTML-Standard gibt Beispiele für beide Fälle
(https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-em-element)
(https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-strong-element)
Die folgende Aussage scheint im Widerspruch zur aktuellen Spezifikation zu stehen
Laut MDN
Guter Artikel, Jeff. Als Schriftsteller, der Grammatikregeln befolgt, ist es wichtig, nur dort Betonung zu setzen, wo sie benötigt wird, und es nicht zu übertreiben. Es gibt sehr gute Bücher über Stilregeln (Strunk & White ist eines davon).
Ob Spezifikationen in HTML2, 3 oder 5 eingeführt wurden, ist fast irrelevant. Wichtig ist, einer Art Grammatikregel zu folgen, egal ob Sie
<i>,<b>,<em>oder<strong>verwenden – die Wahl liegt bei Ihnen.Warum jemand diese Elemente verschachteln möchte, ist mir schleierhaft, auch wenn der HTML-Standard Beispiele liefert. Wenn Sie einen Text bereits hervorgehoben haben, übertreiben Sie es um Himmels willen nicht!
Großartiger Artikel, Jeff. Ich stimme Ihnen vollkommen zu. Das Verschachteln von
<i>,<em>,<strong>und<b>erscheint mir tautologisch und sehr unnötig.