Wenn Sie die font-weight einer Schriftart ändern, verursacht der Text in der Regel eine leichte Layout-Verschiebung. Das liegt daran, dass fetter Text oft größer ist und mehr Platz einnimmt. Manchmal spielt das keine Rolle, wie bei einer vertikalen Anordnung von Links, wo der breitere/fettere Text sowieso nichts verschiebt. Manchmal spielt es eine Rolle, wie bei einer horizontalen Reihe, wo der breitere/fettere Text andere Elemente ein kleines bisschen wegschiebt.
Das Hervorheben von Text beim Mouse-Hover verursacht eine Layout-Verschiebung, die besonders auffällig ist, wenn sich Elemente umbrechen. Hier ist ein raffinierter Trick: Fügen Sie ein verstecktes Pseudo-Element mit demselben Textstring hinzu, aber setzen Sie es auf die fette Schriftgröße 🙌
— Ryan Mulligan (@hexagoncircle) 20. Juli 2020
Siehe es auf @CodePen: https://#/kBzZXqqtmi pic.twitter.com/kdZBTLQ0RD
Ryans Technik ist sehr clever. Jedes Element in der Liste hat ein Pseudo-Element mit dem exakten Text des Links. Dieses Pseudo-Element ist visuell versteckt, aber bereits fett formatiert und nimmt trotzdem Platz ein. Wenn also der eigentliche Linktext fett formatiert wird, nimmt er keinen zusätzlichen Platz ein.
Es hängt auch irgendwie davon ab, wie Sie das Layout gestalten. Hier, wenn ich vier Spalten mit CSS Grid erzwinge und Text, der die Breite nicht wirklich herausfordert, beeinflusst die Fettschrift auch nicht das Layout
Aber wenn ich zum Beispiel zulasse, dass sich diese Links in automatische Spalten aufteilen, hätten wir das Problem der Verschiebung.
Schöner Trick!
Ich möchte einen anderen Ansatz erwähnen, der die Verwendung einer Uniwidth-Schrift (nicht zu verwechseln mit Monospace) wäre, bei der Zeichen über alle Schriftschnitte hinweg die gleiche Breite haben. Eine solche Schrift, die ich mag, ist PT Root UI. Ich weiß, dass dies möglicherweise nicht immer funktioniert und offensichtlich die Designauswahl einschränkt, aber andererseits halte ich es für eine sauberere und weniger "hacky" Lösung.
Was ist mit den Auswirkungen auf die Barrierefreiheit? Würden Screenreader den Text zweimal lesen?
Ich verwende -webkit-text-stroke dafür. Es sieht nicht so gut aus wie "echte" fette Schrift, ist aber normalerweise unter 0,1em nicht schlecht. Es bedeutet möglicherweise, dass Sie keine zusätzliche Schriftstärke laden müssen, und obwohl es nicht standardisiert ist, wird es in jedem Browser unterstützt. Außer natürlich IE, aber Sie können @supports mit einer Überschreibung verwenden, um tatsächliche fette Schrift anzuzeigen, oder sich nicht darum kümmern, dass 1% diesen Text nicht wie beabsichtigt sehen.
Der Text im Pseudo ist display: none, versteckte Farbe weiß oder so etwas. Der Benutzer sieht ihn also nie. Nur der Browser weiß, dass er da ist und berücksichtigt den von ihm eingenommenen Platz.
Genau meine Meinung. Dies ist wahrscheinlich keine gute Lösung für diejenigen, die sich um ADA-Konformität kümmern.
Screenreader können den Inhalt von Pseudo-Elementen nicht lesen, daher sollte es in Ordnung sein.
Ich würde vorschlagen, mit variablen Schriften zu arbeiten, die keine Fixierung benötigen und perfekt funktionieren.
Ich verwende bereits seit Jahren before und after für diese Art der Größenanpassung… Ich freue mich, dass Sie es hier erwähnt haben. Mehr Leute sollten das wissen. :)
Absolute Positionierung von Pseudo-Elementen mit einem relativ positionierten Hauptelement kann in einigen Fällen ebenfalls nützlich sein.
Gibt es etwas Falsches daran, text-shadow für diesen Zweck zu verwenden?
Nicht falsch, aber fett und text-shadow sind nicht wirklich dasselbe.
Ich weiß, dass es nicht dasselbe ist, aber visuell kann man mit text-shadow einen fast identischen Effekt erzielen, ohne das DOM überhaupt zu beeinflussen.
Ja! Es kann mit text-shadow gemacht werden, aber ich glaube nicht, dass wir damit denselben Effekt wie mit dieser Idee erzielen können.
Was ist mit letter-spacing? Vielleicht ist es möglich, die richtige Menge zu finden, um die Fettschrift auszugleichen – oder vielleicht ist es nah genug, dass es für die typischerweise kleine Buchstabenanzahl auf einem Button funktioniert?
Wie wäre es mit text-stroke? https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-text-stroke
Funktioniert nicht auf Mobilgeräten. Muss mehrmals tippen, bis es fett wird.
Danke für diesen Trick. Dieser wackelige Effekt hat mich seit über 6 Monaten gestört.
Ich benutze text-shadow, was eher eine Pseudo-Fettschrift ist, aber seinen Zweck erfüllt, und Sie können sogar eine andere Schattierung wählen.
Danke Paul. Mit Ihrer Methode hatte ich die besten Ergebnisse mit
text-shadow: 0px 0px 1px var(–slate);
Ich frage mich, ob die
contain-Eigenschaft für diesen Zweck verwendet werden könntehttps://developer.mozilla.org/en-US/docs/Web/CSS/contain
Wenn die Textfarbe nicht vollständig schwarz ist, was mir oft gefällt, habe ich festgestellt, dass das Abdunkeln der Farbe beim Hovern dasselbe Ziel wie die Erhöhung der Schriftstärke erreichen kann, wenn der Unterschied groß genug ist. Selbst wenn es keine Layout-Probleme gibt, bevorzuge ich es, dass sich nichts verschiebt. :)
Was macht content: attr(data-text) / ”?
Es ist ein Fallback auf eine leere Zeichenkette – https://developer.mozilla.org/en-US/docs/Web/CSS/content#image_combined_with_text
Aber warum wird das hier benötigt?
Abhängig davon, wie fett Sie Ihren Text haben möchten, funktioniert Skalierung, da sie die Größe nicht ändert. Ich habe sie in mehreren Projekten verwendet. Wir gingen von grau zu weißem Text auf Schwarz und skalierten ihn. Der Effekt hat für uns funktioniert.
a:hover {transform: scale(1.05);
}
Dies ist bei weitem meine Lieblingslösung, um dies zu erreichen. Pseudo-Elemente sind eben das – sie sind ein CSS-Element, aber ich würde sie nicht als echtes DOM-Element betrachten. Screenreader lesen sie nicht, daher sollten sich die Leute keine Sorgen machen, dass sie den Text zweimal lesen.
Aber ich wollte auch nur kommentieren und sagen, dass @media screen ab September 2022 veraltet und nicht mehr unterstützt wird https://www.powermapper.com/tests/screen-readers/content/media-query-speech/
Das ist nicht ganz richtig. Pseudo-Elemente werden in die Berechnung des zugänglichen Namens eines Elements einbezogen und von Browser-/Screenreader-Kombinationen angekündigt, die die Spezifikation respektieren.
In diesem Fall wird dieses Problem jedoch durch Hinzufügen von
visibility: hiddengelöst, da der Screenreader Elemente mit dieser Eigenschaft ignoriert.