Richard Rutters Anleitung zum Einstellen der Schriftgröße eines Elements ist interessant: Er argumentiert, dass wir je nach Beziehung zu anderen Elementen auf der Seite sowohl em als auch rem Einheiten verwenden sollten
Betrachten Sie das Beispiel eines Pull-Quotes, das zwei kurze Absätze enthält. Der Abstand zwischen den Absätzen hängt von der Größe des Absatztextes ab, daher könnten Sie diesen Abstand theoretisch in Rem oder Em festlegen. Sollten Sie während Ihres Designprozesses entscheiden, dass der Pull-Quote etwas größer gesetzt werden soll, muss auch der Abstand zwischen den Absätzen vergrößert werden. Daher steht der Absatzabstand in direktem Zusammenhang mit der Größe des Absatztextes und sollte daher als lokale Größenangabe innerhalb einer Komponente betrachtet werden. Daher sollten Sie in diesem Fall Em verwenden.
Dies ergänzt die Methode, die Chris vor ein paar Jahren beschrieben hat
Hier ist also meine Idee: Sie behalten weiterhin
px-Größenanpassungen auf Dokumentenebene bei, damit Sie einfache/effiziente umfassende Größenänderungen vornehmen können. Aber dann hat jedes Modul auf der Seite eine Schriftgröße, die inremangegeben ist. Tatsächliche Textelemente (h1, h2, p, li, was auch immer), wenn Sie sie überhaupt dimensionieren, werden inemdimensioniert und werden somit relativ zum Modul.
Aufgeschlüsselt: Zuerst setzen wir die font-size des Dokumentenelements mit px
html {
font-size: 16px;
@media screen and (min-width: 900px) {
font-size: 18px;
}
@media screen and (min-width: 1200px) {
font-size: 20px;
}
}
Als Nächstes stylen wir alle unsere kleinen Textelemente, wie Absätze, Überschriften oder Blockquotes, mit ems. Das liegt daran, dass sie eine Beziehung zueinander haben
h2 {
font-size: 2em;
}
pre {
font-size: 0.8em;
}
Und schließlich stylen wir die Module, in denen diese Textteile sitzen, mit rems, damit wir alle Texte darin leicht anpassen können
.module {
font-size: 1.1rem;
}
.another-module {
font-size: 1.3rem;
}
...was sich in der Praxis ungefähr so auswirkt
Siehe den Pen Em AND Rem von Chris Coyier (@chriscoyier) auf CodePen.
Was erreichen wir damit? Warum können wir nicht einfach bei rem oder em bleiben, um die Dinge einfach zu halten? Nun, mit dieser Methode wird jedes Modul sofort abgegrenzt und lässt sich leichter für die Zukunft stylen. Aber auch wir können die font-size jedes Moduls schnell anpassen, ohne große Teile der Codebasis ändern zu müssen. Wenn wir feststellen, dass die font-size der gesamten Website erhöht werden muss, müssen wir nur einen einzigen Wert ändern.
em und rem Werte sind für zwei verschiedene Aufgaben nützlich, und wenn wir sie so nutzen, wie sie konzipiert wurden, kann unsere Arbeit etwas wartungsfreundlicher und flexibler werden.
Wie wäre es mit 100% auf :root statt 16px? Ist es nicht Best Practice, Pixel ganz zu vermeiden?
Außerdem ist es nicht besser, rems zu verwenden, indem man auf das :root-Element verweist und nicht auf das html-Element?
100% entspricht dem, was der Benutzer in seinem Browser als Schriftgröße eingestellt hat (standardmäßig meist 16px). Ich schätze, es ist eine Frage, wie viel Kontrolle Sie über die Root-Schriftgröße haben möchten.
Können Sie näher erläutern, warum das Setzen auf :root besser ist als auf html? Ich bin neugierig.
Der :root-Selektor wählt das Wurzelelement des Dokuments aus. Anscheinend ist das html-Element zu 99% dasselbe wie das Wurzelelement (nicht immer). Ich habe gelesen, dass es sogar besser ist, :root auf einen Prozentsatz wie 100 % (oder 62,5 % der Einfachheit halber für spätere Berechnungen, da dann 1 rem 10 px entspricht) und dann html auf 1 rem zu setzen.
:root { font-size: 100% } oder :root { font-size: 62,5% } // 10px
html { font-size: 1,0rem } html { font-size: 1,6rem } // 16px
Tun Sie das. Nicht.
@Anonym
Warum? Hat es etwas mit
:rootzu tun, oder widersprechen Sie der Änderung des Schriftprozentsatzes auf62,5%?Tun Sie es nicht, denn wenn Sie nie eine feste Größe für die Schriftart festlegen, sind Sie vollständig von dem abhängig, was der Benutzer für seine Schriftgröße eingestellt hat. 100 % (oder 62,5 %) ist ein Prozentsatz von *etwas*, also können Sie genauso gut beschreiben, was dieses Etwas sein soll, anstatt den Benutzer entscheiden zu lassen.
@Jake wollen Sie dem Benutzer wirklich das Recht verweigern, seine Standard-Schriftgröße zu ändern?
Ich möchte keine Kommentarkrieg führen. Die meisten modernen Browser ermutigen den Benutzer, die *gesamte Seite* zu zoomen, anstatt nur die Schriftgröße – sie müssen ein wenig tiefer graben, um *nur* die Schriftgröße zu ändern. In diesem Sinne können Benutzer weiterhin hinein- und herauszoomen, auch wenn die Schriftgrößen auf oberster Ebene mit einer nicht-relativen Einheit festgelegt sind. Sie legen nur eine Standardgröße fest.
Was ich (und andere) sagen, ist, dass es keinen Sinn ergibt, die Schriftart auf eine relative Größe zu setzen, aber nicht zu deklarieren, worauf sie sich bezieht. Die meisten Entwickler legen großen Wert auf ihr Design, warum sollten sie dieses Detail dem Zufall überlassen?
@Jake Menschen mit Behinderungen wissen, wie sie ihre Browsereinstellungen ändern können, und können einmalig eine größere Schriftgröße festlegen. Soweit ich weiß, ist Zoom seitenbasiert, sodass sie Zoomaktionen auf jeder neuen besuchten Seite wiederholen müssen, was für sie wirklich mühsam ist.
Das ist überhaupt kein Detail, und es gibt kein "Zufall" dabei, nur Barrierefreiheit, eines der Hauptprinzipien des W3-Designs: https://www.w3.org/Consortium/mission.html#principles
@Jake, @nhoizey hat hier absolut Recht.
Werfen wir einen genaueren Blick auf das Thema, das im Zusammenhang mit Menschen mit Behinderungen erwähnt wurde, und warum es wichtig ist, allen zu helfen, die Inhalte zu genießen.
Wenn wir dem Leitfaden zum Vergrößern von Text und Bildern der offiziellen Web Accessibility Initiative (WAI) folgen und zur Chrome-Hilfeseite springen, wird dies perfekt deutlich.
Aus Chrome-Hilfe
Mit diesem Wissen und einiger persönlicher Erfahrung bei der Verbesserung einer Website aus Gründen der Barrierefreiheit (einschließlich Optimierungen für das am häufigsten verwendete Screenreader) denke ich, dass es sich lohnt zu wissen, dass die Nutzung der Internet Explorer-Reihe, meist beginnend mit IE8, nicht unüblich ist. Mit Funktionen wie spezifischeren Einstellungen zum Ignorieren von Schriftstilen und nahtloser Interaktion mit Screenreadern ist die Arbeit damit sehr einfach.
Niemand hat wirklich mit einem Grund geantwortet, warum man keinen Schriftprozentsatz auf der Root setzen sollte. In meinen begrenzten Tests wird die Schriftgrößenpräferenz des Benutzers bei einem solchen Setup immer noch die Gesamtskala des Textes anpassen.
Etwas wie dies ermöglicht es Ihnen, mit
rem-Einheiten auf verständliche Weise zu arbeiten, da 1rem im Wesentlichen gleich 10px ist und es ermöglicht, dass sich alles schön an die Schriftgrößenpräferenz des Benutzers anpasst, z. B..container { padding: 2rem; }anstelle von.container { padding: 20px; }@Shaw die Verwendung von
font-size:62,5%auf html war eine interessante Idee bereits 2004, aber Richard Rutter selbst änderte seine Meinung 2007 und verwendetefont-size:100%, auch wenn es schwieriger schien (ist es mit Preprozessoren nicht mehr).Wie ich es sehe, kann die Verwendung von
font-size:62,5%dazu führen, dass einige Elemente auf Ihren Seiten eine10pxSchriftgröße verwenden, weil Sie vergessen haben, einen höheren Wert festzulegen, oder es sich um Inhalte von Drittanbietern handelt, die Sie nicht kontrollieren können. Die Verwendung vonfont-size:100%oder – noch besser – gar nichts, ist meiner Meinung nach sicherer.@nhoizey Das Vergessen, einen höheren Wert festzulegen, ist kein wirkliches Problem, wenn Sie die gewünschte
font-sizeimbodyfestlegen, wie in meinem Beispiel. Alles sollte zumindest die Basisgröße desbodyfolgen, es sei denn, es wird irgendwie zurückgesetzt, aber ich vermeide es, unbekanntes CSS in meine Seiten einzubauen.Die von Ihnen gesendeten Links beziehen sich überhaupt nicht auf die Verwendung von
rem-Einheiten, da diese 2004/2007 noch nicht wirklich existierten. Die Verwendung des Schriftprozentsatzes auf HTML war aufgrund der Varianz vonem-Einheiten etwas hacky, aber mitremist es extrem einfach, zuverlässiges Padding & Margins relativ zur Schriftgrößeneinstellung des Benutzers vorzunehmen.Laut den Mozilla Docs zu
rem-Einheiten, "Diese Einheit ist praktisch, um perfekt skalierbare Layouts zu erstellen.", und genau so verwende ich sie. Ich habe keine Probleme mitremgehabt und das Layout & der Text skalieren hervorragend mit den Schrift- und/oder Zoomeinstellungen des Benutzers. Sofern es keine spezifischen Barrierefreiheitsprobleme in bestimmten Browsern gibt, sehe ich keinen Grund, warumrem-Einheiten nicht auf diese Weise verwendet werden sollten.Ich habe diesen Artikel gefunden, der gegen die Verwendung von
remist und behauptet, dasspx-Einheiten skalierbar sind.pxskalieren jedoch nicht mit der Schriftgrößeneinstellung des Benutzers, obwohl sie sich beim Zoomen ändern.Wie handhaben Sie aus Neugier skalierbare Layouts, die Benutzer-
Schriftgröße- und Zoomänderungen sowie mobile Geräte unterstützen?Konnte jemals jemand die Schriftgröße einer gesamten Webseite erhöhen, ohne durch die gesamte CSS-Datei gehen und viele kleine Teile neu machen zu müssen?
So entscheiden Sie zum Beispiel, dass Sie einen 16px Body anstelle eines 14px benötigen, aber dann stellen Sie fest, dass einige Menügrößen wirklich bei 14px bleiben sollten und Fußnoten von ~12px auf 14px gehen sollten, nicht 13,7px. Es ist immer ein Entdeckungsprozess, bei dem man feststellt, dass einige Dinge proportional skaliert wurden, obwohl sie es nicht mussten, und einige Dinge nicht gut skalieren.
Es war schon immer ein schöner Traum, eine Website radikal durch eine einzige Zeile CSS und viel proportionale Skalierung zu verändern, aber nachdem ich jahrelang nie gesehen habe, dass es gelingt, beginne ich zu denken, dass es ein Hirngespinst ist.
Mein eigenes Ziel beim Schreiben von CSS ist es nicht, die gesamte Gestaltung mit einer einzigen Variable ändern zu können, sondern es einfach zu machen, zu sehen, wo alle Änderungen sind, wenn ich eine radikale Änderung vornehme. Es ist einfach nur wartbares, debugbares CSS.
Website-weite flexible Schriftgrößen sind ein GROSSARTIGES Beispiel dafür, wo die Praktikabilität die Möglichkeit überschattet. Sicher, es mag möglich sein, ultimativ flexibel zu sein, aber für die meisten Websites gibt es einfach zu viele Variablen.
Ich möchte aber eines sagen: Sich zu zwingen, weniger Variablen zu haben, ist nie schlecht. Es kann Ihnen helfen, Ihr Design auf etwas Einfacheres und Verdaulicheres zu konzentrieren, also ist vielleicht das *Streben* nach flexiblen globalen Schriftgrößen keine schlechte Sache.
Ich stimme Ihnen vollkommen zu, wenn ich an kommerziellen Produkten arbeite, habe ich nie nur ein paar Schriftgrößen und einige Größen müssen je nachdem, wo sie sich befinden, unterschiedlich verhalten. Da jede CSS-Größeneigenschaft Auswirkungen auf Ihr Layout hat, wird sie auf Buttons, in einer Spalte oder in einem bestimmten Layout/Container funktionieren? Das ist schwer zu sagen, wir müssen all diese Szenarien plus Media-Queries bedenken. Ich denke, REM kann gut bei einfachen Layouts wie einer Artikelseite oder einem einfachen Blog funktionieren.
Ich stimme dem obigen Kommentar zu, obwohl es oft als Beispiel verwendet wird – Ich glaube nicht, dass das Ändern einer Zahl, um das gesamte Dokument zu beeinflussen, ein sehr realistisches Beispiel ist. Ich bleibe bei ems für Einheiten, die sich auf Typografie, Button-Padding, Absatz- und Überschriften-Margins usw. beziehen sollten, aber ich verwende es lieber nicht für Schriftgrößen. Außerdem verwenden wir Inline-Blocks für unsere Grid-Layouts, die auf font-size: 0 angewiesen sind (ja, wir könnten das vermeiden, indem wir seltsame Dinge im HTML tun, aber es ist weniger praktikabel) und daher wird die em-Kaskade zerstört. Ich kann sehen, wie das Setzen einer Schriftgröße in Rem auf dem Block (BEM-Block, nicht display: block) und dann alle Kinder/Elemente in Em's alles modular halten würden.
Nein, bitte!
Baseline-Gitter. Ich verwende EMs für Dinge wie meine Schriftgröße oder Größen, die das Baseline-Gitter nicht beeinflussen, sodass es abgegrenzt ist, aber wenn es um vertikale Abstände geht (z. B. Zeilenhöhe, Rand), verwende ich im Allgemeinen REMs, es sei denn, ich betrachte es nicht als Teil des Baseline-Gitters (z. B. das Menü).
Warum sollten Sie eine Einheit für Zeilenhöhe/Rand verwenden, die nicht mit dem Inhalt zusammenhängt? Sicherlich wäre eine Zeilenhöhe von 1,3 weitaus passender/vielseitiger als eine magische Zahl :/.
Das ist eine interessante Lektüre, Rob. Es ist schön, einige Diskussionen zu diesem Thema zu sehen.
Ich habe selbst einige Experimente mit der Mischung von Ems und Rems durchgeführt. Ich bin mir jedoch nicht sicher, ob die "Komplexität", die sie hinzufügt, die Mühe wert ist. Mit "Komplexität" meine ich Schwierigkeit, Einheiten zu verstehen und wie sie darauf reagieren, wo sie sich befinden. Sie müssen sich immer des Kontexts bewusst sein, um diese Technik voll nutzen zu können.
Theoretisch sollte der Fluss/Rhythmus des Dokuments einer unkomplizierten Größenskala folgen und das sollte in den meisten Fällen ausreichen.
Der große Vorteil der schriftgrößenbasierten Skalierung ist die Nutzung einer Barrierefreiheitsfunktion (die Benutzereingaben berücksichtigt – den Zoom) im Gegensatz zu willkürlichen Pixelwerten. Das Ändern des Dokumentflusses durch Festlegen einer sehr kleinen Schriftgröße für eine Komponente kann zu vielen Lesbarkeitsproblemen führen (im DOM, wörtlich eine Kaskade von Problemen), was meiner Meinung nach ein Dealbreaker ist.
Es scheint so viele widersprüchliche Theorien zu geben, wie ein HTML-Dokument eingerichtet werden soll. Einige befürworten die Verwendung von px, andere Prozente und wieder andere rems und ems oder Kombinationen aus allem.
Persönlich möchte ich glauben, dass das Einrichten von :root oder html auf 100 % und dann die Verwendung von rems der ideale Weg für mehr Kontrolle über Layout und Verschachtelung wäre und auch mobilfreundlich ist.
Warum auf
100 %setzen, anstatt einfach die Standardeinstellung ohne etwas im CSS verwenden zu lassen?Was hältst du davon
Ist es schlechte Praxis, rem für alles zu verwenden (mit px-Fallback)?
Ich verwende es sogar für Container, Paddings, Margins, ...
Aus Styling-Sicht unterscheidet sich die Verwendung von rems nicht von Pixeln (der Browser berechnet immer noch einen px-Wert), der Hauptunterschied ist, dass Sie die relative Skalierung verlieren. Zum Beispiel haben Sie vielleicht einen Titel mit einer Schriftgröße von 30px und einem margin-bottom von 30px und einen weiteren Titel mit einer Schriftgröße von 20px – es ist unwahrscheinlich, dass Sie möchten, dass der margin-bottom ebenfalls 30px beträgt (da der Abstand normalerweise relativ zur Größe ist, daher ein Einheiten-loser Zeilenabstand). Stattdessen könnte margin-bottom 1em besser sein, da es eine relative Einheit ist.
Ein kurzes Beispiel für ems und rems in der realen Welt
http://codepen.io/basement31/pen/JXbJYx
Das Padding des Buttons ist relativ zur Schriftgröße eingestellt, was bedeutet, dass Sie nur einen Wert ändern müssen und die Buttons konsistent bleiben.
Vergessen Sie auch nicht em's für Media Queries
http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/
Schauen Sie sich die Notiz am Anfang dieses Artikels an.
Dies ist eines meiner Lieblingsbeispiele für ein Konzept, das im GlobalDeveloperConsciousness™ stecken bleibt.
@Chris Ich glaube, Lyza hat Recht, wenn sie sagt, dass "das Zoomverhalten ... konsistent gemacht wurde", aber das bedeutet nicht, dass Benutzer, die ihre Standard-Schriftgröße ändern, nicht mehr berücksichtigt werden sollten ... Dies sind zwei verschiedene Themen, die beide
em-basierte MQs erfordern.Es wäre schön gewesen, einen vollständigen Artikel zu diesem Thema (Typografie und Einheiten) zu haben, da in diesem nichts wirklich Neues ist.
Ich habe kürzlich eine Reihe von Beiträgen dazu gelesen (geschrieben von Zell Liew) und wusste bereits ein wenig über modulare Skalierung, "responsive" viewport-basierte Schriftgröße, vertikale Rhythmen usw. Dies veranlasste mich, mehr darüber zu erfahren, und ich war ein wenig enttäuscht, nichts Synthetisches auf CSS-Tricks zu finden (bitte nehmen Sie das als Kompliment, denn es ist zu 99 % eine Goldgrube).
Ich frage mich auch, was der Unterschied ist, ob man die globale Schriftgröße auf :root anstelle von html oder sogar body setzt. Ich vermeide es, die globale Schriftgröße für die meisten meiner Projekte überhaupt zu ändern, daher ist es für mich kein wirkliches Problem, aber ich sehe, dass es eines gibt, indem ich es mit Pixeln für Benutzer korrigiere, die eine Schriftgröße in ihrem Browser einstellen. Okay, es sollte nicht so viele Leute geben, die das tun, aber wir müssen davon ausgehen, dass sie es aus gutem Grund getan haben, den wir mit einer Einheit, die (zumindest) nicht relativ ist, völlig ignorieren.
Ich bin nicht von der Idee überzeugt, die Schriftgröße von Modulen in rem zu setzen. Warum nicht in em lassen, daher verknüpft mit einer Root-Schriftgröße? Stellen Sie sich vor, wir verwenden BEM und setzen für jeden Block eine Schriftgröße in rem. Ein Button wäre ein Block. Ein sekundärer Block mit einer kleineren Schriftgröße als die Root-Schriftgröße und der diesen Button enthält, würde ihn zu groß darstellen.
Bezüglich des responsiven Änderns der Schriftgröße mit einer einzigen Deklaration schrieb Mike Rithmuller Mike Rithmuller vor einem Jahr über eine Methode für responsive Typografie basierend auf der Viewport-Breite, mit Min/Max-Werten in Pixeln (eventuell unterschiedlich für mehrere Viewports). Es ist nicht ideal, da wir nicht immer die Schriftgröße reduzieren/erhöhen müssen, um responsiv zu sein, sondern stattdessen das Layout ändern möchten.
sehr gut
Betreff: { font-size: 62,5% }
Kurz: Sparen Sie sich einige Probleme, setzen Sie einfach die Root auf px.
Lang: Ich hatte gerade einen Anruf von einem Designer, der sich wunderte, warum sein Design total verunstaltet ist ... weil sein Browser auf 10px eingestellt war. Ich habe diese Seite gefunden, als ich nach Warum CSS Rem verwenden suchte, und einige Seiten als Referenz überprüft.
Browser-Einstellungen scheinen eine vergessene Funktion zu sein und deren Berücksichtigung ebenfalls. Zoomen funktioniert gut mit absoluten Werten auf der Root, es ignoriert nur, dass wir die Einstellungen *beachten* könnten.