Ich, seit etwa einem Jahr: "rem sind so cool! Ich werde alles damit skalieren, damit ich die Schriftgröße am Root-Element anpassen kann und alles mitskaliert!" Es war ein schöner Traum. Und es war keine Katastrophe. Das ist es, was ich hier auf CSS-Tricks gerade mache und so spielt es sich in einem sehr einfachen Szenario ab

Das kommt im Wesentlichen von
/* Document level adjustments */
html {
font-size: 17px;
}
@media (max-width: 900px) {
html { font-size: 15px; }
}
@media (max-width: 400px) {
html { font-size: 13px; }
}
/* Type will scale with document */
h1 {
font-size: 3rem;
}
h2 {
font-size: 2.5rem;
}
h3 {
font-size: 2rem;
}
Ich gebe zu, ich mag diese Einfachheit, aber ich fange an zu denken, dass sie für alle außer den einfachsten Websites ein wenig zu träumerisch ist. Das Hauptproblem: Man kann nicht erwarten, dass Typografie, die man bei einer Bildschirmgröße festlegt, durch einfaches proportionales Skalieren einfach richtig aussieht. Große Typografie könnte beim Hochskalieren zu groß werden. Kleine Typografie könnte zu klein werden (ein häufiges Problem, das mich erwischt). Oder sogar das Gegenteil von beidem, wobei große Typografie nicht *klein genug* werden könnte.
Wenn eines dieser Dinge passiert, dann nimmt man @media query-spezifische Anpassungen vor, was nicht nur verwirrend wird, sondern auch nicht sehr effizient ist (Größe ändern, nur um sie dann wieder zu ändern, um sie zu korrigieren).
Hier ist also meine Idee: Man behält px-Größenanpassungen auf Dokumentenebene bei, um einfache/effiziente umfangreiche Größenänderungen vornehmen zu können. Aber dann hat jedes Modul auf der Seite eine Schriftgröße, die in rem festgelegt ist. Tatsächliche Textelemente (h1, h2, p, li, was auch immer), wenn man sie überhaupt skaliert, werden in em skaliert und werden somit relativ zum Modul.
Auf diese Weise kann man die Schriftgröße auf Modulebene anpassen, was ziemlich einfach ist. Die Wahrscheinlichkeit, dass die Typografie innerhalb eines einzelnen Moduls gute Proportionen hat und schön zusammen skaliert werden kann, ist hoch. Das würde sich dann so auswirken
Man kann hier mit den Schiebereglern mit der Idee herumspielen
Siehe den Stift Em UND Rem von Chris Coyier (@chriscoyier) auf CodePen.
Bei einer bestimmten mittleren Größe sieht alles gut aus. Beim Hochskalieren kann man zu einem Punkt gelangen, an dem die Hauptartikel eine gute große Größe haben, aber die Seitenleisten nicht so groß sein müssen. Mit diesem System wäre es einfach, sie anzusprechen und wieder nach unten zu regeln. Beim Herunterskalieren werden diese Seitenleistenmodule zu schnell zu klein, daher könnte man sie leicht wieder nach oben regeln. Es könnte sogar Größen geben, bei denen man die Dinge angleicht, weil man zu einer einzelnen Spalte übergegangen ist (oder Ähnliches).
So würde es ablaufen
/* Document level adjustments */
html {
font-size: 17px;
}
@media (max-width: 900px) {
html { font-size: 15px; }
}
@media (max-width: 400px) {
html { font-size: 13px; }
}
/* Modules will scale with document */
.header {
font-size: 1.5rem;
}
.footer {
font-size: 0.75rem;
}
.sidebar {
font-size: 0.85rem;
}
/* Type will scale with modules */
h1 {
font-size: 3em;
}
h2 {
font-size: 2.5em;
}
h3 {
font-size: 2em;
}
Ich habe "Idee" in den Titel gesetzt, weil ich noch keine Website so gebaut habe, aber es ergibt für mich Sinn und ich würde es auf jeden Fall ausprobieren.
Hm… guter Plan. Ich benutze eigentlich nur em und Prozent – keine Pixel (es sei denn, Ränder sind beteiligt) und keine rem. Das klingt besser.
Es ist definitiv erwähnenswert, die Browserunterstützung für rem. Wenn Sie IE8 und darunter unterstützen müssen, kann diese Idee nicht einmal in Betracht gezogen werden.
Es kann mit px-Fallback für rem erreicht werden. Sie müssten nur die rem/px-Fallbacks für Module in Ihre @media-Deklarationen einbeziehen.
Hinterlassen Sie sich eine kleine Notiz, dass sie entfernt werden können, wenn IE8 nicht mehr unterstützt werden muss, und Sie können dies heute nutzen.
Glücklicherweise ist XP heute gestorben
@Legomushroom Das bedeutet nichts, wir müssen diese Benutzer immer noch unterstützen.
Sicher, aber das wird sich bald ändern
Hören wir einfach auf, IE8 zu unterstützen, ja? Es ist 2014.
Ja, wir können sicherlich alle aufhören, IE8 zu benutzen, aber viel zu viele andere Leute werden ihn einfach weiter benutzen. Wenn Sie Windows 7 installieren, nicht einmal XP, erhalten Sie eine Standardversion von IE 8 oder sogar IE 7, je nach Installation. Noch nicht aus dem Schneider :)
Ich arbeite für ein Unternehmen, dessen Kunden große Personalvermittlungsfirmen sind, die wiederum auf große IT-Abteilungen angewiesen sind, um ihren gesamten technischen Support zu erledigen. Wenn man in Umgebungen dieser Größenordnung gerät, ist die Aktualisierung extrem schwierig, zeitaufwendig und vor allem kostspielig. Infolgedessen haben wir IE8 bis letzten Monat unterstützt.
Einige Regierungsbehörden verwenden immer noch IE6. Denken Sie nur daran.
Übrigens hat die britische Regierung gerade 5,5 Millionen Pfund für erweiterte Unterstützung für XP ausgegeben
http://ccs.cabinetoffice.gov.uk/i-am-buyer/categories/ict/special-agreements/custom-support
Zielen Sie auf Funktionen, nicht auf Browser. Alles kann mit korrekten Fallbacks berücksichtigt werden. Verkaufen Sie sich nicht unter Ihren Möglichkeiten. Planen Sie für die Zukunft und behalten Sie die Vergangenheit im Auge.
Hmm. Das klingt ziemlich vielversprechend, ich kämpfe mit demselben Problem.
Das Problem, auf das ich tendiere, ist, dass, wie Sie sagten, die große Schrift nicht *klein genug* wird, wenn man die Skalierung reduziert – und ich bin mir nicht sicher, ob das das lösen würde. Obwohl ich denke, ich bin nur faul und eine einfache MQ-Anpassung für Überschriften würde das Verhältnis ändern.
In meinen Träumen ist alles so einfach wie das Ändern einer Zahl.
Diese Idee gefällt mir sehr gut. Jeder, der mit modularen "Widgets" gearbeitet hat, sollte den Vorteil erkennen.
Fügen Sie die Möglichkeit hinzu, Module in Kontexten (Seitenleiste, Hauptinhalt) unterschiedlich zu gestalten, und dies reduziert den Bedarf an dupliziertem CSS erheblich.
Danke, Chris! Ich freue mich darauf, einen ähnlichen Ansatz zu adaptieren.
Ich werde es bei meiner nächsten vollständigen Website sicher ausprobieren. Dieser Kunde ist ein Schrift-Snob, wie er selbst zugibt, also ist er das perfekte Versuchskaninchen.
Das Setzen Ihrer Schriftgröße auf Dokumentenebene mit einer absoluten Einheit überschreibt die Browsereinstellungen des Benutzers, daher ist es sicher zu sagen, dass dies eine **schlechte Praxis** ist.
Verwenden Sie stattdessen eine relative Einheit, wie folgt:
html { font-size: 100%; }.Ich stimme Tim zu, lassen Sie das html in Ruhe. Hier ist die Quelle dafür: http://filamentgroup.com/lab/how_we_learned_to_leave_body_font_size_alone/
Außerdem erwähnen sie (und verlinken), warum man EMs für Media Queries verwenden sollte: http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/
Der größte Faktor war, dass px-Media-Queries beim Zoomen des Browsers nicht funktionierten, EMs jedoch schon, was heute nicht mehr zutrifft. Ich habe aus diesem Grund alle meine Media Queries auf EMs umgestellt, was in Ordnung ist, aber im Allgemeinen bin ich mit px dort wohler.
Chris, es dauert ein wenig, bis man aufhört, px zu verwenden. Es ist ein Wechsel von der gesamten pixelbasierten Gestaltung zur gesamten Gestaltung relativ zur Basisschriftgröße.
Es ist ein Wechsel von absolut zu proportional. Derselbe Wechsel wie von Photoshop zu Illustrator.
+1, hören Sie auf, Pixel zu verwenden, es ist schlecht :)
Es kann auch Zugänglichkeitsprobleme für alte IEs haben, aber das Hauptproblem ist – wie Tim sagt – dass es die Standardwerte des Benutzers überschreibt. Respektieren Sie den Benutzer, verwenden Sie Prozente oder verwenden Sie gar nichts :)
@Nico
Wer sind diese Benutzer, die Standard-Schriftwerte ändern?
Ich kenne ein paar gesetzlich Blinde. Einer vergrößert seinen gesamten Bildschirm (OS X Strg + Mausrad). Alle anderen verwenden Strg-+ zum Zoomen, nicht nur Schriftarten.
Hat jemand tatsächliche Statistiken dazu?
Verwenden Sie % am Root – dasselbe Konzept.
Wenn es dasselbe Konzept ist, bewerben Sie nicht die Verwendung einer absoluten Einheit, wie Pixel, am Root-Element.
Im Grunde raten Sie den Entwicklern, Leute mit schlechter Sehkraft zu verärgern, die die Zoom-Option nicht gefunden haben.
Wenn Sie es nicht ändern wollen, erwähnen Sie zumindest die Vorteile von Prozenten im Artikel. Bitte.
Ich stimme hier nicht zu. Ja, es ist offensichtlich schön, die Einstellungen des Benutzers zu berücksichtigen. Aber die richtige Antwort ist viel komplexer. Warum? Nun, weil
Man kann davon ausgehen, dass Benutzer ihre Textgrößen erhöhen, um 10px Body-Text lesen zu können. Aber es ist unmöglich zu sagen, ob der Benutzer die erhöhte Textgröße tatsächlich wünscht, wenn Ihre Website auf 20px eingestellt ist.
Diese Idee gefällt mir sehr gut. Ich denke, da die Browserunterstützung etwas breiter wird, wird dies der Weg sein. Danke für die Einblicke.
Sobald rem verfügbar ist, halte ich es für falsch, px für etwas anderes als Ränder oder Trennlinien zu verwenden. Es sollte nicht mehr für Schriftarten verwendet werden. Meine Begründung
Rem ermöglicht die gleichzeitige Handhabung von: Browser-Zoom UND Benutzereinstellungen für Schriftgröße.
– Mit Zoom wollen wir alles größer machen.
– Mit der Änderung der Schriftgröße wollen wir nur die Schriftarten größer machen.
Nur die Schriftarten größer zu machen bedeutet, dass das Layout nicht größer oder kleiner wird.
Wenn die Einstellung der Schriftgröße geändert wird, ändern sich alle "em"-skalierten Elemente, aber nicht die rems.
Daraus ergibt sich meine folgende Basisstrategie
– em für Schriftarten und alles, was sich auf Schriftarten bezieht.
– rem für Breiten. Alle Dinge, die sich nicht ändern sollten, wenn die Schriftgröße des Benutzers geändert wird. Also im Allgemeinen die Layout-Breite, die Spalten- und Blockbreiten. Im Allgemeinen wollen wir, dass der Container nach unten expandiert, aber nicht größer wird.
-px fast verbannt und nur für Ränder verwendet, da wir dafür in der Regel runde Zahlen wollen.
Super einfache Strategie und funktioniert gut für mich in IE9+-Browsern.
Außerdem öffnet es die Türen für die programmatische Manipulation der Schriftgröße.
Ja, genau!
Das mache ich schon seit etwa 3 Jahren so, außer dass ich ems nur verwendet habe, wenn rem nicht verfügbar war. Ränder, Textschatten und im Allgemeinen alles, was 1,2 in px ist, und abgerundete Ecken in px ebenfalls. Nun, man könnte em bei abgerundeten Ecken verwenden, aber es ist besser, es nicht zu tun.
Ich habe in letzter Zeit über dasselbe nachgedacht!
Die Verwendung von rems für alles schien eine geniale Idee zu sein, bis ich anfing, sie bei großen Websites zu verwenden. Mit ems konnte ich nur den übergeordneten Container eines Moduls anpassen und die restlichen Blöcke würden sich entsprechend anpassen. Aber mit rems muss ich rems für jedes verschachtelte Objekt überschreiben. Und das überwindet im Grunde alle Vorteile von rems.
Ich werde diesen neuen Ansatz auf jeden Fall bei meinem nächsten Projekt ausprobieren, weil er alles kombiniert, was ich an rems mag (abhängig nur von der Schriftgröße des Roots) und ems (es skaliert einfacher).
Interessante Idee – ich habe bisher auf die Verwendung von rems verzichtet und stattdessen Prozente und ems bevorzugt. Ich mag das Konzept davon, und ich denke, ich werde es bei meiner nächsten Website ausprobieren.
Danke Chris!
Großartige Idee. Ich bin auf die Verwendung von
rems für die gesamte Schriftgröße und Abstände umgestiegen, hatte aber Schwierigkeiten mit der Skalierbarkeit. Durch die Einstellung der tatsächlichenfont-sizemitemkann der Container / das Modul die Größe wirklich bestimmen, während der Abstand mitrems konstant bleibt. A+ Idee.Das ist wirklich großartig! Jetzt muss ich es ausprobieren. Danke Chris!
Ich habe diese Methode auf der aktuellen Website, an der ich arbeite, ausprobiert und bin auf ein paar kleine Probleme mit meinem aktuellen Setup gestoßen. Wenn ich LESS verwende, habe ich mehrere Hauptvariablen für die Schriftgröße.
Das Setzen von 1rem gleich 10px ermöglicht einfache Berechnungen für Schriftgröße oder Abstände (Methode basierend auf The Golden Ratio and REMS)
Als ich jedoch auf die Verwendung von
emfürfont-sizeundremfürmargin/paddingumstieg, gab es ein paar notwendige Anpassungen.Dies ermöglicht es mir, auf eine feste Größe mit der Variablen
@font-size-bodyzurückzufallen, wie bei der Verwendung eines Inline-Block-Grids und font-size: 0.1px zum Entfernen von Abständen, während die Skalierung der Schriftgröße für Module oder Media-Queries immer noch einfach ist.Nur neugierig: warum
html {17px}statt z.B.16px?Ich bin nicht besonders begeistert davon, die Standard-Schriftgröße der Browsereinstellungen des Benutzers zu überschreiben. Ich stelle mir vor, die meisten Benutzer berühren diese Einstellung nicht einmal. Daher ist es am besten, sie als
font-size: 100%zu belassen.Die Idee,
px,remundemzusammen für die Schriftgrößenfestlegung zu verwenden, mag für Anfänger etwas überwältigend sein. Daher verwende ich als Alternative nurems, um die Schriftgröße(n) festzulegen, was bedeutet, dass wir den Text durch einfaches Ändern derfont-sizedeshtml-Elements ändern können.Hier ist, wie es gemacht wird,
Das war's! Durch einfaches Ändern der
font-sizein%für dashtml-Element können wir den Text basierend auf den Media-Queries hoch-/herunterskalieren.Was ist mit vertikalem Rhythmus und Tools wie Compass? Ich benutze Compass heutzutage eigentlich nur noch dafür (Gulp für Präfixe). Wie macht man es nutzbar?
Bezüglich des Redesigns von CSS-Tricks, warum verkleinern Sie Ihre Schriftgrößen für kleine/mobile Bildschirme? Macht es nicht Sinn, sie größer/leserlicher zu machen?
Ich habe zunächst dasselbe gedacht, aber das berücksichtigt nicht die Tatsache, dass mobile Geräte normalerweise viel näher am Benutzer sind als traditionelle Computer. http://ia.net/blog/responsive-typography-the-basics/
Gute Idee. Ich denke, Sie müssen auch vertikale Abstände wie Margen und Paddings berücksichtigen. Die Vergrößerung der Schriftgröße der Module ohne die Verwendung von 'em' für diese Eigenschaften könnte zu interessanten Ergebnissen führen.
Bisher habe ich % zum Hoch- oder Herunterskalieren der Schriftgröße verwendet. Dieser Ansatz scheint interessant. Werde es ausprobieren.
In Nimmerland wird EM oder REM für alles verwendet!
Für den EM-Fall halte ich es für eine schlechte Idee, die font-size auf den Elternteil des Textelements anzuwenden.
Eines Tages sollten wir über vollständiges EM/REM-Design nachdenken.
1) Nehmen Sie niemals die Kontrolle über die Schriftgröße vom Benutzer. Viele Menschen mit Behinderungen stellen ihre eigene Basisschriftgröße im UA ein.
2) Das gesagt, Designer nehmen die Kontrolle seit Ewigkeiten vom Benutzer weg. Trotzdem ist es nie zu spät, jetzt anzufangen.
3) Ich habe die Notwendigkeit für REMs nie verstanden. Was Sie hier vorschlagen, kann genauso gut mit EMs gemacht werden
rem macht nach meinem Verständnis nur die Mathematik einfacher. Ein Rem basiert immer auf der HTML-Größe, wenn ich mich richtig erinnere, also egal wie viele Elemente verschachtelt sind, es verhält sich gleich und vorhersehbar. Betrachten Sie es als die Deklaration eines Geltungsbereichs, auf dem em seine Mathematik basiert. Wo hingegen das Verschachteln von em unüberschaubare Konsequenzen haben kann, je mehr Elemente verschachtelt werden.
In einfachen Websites ein relatives Nicht-Problem, aber in einigen der komplizierteren, die von vielen Leuten verwaltet werden, wird em zu einem echten Schmerz.
Rem wird nicht von der Änderung der Benutzerschriftgrößeneinstellung beeinflusst. (und es gibt keine Kumulierung)
Das ist der Grund, warum ich dringend empfehle, es für alle Breiten zu verwenden. Dann kann der Benutzer eine größere Schriftgröße anfordern, ohne dass die Website größer wird. So größere Schrift, aber keine horizontalen Scrollbalken.
@olivvv: vielleicht missverstehe ich Sie, aber
rems werden von Änderungen der Benutzerschriftgrößeneinstellung beeinflusst, genau wieems. Deshalb sind sie nützlich. Der Benutzer kann seine Schriftgröße ändern und die Elemente werden entsprechend skaliert. So haben Sie keine Spalten, die zu schmal oder zu breit sind, wie Sie es mitpx-basierten Layouts hätten.Das Eine wichtige Sache bei
rem-basierten Layouts ist, immer auchrem- oderem-basierte Media Queries zu verwenden. Forrest Galloway hat Informationen dazu in einem Kommentar unten – wenn ein Benutzer seine Schriftgröße (oder Zoom-Einstellung) hochskaliert, erhält er die Tablet-Version, dann die mobile Version, was wahrscheinlich sowieso eine bessere Benutzererfahrung ist.Ein *leicht* abweichendes Thema, aber wenn Sie Schriftgrößen hoch und runter skalieren, möchten Sie vielleicht auch mit dem Buchstabenabstand experimentieren.
Große Typografie kann – und tut es oft – schöner aussehen mit etwas weniger Abstand zwischen den Buchstaben. Es kann auch die Lesbarkeit verbessern.
Verwenden Sie relative Einheiten für gute Ergebnisse, gehen Sie subpixel-crazy für großartige Ergebnisse.
Amazeballs! Liebe es.
Wir haben eine ähnliche Technik wie in diesem Artikel für das jüngste Redesign von http://www.nationalguard.com verwendet. Wir haben einige PX-Deklarationen, aber hauptsächlich EMs, sie eignen sich hervorragend für Module und Layouts (zum Herunterskalieren der genannten Module)! Um die Website responsiv zu machen, haben wir die Standalone-Version von fittext verwendet und sie an das html-Element allein angehängt. Die Schriftgrößen haben sich wunderschön kaskadiert.
Wenn JS ausgeschaltet ist, verwenden Sie eine PX-basierte Schriftgröße für das html-Element und eine feste Breite für body. Es ist möglich, das Verhalten von Fittext mit einem Sass-Mixin und MQs zu imitieren, ich bin mir nicht sicher, ob es ratsam wäre, es wären viele Zeilen CSS.
Es hat einen interessanten Vorteil/Nebeneffekt für die Barrierefreiheit: Wenn man die Schriftgröße im Browser erhöht, wird schließlich die mobile Erfahrung mit großen Texten angezeigt, was unserer Meinung nach eine bessere Erfahrung ist als nur ein aufgeblähter Desktop.
Ich stimme der Änderung des Routen-Em-Größenwechsels bei Breakpoints zu, aber ich sehe immer noch keinen wirklichen Vorteil darin, Komponenten in ems oder rems zu skalieren, für mich ist es
Rems für Text
Ems für Dinge, die eine Beziehung zu diesem Rem haben (z.B. Padding an einem Button sollte relativ zur Textgröße des Buttons sein) auch ems für Margins bei textbasierten Dingen
% für das Layout
% oder PX für Rinnen/Margins bei Layout-Elementen – Rinnen zwischen Spalten zum Beispiel haben keine Beziehung zur Größe eines
<
p>
Hier ist eine Methode, die ich auf meiner Website verwende
Setzen Sie eine Basiseinheit für die Ansichtsfenstereinheit (vw) für :root, ändern Sie dann alle anderen Größen per Prozent, hier ein Beispiel
https://github.com/sparanoid/sparanoid.com/blob/master/_app/assets/less/app.less#L2
Hallo Chris – Ich liebe den engen modularen Ansatz, aber es gibt ein paar Dinge, die meiner Meinung nach wirklich wichtig sind zu berücksichtigen
1) EMs für Media-Queries funktionieren zuverlässiger, da einige Browser-/Hardwarekombinationen (ein Samsung Touchscreen-Laptop ist einer, von dem ich gehört habe) beginnen, die tatsächliche Auflösung ihrer hochauflösenden Bildschirme zu melden – und em-basierte Layouts funktionieren hervorragend, aber px-basierte erscheinen plötzlich so groß wie eine Briefmarke. Ich denke, das wird mit der Zeit immer häufiger vorkommen, daher könnte es angesichts des ziemlich einfachen Wechsels zwischen den beiden sinnvoll sein, auch bei MQs bei EMs zu bleiben.
2) Filament Group hat Recht damit, bei 1EM für Body-Text zu bleiben. Sie (Geräte-/Betriebssystemhersteller) stecken viel Aufwand in die Bestimmung einer guten lesbaren Größe auf ihrem jeweiligen Gerät, und wenn Sie es bei 1EM belassen, wird es immer funktionieren.
3) Urteile über relative Größen in Modulen überall können dazu führen, dass die Design-Erfahrung wirklich fragmentiert wird. Wenn die relative Größe sehr unterschiedlich ist, verlangsamt dies die Wahrnehmung der Benutzer darüber, welches Element wichtiger ist als ein anderes, da diese Hierarchie nicht aufrechterhalten wird.
Es ist nicht so, dass der modulare Code-Ansatz nicht wirklich klug ist – aber ich denke, es ist wirklich wichtig, das gesamte Design und seinen Zusammenhalt zu berücksichtigen, anstatt sich auf die Feinabstimmung jedes Moduls zu konzentrieren. Natürlich würde ich diesen Ansatz aus Coding-Sicht völlig wählen, um alle Module von CSS portabler und "SMACSSy" zu machen – aber als Designer würde ich einfach überlegen wollen, wie viel geändert wird und wo.
Okay. Noch eine Sache zu REMs vs. EMs. Ich habe REMs nie übernommen, teilweise wegen IE8- (und dem gesamten Beispielcode, den ich für meine RWD-Workshops verwende, ist responsiv bis IE6), aber die Notwendigkeit von REMs ist viel geringer, wenn man einfach darauf achtet, keine Schriftgrößenänderungen auf Container anzuwenden – nur auf die Elemente selbst. Auf diese Weise berechnet man immer auf der Basis-HTML-Schriftgröße – und man könnte viel von derselben Gesamtflexibilität erreichen, um die Basis zu ändern und sie durchlaufen zu lassen.
Wir haben tatsächlich ein ähnliches System in einem großen responsiven Projekt im Einsatz. Erstens haben wir alle UI-Komponenten auf der Seite streng modularisiert mit BEM-Klassenbenennung. Dann haben wir zwischen Modulen unterschieden, die Seitenbereichen entsprechen, und kleineren Modulen. Seitenbereiche durften ihre Schriftgröße mit REM überschreiben. Kleinere Module (wie Buttons, Formularelemente, Überschriften usw.) werden immer mit EMs skaliert. So konnten wir die kleinen Module auch in verschiedenen Größen sehr flexibel einsetzen. Die Skalierung wird über die Seitenbereichsmodule durch ihre REM-Basisschriftgröße gesteuert.
Das Endergebnis war ein hochflexibles und modulares UI-Komponentensystem.
Ich mag
rem-Einheiten, weil sie die Mathematik erleichtern.Warum also nicht die
font-sizedes Root-Elements auf10pxsetzen? So ist1rem=10px,1.2rem=12pxusw.Außerdem dachte ich, dass das Überschreiben der Browsereinstellungen des Benutzers mit
px-Einheiten von der Community missbilligt wird. Hat sich dieser Ethos geändert?Oder, wenn man sich nicht um einfache Mathematik kümmert, warum nicht die
font-sizedes Root-Elements direkt mit einerrem-Einheit setzen und dem Benutzer die Kontrolle überlassen?Ich verwende diesen Prozess mit Atomic Design für die große Enterprise-Anwendung meines Unternehmens. Es ist großartig, weil man eine Sass- oder LESS-Partialdatei für ein Modul definieren kann (in Atomic Design heißen sie *Moleküle* oder *Atome*), die standardmäßig auf font-size: 1rem gesetzt ist, dann auf der Page-Ebene kann ich das mit einer font-size: 1.2rem usw. überschreiben.
So kann ich ein Widget anwendungsübergreifend basierend auf seinem Kontext skalieren.
Die Schriftgröße eines Moduls wird in
remgemessen, ebenso das Seitenraster-Framework. Ich verwende Susy, das rems nativ auf diese Weise verwendet. Sie eignen sich hervorragend für Raster-Frameworks, da Sie sicherstellen möchten, dass Spalten und Abstände auf der gesamten Seite konsistent bleiben, unabhängig davon, in welchem Modul sie sich befinden.Ich möchte die Fragen von thinsoldier wiederholen
„Wer sind diese Benutzer, die Standard-Schriftgrößen ändern?
Gibt es dafür tatsächliche Statistiken?“
Ist es überhaupt möglich, die Standard-Schriftgröße aus dem UA eines Benutzers auszulesen? Wenn ja, gibt es Statistiken und wo sind diese zu finden?
Danke
Was ist Ihre Meinung dazu, die Basisschriftgröße in px und den Rest in Prozent festzulegen?
Ich stimme Ihnen zu :-)
Gefällt mir die Slider-Demo, um die Schriftgröße zu erhöhen
Es ist viel einfacher, Prozente zu verwenden +/- 100 % = Funktioniert überall; auf diese Weise ersparen Sie sich die verflixten rem-Kopfschmerzen! Fangen wir gar nicht erst mit der plattformübergreifenden Kompatibilität an.
Es ist einfach so, Leute...
Typografie in % und em ist dasselbe – es beeinflusst immer noch die Kaskade, da 100 % von 300 % immer noch 300 % sind. Ebenso sind 1em bei 3em immer noch 3em.
Überzeugen Sie sich selbst
http://codepen.io/basement31/pen/oyJFf/
Kleiner Tipp für die CodePen-Demo: Wenn Sie den Callback an das „input“-Ereignis binden, werden die Schriftgrößen aktualisiert, während Sie den Regler nach oben und unten ziehen. Supercool.
Ich verwende eine ähnliche Technik in Kendo UI Mobile seit einiger Zeit. Wir benötigen jedoch, dass Komponenten skalierbar sind und basieren hauptsächlich auf em.
Die Verwendung von em und rem sowie von font-size auf dem Stamm ist auch die einzige Möglichkeit, die fehlende automatische Skalierung 1 in Windows Phone 8 zu simulieren, wo kein devicePixelRatio verfügbar ist (WP8.1 hat devicePixelRatio, aber keine automatische Skalierung).
Ich denke, das ist eine gute Idee, aber ich frage mich nur, warum Sie keine Punkte (pt) für den Text verwenden. Ist das nicht besser für den Druck von Seiten?
Hallo Chris, wir verwenden diese Technik tatsächlich seit zwei Jahren in einem HTML5-Videoplayer. Die Anpassungen der Stammebene erfolgen bei uns mit JS, da der Player auf das Fenster zoomen soll. Wir haben uns entschieden, px für den Stamm und em für alles andere zu verwenden, aber dasselbe hätte natürlich auch mit rems gemacht werden können.
Das Schöne an diesem Projekt war, dass wir uns nicht um ältere Browser kümmern mussten, denen wurde der seltsame alte Schritt-Onkel (Flash) serviert.
Hier ist das Ergebnis: http://www.heliview.de/?uid=Q5ZPL5
Es gibt ein großes Problem mit (r)ems: FF/Chrome/IE/Safari verwenden dazu neigen, ihren eigenen Algorithmus für das Runden von Werten zu verwenden, was zu kleinen, aber sichtbaren Unterschieden in der Berechnung führt, und Sie können keine Mindestwerte für Dinge wie Ränder definieren. Deshalb haben wir uns entschieden, dafür px-Werte zu verwenden... und sind auf das nächste Problem gestoßen, wenn der Benutzer zoomt (nur Desktop). px-Werte werden in modernen Browsern tatsächlich gezoomt.
also... liebe CSS-WG/W3C: Wir lieben, was Sie aus dem Ort gemacht haben, aber dieser eine Raum braucht immer noch einen neuen Anstrich...
@Tim Severien und % vs. px: Das hängt wirklich vom Anwendungsfall ab! Wenn Sie die volle Kontrolle haben müssen, müssen Sie Pixel verwenden. Für Webseiten: Ja, Sie haben Recht – aber für Apps ist das eine andere Geschichte.
Ich mag diese Idee. Gleichzeitig fühlt es sich etwas unwohl an, Studenten heute über Schriftarten und Einheiten zu unterrichten. Wenn ich neuen Webdesign-Studenten px, %, em und rem erkläre, werden sie manchmal verwirrt. Stellen Sie sich vor, jemandem, der neu im Webbereich ist, zu erklären, wie man 62,5 % auf dem HTML, rem auf den Modulen, em auf den Elementen und px für einige andere Dinge verwendet :). Danke für den Tipp, ich mag ihn!
@Paul d’Aoust
Ja, Sie haben Recht, ich habe bei meinen Tests etwas vermasselt und seitdem zu viel geredet.
Dann funktioniert das, was ich erreichen möchte, mit in px gesetzten Breiten.
In diesem Fall ist das nicht wirklich der Sinn von rems, wenn ems bereits verfügbar sind. Der einzige Unterschied, den ich sehe, ist, dass es mit rems keine Staffelung gibt. Ich werde die Tests wiederholen und aufhören, Mist zu reden.
@olivvv Hehe, keine Sorge; Ich glaube, ich „vermassle ein paar Mal am Tag etwas in meinen Tests und rede zu viel“ (meistens, wenn ich mit Kollegen spreche). Aber ja, Sie haben Recht –
rems sind großartig, weil sie, genau wiepxs, nicht gestaffelt werden, aber wieems sind sie relativ zu einer irgendwo gesetzten Schriftgröße (in diesem Fall der Schriftgröße des Stammelements).Wenn ich nur
rems verwenden könnte... wir sehen immer noch 9 % IE8, und es wäre unverantwortlich für uns, die Unterstützung für einen Browser einzustellen, bis er etwa 2-3 % erreicht. Seufz.Ich bin ein totaler Anfänger, aber ich dachte, ich probiere das für meine nächste Website aus... denn warum nicht. Neugierig aber... kann ich das mit dem Goldenen Schnitt mischen, damit das funktioniert, während der Fallback einfach ist und die ganze Debatte über px vs % vs em auf Dokumentenebene (die ich einfach nicht qualifiziert genug bin zu verstehen) anspricht?
Könnte ich also font-size auf 62,5 % setzen und die Fallback-Werte für meine Module beibehalten? Für Typografie... Ich müsste die Dinge wahrscheinlich immer noch aufteilen... aber zumindest müsste ich nur durch die 1,6rem/16px zu em teilen und ich wüsste, dass 1em 16px sind, richtig?
Ich verwende seit Jahren ems bei neuen Projekten und wurde so unterrichtet, als ich meine erste Anstellung in einer Agentur bekam. Die Idee von rems ist großartig, da sie vom Dokument ausgehen, aber die Browserunterstützung reicht nicht aus, um sie bei allen Projekten zu verwenden, siehe caniuse-Website: http://caniuse.com/#feat=rem
Mir wurde immer der font-size:62.5%-Trick beigebracht, um ems so nah wie möglich an relevante px-Dimensionen zu bringen, wie in den Kommentaren oben erwähnt: 1,6em = 16px, 2,0em = 20px und so weiter.
Warum verwenden Sie nicht die :root-Pseudo-Klasse, um die Schriftgröße des Stammelements festzulegen?
Interessanter Artikel.
Ich habe die Grafik gespeichert und bemerkt, dass es sich um eine SVG-Grafik handelt. Ich habe ein Beispielmuster dieses Tutorials erstellt und die SVG eingebettet, woraufhin ich bemerkte, dass sie nicht responsiv ist.
Ich habe die SVG geöffnet und den Header wie folgt geändert:
Hmmm... Ich kann diese Code-Oberfläche nicht verstehen. Benötigt klarere UX-Anweisungen.
Tolle Idee Chris. Ich implementiere das gerade in einem Projekt mit guten Ergebnissen :)
Das ist cool, aber ich denke, Ihre Idee kann mit diesem Trick besser gemacht werden
% am Stamm wie:
html{font-size:62.5%;},rem(mit Trick) für Komponenten wie:.article{font-size:20px; font-size:2rem;}und
emfür Textelemente wie in Ihrem BeispielDas einzige Problem dabei ist, dass alles standardmäßig 10px Schriftgröße entspricht.
Ich lehne
remwegen der Browserunterstützung immer noch ab. Aber ich denke, es ist in Ordnung,embis zum Stammelement zu verwenden.Ich verstehe nur eines nicht... Warum sollte man den Text auf einem kleineren Bildschirm verkleinern, anstatt ihn zu vergrößern?
Jos –
Ich stimme zu. Ich habe festgestellt, dass es im Allgemeinen am besten ist, den Körpertext bei „1em“ (oder 100 %) unverändert zu lassen, damit das Gerät/Betriebssystem angeben kann, was es möchte, da es im Allgemeinen gut gerendert wird und auf jedem Gerät gut lesbar ist, unabhängig von Größe oder Auflösung. Die einzige Einschränkung ist, dass einige Schriftarten etwas klein wirken (wie Garamond), daher vergrößere ich diese auf allen Bildschirmen sowieso etwas.
Was kleiner werden muss, sind Überschriften relativ zur Körpertextgröße. Es ist viel weniger sperrig und immer noch sehr klar, wenn Sie die Überschriften proportional zur Bildschirmgröße verkleinern. Ich habe darüber für Typecast geschrieben: Artikel im Typecast-Blog