Share
J'ai récemment écrit sur ems; ce qu’ils sont, comment ils sont utilisés et quelques éléments à garder à l’esprit lorsque vous les implémentez vous-même. Je n'ai fait qu'effleurer la surface et le fil de commentaires a soulevé deux fois plus de questions que l'article a répondu! Dans ce suivi, je vais aller plus loin, en examinant les SME de manière encore plus détaillée.
E sur Dribbble Remarque: L'article précédent couvre toutes les bases. Je vous recommande de les lire avant d'aller plus loin.
Le sujet des mesures sans unité (c'est-à-dire: valeurs sans pixels, pourcentages, ems, yards, brasses…) a été proposé par quelques personnes la dernière fois, d'autant plus que j'avais encouragé l'utilisation d'ems pour spécifier hauteur de la ligne.
Ems sont parfaitement logiques dans ce cas car ils sont relatifs à la taille de police. Si le texte en question grossit ou diminue, la hauteur de ligne augmente également, si elle est définie dans ems. Les unités absolues, comme les pixels, gâcheraient vraiment les choses. La même chose est vraie de l'espacement des lettres, un autre exemple d'une dimension qui devrait toujours être relatif à la taille de la police.
Cependant, nous pouvons améliorer cela. Ems compliquent les choses comme leurs valeurs en cascade; les éléments héritent des valeurs em de leurs parents. Prenons cet arrangement, par exemple: un article contenant un paragraphe:
Si nous appliquons la hauteur de ligne à l'article, il sera également hérité par le paragraphe, ce qui est bien:
Mais ce dont le paragraphe hérite en réalité est le valeur calculée (dans ce cas effectivement 24px), donc sa hauteur de trait est relative à la taille de police de l'article, pas à la sienne. Si nous augmentons la taille de la police du paragraphe à l'équivalent de 20px:
alors sa hauteur de ligne reste fermement à 24px. Idéalement, nous aimerions que sa hauteur de trait apparaisse à 1.5 * 20 = 30px.
C’est là que les mesures sans unité entrent en jeu. En supprimant l’unité em de la hauteur de ligne de l’article:
le paragraphe héritera de la valeur sans unité, 1.5. La hauteur de ligne du paragraphe est maintenant relative à sa propre taille de police, bingo.!
Accentsconagua
Fait intéressant, cela ne s'applique pas à l'espacement des lettres. Et vous pouvez complètement oublier les marges, retrait du texte, ce genre de chose.
Si vous souhaitez en savoir plus sur le sujet, Eric Meyer l'a couvert de manière solide en 2006, et Harry Roberts a un bon aperçu des unités de mesure d'il y a quelques années..
Tandis que microtypographie fait référence aux minuscules détails d'un document (signes de ponctuation, ligatures, coupures de mots, crénage, etc.) macrotypographie gère tous les "gros" trucs. Pensez à tous les aspects de la typographie qui rendent un corps de texte lisible. espaces, longueur de ligne (mesure), indentation de paragraphe, etc..
Regardez cette configuration de colonne de fluide:
Une mise en page parfaitement décente; deux divs, chacun exactement 50% de large, avec un rembourrage à gauche et à droite pour former les gouttières (à l'intérieur de chaque div, en supposant que * box-sizing: border-box est utilisé). En règle générale, vous seriez tenté de définir le remplissage à l’aide de pixels ou, mieux encore, de pourcentages, si vous vous sentiez super flexible..
Cependant, les pixels et les pourcentages auront tous deux un effet néfaste sur la lisibilité du contenu, si (quand) la taille de la police est modifiée. La largeur de la gouttière, comme avec les espaces en général, devrait être réellement dimensionnée par rapport au texte. Dans cet exemple, nous avons deux colonnes de texte, avec gouttière appliquée en pourcentage de la largeur de la colonne, comme nous l'avons décrit ci-dessus:
.colonne largeur: 50%; float: gauche; rembourrage: 0 3%;
C'est une démo en direct, jetez un coup d'oeil et déconnez-vous vous-même… Cependant, lorsque vous modifiez la taille de la police, vous remarquerez que la gouttière devient relativement plus étroite, brouillant la division entre les colonnes de texte et rendant la lecture plus difficile..
Ceci est un exemple extrême, avec un texte absurdement grand pour la largeur de la colonne, mais il illustre le point… Il serait bien mieux de définir le remplissage à l’aide de ems:
.colonne largeur: 50%; float: gauche; rembourrage: 0 1.2em;
De cette façon, la gouttière s'agrandit et se rétrécit avec le texte, en maintenant la distance entre les colonnes et en laissant les choses lisibles..
Essayez de jouer avec celui-ci… Si vous n'utilisez pas encore les em, c'est probablement l'une des deux choses que vous n'aimez pas chez elles; le fait que leurs valeurs en cascade, ou d'avoir à calculer ces valeurs en premier lieu.
L’approche à 62,5% (proposée pour la première fois par Richard Rutter en 2004) vous aidera dans la seconde étape. Tout simplement, au lieu de définir la taille de la police de base à 100% (ce qui est supposé être 16 pixels), nous la définissons à 62,5%, soit 10 pixels..
À partir de là, 1em = 10 px. Donc:
| Ems | Pixels équivalents |
| 0.5em | 5px |
| … | … |
| 1.1em | 11px |
| 1.2em | 12px |
| 1.3em | 13px |
| 1.4em | 14px |
| … | … |
| 47.3em | 473px |
et ainsi de suite, ce qui devrait éliminer une partie de l'arithmétique mentale. toutefois, il y a un petit problème avec cette approche, et tout cela a à voir avec…
Nous parlerons un peu de la mise en garde de 62,5% dans un instant, mais nous devons d'abord jeter les bases.
Dans leur forme la plus simple, les requêtes multimédia nous aident à appliquer les règles CSS dans différentes circonstances, le plus souvent en fonction de la taille de l'écran. Les résolutions d'écran sont mesurées en pixels, il est donc logique que nous définissions les requêtes de média de la même manière:
Écran @média uniquement et (largeur minimale: 600 pixels) / * certains éléments * /
Appliquons cela à notre précédente démo, pour séparer les colonnes après un certain point.
Dans cette première approche mobile, nos colonnes sont divisées une fois que la fenêtre d’affichage atteint 600 pixels. Le chiffre arbitraire de 600px s’avère très bien dans ce cas; longueur de ligne optimale (ou mesure) est un sujet très controversé, mais comme le dit Robert Brighurst:
Un nombre compris entre 45 et 75 caractères est généralement considéré comme une longueur de ligne satisfaisante pour une page comportant une seule colonne et dont le format de texte contient une face avec texte renforcé. La ligne de 66 caractères (comptant à la fois les lettres et les espaces) est largement considérée comme idéale..
Robert Brighurst - Les éléments du style typographique
Dans notre démo, avec une taille de police de 1em, la mesure frappe maintenant environ 70 caractères avant de se scinder en deux colonnes..
Une fois que nous avons atteint deux colonnes, la mesure est peut-être un peu plus étroite que nous ne l'aurions idéalement aimé, mais ces colonnes sont parfaitement acceptables pour les besoins de cette démonstration. Cependant, des problèmes surviennent lorsque nous modifions la taille de la police de notre navigateur (tapez sur +).
Avec la taille de police augmentée à "Très grand" (j'utilise Chrome), nos mesures de colonne sont façon trop étroit, rendant le contenu plutôt illisible. Pour cette raison, nous devrions également envisager de consulter nos médias en fonction de la taille de la police..
Rappelez-vous la formule de notre article précédent?
Nous visons 600px, à partir d’une taille de police héritée de 16px. 600/16 = 37,5em, changeons donc notre requête média pour refléter cela:
Désormais, lorsque les paramètres de taille de police de notre navigateur sont modifiés, nous voyons une différence dans le comportement de la requête multimédia. Avec un texte plus volumineux, voici la requête multimédia basée sur les pixels, avec une fenêtre d'affichage d'environ 630 pixels de large:
Considérant que, à cette largeur d’écran, la requête multimédia basée sur em conserve les éléments correctement dans une colonne; agréable et lisible.
Effectuer un zoom avant / arrière et regarder la requête de média prendre effet Voici le resserrement; Les requêtes multimédia basées sur em sont totalement désintéressées par tout dimensionnement de la html, corps, ou peu importe; ils sont relatifs à la taille de police du navigateur. Cela signifie qu'en définissant la taille de la police de base sur une valeur autre que 100%, vous devrez gérer deux échelles de valeurs em..
Travaillez à partir de 100% et tout commencera de la même manière. De plus, comme le soutient Filament Group, travailler de cette manière vous éloigne de la pensée en pixels, ce qui est une bonne chose..
Un mot est apparu plus que tout autre dans le fil de commentaires de l'article précédent; mixin. Si vous avez du mal à comprendre les calculs, alors pourquoi ne pas laisser un préprocesseur CSS faire le gros du travail pour vous?
Avec les préprocesseurs CSS, tels que Sass, LESS et Stylus, vous pouvez définir des mixins et des fonctions. Ceux-ci acceptent les paramètres, puis calculent et désabonnent pour vous les valeurs CSS.
Remarque: Si vous débutez dans ce concept, jetez un coup d’œil à Mastering Sass: Leçon 2 dans laquelle Jeffrey présente Sass mixins..
Les mixins et les fonctions peuvent gérer toutes sortes de choses pour vous, y compris les problèmes de mathématiques qui entourent ems.
Prenez cet exemple simple de Garrett Winder à Erskine. Il commence par définir une fonction (appelée "em") qui accepte deux valeurs (tout comme notre formule de précédemment) bien que la valeur de contexte ait une valeur par défaut de 16, il n'est donc pas nécessaire de la spécifier à moins que nécessaire..
Nous pouvons ensuite utiliser cette fonction "em" dans CSS par la suite, en lui demandant de calculer l'équivalent de 30px:
Qui, une fois compilé, affiche le CSS dans sa forme brute:
Et ce n'est pas le seul exemple de ce type non plus - des milliers de développeurs front-end ont coupé leurs dents en prétraitement en écrivant leurs propres em mixins. Rems aussi; en entrant la valeur de pixel souhaitée dans ce mix présenté par Chris Coyier, vous pouvez tout aussi facilement obtenir des rems en sortie, avec des pixels de repli.
Voici le mixin. 
Voici l'utilisation. 
Voici le résultat. La liste est presque infinie, mais si vous avez des mixins que vous aimez utiliser dans votre propre travail (pour la sortie d'ems et de rems), faites-le-moi savoir dans les commentaires et je les ajouterai ici:
C'est un sujet vaste, il y a clairement beaucoup de choses à faire, mais plonger dans le monde des ems est l'un des défis les plus satisfaisants du développement Web front-end. Arrêtez de penser en pixels et commencez à penser relativement, aujourd'hui!
